Inconsistent Glue Records

Question

We've picked up a number of issues on mxtoolbox and various other online DNS tools that we have inconsistent glue records. In particular, it appears that the glue records setup at the TLD (.host in this case) has glue records setup for our 4 nameservers but 2 of their NIC servers do not have an IP address assigned.

In particular, .host has 4 NIC servers (a.nic.host - d.nic.host) and it appears that only a.nic.host and b.nic.host has IP addresses assigned to our 4 name servers where c.nic.host and d.nic.host has none.

When we do a query for our domain on pingdom dns check tool we're given a number of errors:

 Nameserver ns1.intelli.host is listed for zone intelli.host without address information.
 Nameserver ns3.intelli.host is listed for zone intelli.host without address information.
 Nameserver ns4.intelli.host is listed for zone intelli.host without address information.

These errors appear at random (i predict based on which NIC server returned the results).

Ultradns is more precise at the bottom of the trace indicating that online a.nic.host and b.nic.host has IP addresses assigned.

When I however do a:

 dig +norec @c.nic.host intelli.host NS

I am given IP addresses for the 4 nameservers - This leads me to believe that either I'm not doing the correct dig command on that the various online tools like pingdom and ultratools are reporting incorrectly (which I doubt)

Can anyone confirm whether my understanding of the issues we experience is correct?

UPDATE (DAY 2)

Thank you all for your help thus far! From answers thus far it appears that it may pingdom leading us in the dark, but I have found 2 other DNS tool sites also giving random results.

What is clear in all of these cases is that, at random, we will get some sort of DNS issue, and from what I can again gather it's when c.nic.host or d.nic.host is reporting glue records:

VIEWDNS: http://viewdns.info/dnsreport/?domain=intelli.host

Note that this one gives different results with some queries. It mostly changes dependant on which server gives it a result (in this case it was d.nic.host):

Nameserver records returned by the parent servers are:
ns2.intelli.host. [NO GLUE] [TTL=3600]
ns3.intelli.host. [NO GLUE] [TTL=3600]
ns1.intelli.host. [NO GLUE] [TTL=3600]
ns4.intelli.host. [NO GLUE] [TTL=3600]

This information was kindly provided by d.nic.host.

Error also from VIEWDNS: Oops! The IP addresses (GLUE) returned for your nameserver don't match! You should closely observe the nameserver details above and identify where the differences lie.

ULTRADNS https://www.ultratools.com/tools/dnsLookupResult (might have to search here for intelli.host as there is no direct link)

When going to trace, it shows at the bottom the returned HOST records as follows:

host.
b.nic.host.66 ms
intelli.host.   ns2.intelli.host.   129.232.201.205
intelli.host.   ns1.intelli.host.   129.232.201.203
intelli.host.   ns3.intelli.host.   13.80.126.179
intelli.host.   ns4.intelli.host.   40.121.91.245

d.nic.host.3 ms
intelli.HOST.   ns2.intelli.host.   
intelli.HOST.   ns1.intelli.host.   
intelli.HOST.   ns3.intelli.host.   
intelli.HOST.   ns4.intelli.host.   

c.nic.host.38 ms
intelli.HOST.   ns1.intelli.host.   
intelli.HOST.   ns4.intelli.host.   
intelli.HOST.   ns3.intelli.host.   
intelli.HOST.   ns2.intelli.host.   

a.nic.host.65 ms
intelli.host.   ns4.intelli.host.   40.121.91.245
intelli.host.   ns1.intelli.host.   129.232.201.203
intelli.host.   ns2.intelli.host.   129.232.201.205  
intelli.host.   ns3.intelli.host.   13.80.126.179

