Mismatch in NS and glue records in the parent zone, where every NS is still auth

What happens with glue record inconsistency, where every single server that is listed as an NS server at the parent zone for the child zone, always answers records authoritatively regarding the child zone, but is not necessarily listed as an NS server within the child zone itself?

For example, if b.dns.ripn.net. of the parent zone su. says that my corporate.su. is controlled by server d.ns.corporate.su. with IP-address 2001:db8::d, but when connecting to 2001:db8::d, some of the following things happen:

• the corporate.su. zone itself is present as authoritative on the server 2001:db8::d, but there is no mention of any NS server that could resolve to an IP-address of 2001:db8::d

• a record for d.ns.corporate.su. is missing from the list of NS servers for corporate.su., but another NS record, d.ns.example.net., is present that nonetheless still resolves to 2001:db8::d

  • what if d.ns.corporate.su., from the parent zone, still resolves in the child zone, but to another IP address?
  • what if d.ns.corporate.su. does not even resolve on my authoritative servers, contrary to the glue at the parent zone?

What if I have several such NS records in the parent zone of my domain servers that all authoritatively answer queries regarding my zone, but all or some of which have some kind of mismatch in the names of their records within the actual child zone that contradict the parent zone?

I've tried using dig +nssearch and dig +trace, but it seems like dig suffers from various pollution and silent healing issues, and doesn't make it at all that much obvious what actually happens behind the scenes.

Solution 1:

The problem right now is that your domain is still not delegated.

From what I see in the whois information of the domain, you registered it today. Your domain is registered but not yet delegated;

whois corporate.su | grep state
state:         REGISTERED, NOT DELEGATED

The nic.ru FAQ actually states that it takes between 6 hours and several days for the delegation to actually take effect.

That being said, you seem to have a lot of NS entry in the zone file when I query one of your soon-to-be-delegated-and-authoritative name server.

You have a total of 9 NS entry.

dig +noall +answer @ns4.linode.com corporate.su ns
corporate.su.       86400   IN  NS  ns5.he.net.
corporate.su.       86400   IN  NS  d.ns.corporate.su.
corporate.su.       86400   IN  NS  d.ns.cns.su.
corporate.su.       86400   IN  NS  ns5.linode.com.
corporate.su.       86400   IN  NS  ns4.linode.com.
corporate.su.       86400   IN  NS  ns4.he.net.
corporate.su.       86400   IN  NS  ns2.linode.com.
corporate.su.       86400   IN  NS  ns2.he.net.
corporate.su.       86400   IN  NS  ns3.he.net.

You need to understand that all of these 9 Name Servers will be Authoritative Name Server. Meaning they will answer with the AA flag and will not do recursive query for corporate.su.

The five Name Server you included in your registrar form are the Delegated Name servers.

whois corporate.su | grep nserver
nserver:       any.ns.cns.su.
nserver:       d.ns.corporate.su.
nserver:       lon.ns.cns.su.
nserver:       ns2.he.net.
nserver:       ns4.linode.com.

Of these, only d.ns.corporate.su will require glue records in the parent zone.

The reason being that in order to resolve any other Delegated Name Servers for your domain, the resolver doesn't need to know how to resolve your domain. (ie Circular dependencies).

The Delegated Name Servers should actually match the Authoritative Name Servers. So you should check your zone and remove NS entries that are not found in your registrars.

Or the other way around...but again...having 9 Delegate Name Servers and/or Authoritative Name Server is quite overkill.

Answer to comments;

what happens when there are name mismatches between the zones

If the mismatch is between two Authoritative Name Server, then you have quite a bit of an issue...normally, the SOA will prevail.

If my resolver detects conflict, it will send the query to the SOA (d.ns.cns.su in your case).

will not do recursive query for corporate.su" -- what do you mean by that? why would they have to? they're already authoritative, and have all the zone info

They should not, that's exactly my point. If two of them send conflicting zone information, they do so with the AA flag...I should take it for granted that what they send me is the correct information.

As for the Glue record, in your case, it's still not an issue...your domain is NOT delegated.

dig @a.dns.ripn.net d.ns.corporate.su

; <<>> DiG 9.8.1-P1 <<>> @a.dns.ripn.net d.ns.corporate.su
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35421
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;d.ns.corporate.su.     IN  A

;; AUTHORITY SECTION:
su.         3600    IN  SOA a.dns.ripn.net. hostmaster.ripn.net. 650151100 86400 14400 2592000 3600

;; Query time: 150 msec
;; SERVER: 193.232.128.6#53(193.232.128.6)
;; WHEN: Wed Feb 13 21:30:42 2013
;; MSG SIZE  rcvd: 96

You should notice 3 things here.

1- That answer was Authoritative (AA flag) 2- It did not offer NS records in the Authority Section 3- There is still no SOA for your zone

This means, that 1- Your domain does not have any Glue records of any kind for now. 2- None of the Authoritative Name Server for corporate.su are part of the delegation path.

Looking at your question, here are some corrections;

For example, if b.dns.ripn.net. of the parent zone su. says that my corporate.su. is controlled by server d.ns.corporate.su.

Well it's really not.

dig @b.dns.ripn.net corporate.su soa

No SOA, no delegation offered.

what if d.ns.corporate.su., from the parent zone, still resolves in the child zone, but to another IP address?

what if d.ns.corporate.su. does not even resolve on my authoritative servers, contrary to the glue at the parent zone?

I suggest you read the answer I provided for exactly that situation on meta.serverfault.com

But if the Glue is right, and your Zone is wrong...then you will have resolving issues. If your Glue is wrong, but your zone is right, it's not as bad...not clean at all...but not as bad.

What if I have several such NS records in the parent zone of my domain servers that all authoritatively answer queries regarding my zone, but all or some of which have some kind of mismatch in the names of their records within the actual child zone that contradict the parent zone?

With DNS, your SOA is almighty. Glue records should match what the SOA is resolving your delegated name server to, not the other way around.