At the time of this comment, ns3 and ns4 are no longer showing up in the [pingdom errors](http://dnscheck.pingdom.com/?domain=intelli.host). ns1 is still there, and ns2 (not in the original question) ihas appeared. Something strange is definitely going on here. — Andrew B, Jun 20 '17 at 23:26
@AndrewB Yes this morning it's only indicating issues on ns2, the others are no longer reporting as problems, but the strange thing is we have not actually done anything. I've picked up similiar issues on ultradns and viewdns.org, but also at random — mauzilla, Jun 21 '17 at 07:22
Describe "similar issues on [other services]"? An example would be helpful, as the current error messages are specific to Pingdom. — Andrew B, Jun 21 '17 at 07:27
`c.nic.host` and `d.nic.host` being consistently involved would fit the theory that it has something to do with case sensitive comparison between DNS records. At this point I think it would be best to let [RADIX](https://radixregistry.com/dot-host) (TLD operator for .host) run with this problem as it is impacting their brand. There is a problem at the TLD nameserver level that you cannot correct (and that we can't reproduce), or those two servers of theirs are being incorrectly flagged by poorly written software. We need a second .host domain that delegates to child nameservers to confirm. — Andrew B, Jun 21 '17 at 08:02
I actually already have a support ticket open with them and with enom (the actual registrar) - Enom has a massive backlog of support queries (ticket has been open for 12 days) so hoping radix will be helpful in resolving this query for us — mauzilla, Jun 21 '17 at 08:15

score 1 · Answer 1 · answered Jun 20 '17 at 13:59

1

You need to set both names and IP addresses for all your four name servers at the registrar. They probably have some web interface for that. Then, your name servers must have the exactly same four NS record (and their A records), all the name servers must have the same zone data etc.

See IANA Technical requirements for authoritative name servers:

Consistency between glue and authoritative data

For name servers that have IP addresses listed as glue, the IP addresses must match the authoritative A and AAAA records for that host.

Consistency between delegation and zone

The set of NS records served by the authoritative name servers must match those proposed for the delegation in the parent zone.

answered Jun 20 '17 at 13:59

Esa Jokinen

43,252
2
75
122

@Mauzilla Did you actually confirm that there was a mismatch between the glue and authoritative definitions? I don't see that this is the case, and the nameservers associated with the error have changed since the original question was posted. I don't think this was a result of acting on your answer as pingdom is now complaining about ns2, when it wasn't originally. – Andrew B Jun 20 '17 at 23:28
While you weren't having this problem, I'll keep this answer as it might be helpful for anyone who finds this on Google. This is the most common case. – Esa Jokinen Jun 21 '17 at 09:02

Andrew B · Answer 2 · 2017-06-20T23:57:23.627

I suspect you've stumbled across a bug in Pingdom's code with regard to mixed case. That's the most I can figure out here. Your next step should be to take this to Pingdom's technical support.

Step 1: Confirm that glue records are present

All glue records are present at the point of delegation:

$ dig +norec @c.nic.host intelli.host NS

; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> +norec @c.nic.host intelli.host NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51608
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;intelli.host.                  IN      NS

;; AUTHORITY SECTION:
intelli.HOST.           3600    IN      NS      ns1.intelli.host.
intelli.HOST.           3600    IN      NS      ns3.intelli.host.
intelli.HOST.           3600    IN      NS      ns4.intelli.host.
intelli.HOST.           3600    IN      NS      ns2.intelli.host.

;; ADDITIONAL SECTION:
ns1.intelli.HOST.       3600    IN      A       129.232.201.203
ns2.intelli.HOST.       3600    IN      A       129.232.201.205
ns3.intelli.HOST.       3600    IN      A       13.80.126.179
ns4.intelli.HOST.       3600    IN      A       40.121.91.245

;; Query time: 32 msec
;; SERVER: 2a02:e180:3::2#53(2a02:e180:3::2)
;; WHEN: Tue Jun 20 23:32:59 UTC 2017
;; MSG SIZE  rcvd: 205

Step 2: Confirm that glue records align with data on child nameservers:

$ for ip in 129.232.201.203 129.232.201.205 13.80.126.179 40.121.91.245; do echo ==@$ip==; dig @$ip +noall +question +answer ns{1..4}.intelli.host; done
==@129.232.201.203==
;ns1.intelli.host.              IN      A
ns1.intelli.host.       14400   IN      A       129.232.201.203
;ns2.intelli.host.              IN      A
ns2.intelli.host.       14400   IN      A       129.232.201.205
;ns3.intelli.host.              IN      A
ns3.intelli.host.       14400   IN      A       13.80.126.179
;ns4.intelli.host.              IN      A
ns4.intelli.host.       14400   IN      A       40.121.91.245
==@129.232.201.205==
;ns1.intelli.host.              IN      A
ns1.intelli.host.       14400   IN      A       129.232.201.203
;ns2.intelli.host.              IN      A
ns2.intelli.host.       14400   IN      A       129.232.201.205
;ns3.intelli.host.              IN      A
ns3.intelli.host.       14400   IN      A       13.80.126.179
;ns4.intelli.host.              IN      A
ns4.intelli.host.       14400   IN      A       40.121.91.245
==@13.80.126.179==
;ns1.intelli.host.              IN      A
ns1.intelli.host.       14400   IN      A       129.232.201.203
;ns2.intelli.host.              IN      A
ns2.intelli.host.       14400   IN      A       129.232.201.205
;ns3.intelli.host.              IN      A
ns3.intelli.host.       14400   IN      A       13.80.126.179
;ns4.intelli.host.              IN      A
ns4.intelli.host.       14400   IN      A       40.121.91.245
==@40.121.91.245==
;ns1.intelli.host.              IN      A
ns1.intelli.host.       14400   IN      A       129.232.201.203
;ns2.intelli.host.              IN      A
ns2.intelli.host.       14400   IN      A       129.232.201.205
;ns3.intelli.host.              IN      A
ns3.intelli.host.       14400   IN      A       13.80.126.179
;ns4.intelli.host.              IN      A
ns4.intelli.host.       14400   IN      A       40.121.91.245

Step 3: Confirm that there is no NS record mismatch

$ for ip in 129.232.201.203 129.232.201.205 13.80.126.179 40.121.91.245; do echo ==@$ip==; dig @$ip +short intelli.host NS ; done
==@129.232.201.203==
ns1.intelli.host.
ns2.intelli.host.
ns3.intelli.host.
ns4.intelli.host.
==@129.232.201.205==
ns2.intelli.host.
ns3.intelli.host.
ns4.intelli.host.
ns1.intelli.host.
==@13.80.126.179==
ns2.intelli.host.
ns4.intelli.host.
ns1.intelli.host.
ns3.intelli.host.
==@40.121.91.245==
ns1.intelli.host.
ns2.intelli.host.
ns4.intelli.host.
ns3.intelli.host.

Step 4: Consult the almighty dnsviz for DNSSEC inconsistencies

Looks good.

Step 5: Re-evaluate the problem

Your initial question indicated that Pingdom reported problems with ns1, ns3, and ns4. When I ran the same check through Pingdom, I received errors for a different set of nameservers:

Delegation

Nameserver ns2.intelli.host is listed for zone intelli.host without address information.

Nameserver ns4.intelli.host is listed for zone intelli.host without address information.

The error for ns4 is still present.
The errors for ns1 and ns3 are gone.
The error for ns2 is new.

At this point I evaluated the possibility that the inconsistency was at the parent nameservers:

$ for ns in {a..d}; do echo ==@$ns.nic.host==; dig @$ns.nic.host +noall +question +authority +additional intelli.host; done
==@a.nic.host==
;intelli.host.                  IN      A
intelli.host.           3600    IN      NS      ns1.intelli.host.
intelli.host.           3600    IN      NS      ns2.intelli.host.
intelli.host.           3600    IN      NS      ns3.intelli.host.
intelli.host.           3600    IN      NS      ns4.intelli.host.
ns1.intelli.host.       3600    IN      A       129.232.201.203
ns2.intelli.host.       3600    IN      A       129.232.201.205
ns3.intelli.host.       3600    IN      A       13.80.126.179
ns4.intelli.host.       3600    IN      A       40.121.91.245
==@b.nic.host==
;intelli.host.                  IN      A
intelli.host.           3600    IN      NS      ns1.intelli.host.
intelli.host.           3600    IN      NS      ns3.intelli.host.
intelli.host.           3600    IN      NS      ns2.intelli.host.
intelli.host.           3600    IN      NS      ns4.intelli.host.
ns1.intelli.host.       3600    IN      A       129.232.201.203
ns2.intelli.host.       3600    IN      A       129.232.201.205
ns3.intelli.host.       3600    IN      A       13.80.126.179
ns4.intelli.host.       3600    IN      A       40.121.91.245
==@c.nic.host==
;intelli.host.                  IN      A
intelli.HOST.           3600    IN      NS      ns3.intelli.host.
intelli.HOST.           3600    IN      NS      ns2.intelli.host.
intelli.HOST.           3600    IN      NS      ns1.intelli.host.
intelli.HOST.           3600    IN      NS      ns4.intelli.host.
ns1.intelli.HOST.       3600    IN      A       129.232.201.203
ns2.intelli.HOST.       3600    IN      A       129.232.201.205
ns3.intelli.HOST.       3600    IN      A       13.80.126.179
ns4.intelli.HOST.       3600    IN      A       40.121.91.245
==@d.nic.host==
;intelli.host.                  IN      A
intelli.HOST.           3600    IN      NS      ns2.intelli.host.
intelli.HOST.           3600    IN      NS      ns4.intelli.host.
intelli.HOST.           3600    IN      NS      ns1.intelli.host.
intelli.HOST.           3600    IN      NS      ns3.intelli.host.
ns1.intelli.HOST.       3600    IN      A       129.232.201.203
ns2.intelli.HOST.       3600    IN      A       129.232.201.205
ns3.intelli.HOST.       3600    IN      A       13.80.126.179
ns4.intelli.HOST.       3600    IN      A       40.121.91.245

Note that the case for .HOST changes in the responses from C and D. At this point I suspect the most likely case is that Pingdom is barfing when attempting to do comparisons between mixed case DNS entities, which is would be a bug according to the DNS standards.

I've updated my question with some newer findings. Thank you so much for your comprehensive help so far! — mauzilla, Jun 21 '17 at 07:25
Thanks Andrew, nice investigation! I must admit that I thought the `intelli.host` was a replacement for the actual domain. I confirm, this seems like a bug in Pingdom. Has someone reported it? — Esa Jokinen, Jun 21 '17 at 08:57