0

I've almost got my head wrapped around NS delegation records.

I have this question though: Can a non-authorative dns server containing a domain zone ever return a record from that zone instead of proceeding to the server in the NS record?

For example:

Registrar has example.com with nameserver = ns1.A.example

ns1.A.example has the zone example.com with the following:

NS = ns1.B.example
A = 192.0.2.4

ns1.B.example with the zone example.com has the following:

NS = ns1.B.example
A = 192.0.2.8

Obviously, 192.0.2.8 is the authoritative answer, and both name servers listed above should always return 192.0.2.8 when queried.

Is there ANY situation where 192.0.2.4 would be returned as an answer? Or would that record NEVER be accessed because of the NS record not matching?

0

Your setup will always return 192.0.2.4. This is based on a quick test I conducted on one of my domains. Considering that it is an easy test, I urge you to do the same and verify it for yourself.

5
  • ok, actually i see that happening now. But, why is it returning 1.2.3.4? It should use the NS record to see that the authority is ns1.B and then A should ask B for the address and then A should return 5.6.7.8 based on that answer. Everything I have read indicates that the NS record tells the resolver to go to that server for the answer. – JMain Sep 23 '20 at 2:53
  • Someone edited the ip addresses in my question, so my last comment is wrong. Now, it should say, why is it returning 192.0.2.4? It should see the NS pointing to the next dns server which would return 192.0.2.8. – JMain Sep 23 '20 at 3:11
  • Your lookup is for A record, and when it reaches ns1.A.example bind sees that A record locally and returns the same. – tinkertwain Sep 23 '20 at 3:47
  • But if you remove the A record from ns1.A, it still does not continue to ns1.B, it doesn't return any address – JMain Sep 23 '20 at 18:46
  • This is not how bind is supposed to work. You cannot keep chaining name servers. May I know what exactly are you trying to do? – tinkertwain Sep 23 '20 at 18:58
2

What you describe is the lame delegation case (if I understood correctly, it is not 100% clear - obfuscation almost always brings uncertainty - ; registrar has almost nothing to do there, what is important is what the registry aka parent nameservers say).

The upstream authoritative nameservers are saying the name is handled (authoritatively) by one nameserver, but then if you query it, it says the zone is handled by another nameserver.

This "shouldn't" happen because it creates obvious problems. Some recursive nameservers are child-centric (and hence will tend to believe what the child says, this is maybe the intent of original DNS specifications) while others are parent-centric. So your assertion of "Obviously, 192.0.2.8 is the authoritative answer", is not so obvious in fact...

It will also depend on caches, and when/how this change has been carried out.

You should avoid being in this situation at all costs. It may not show operational problems right now, testing tool like DNSViz will flag just a warning, not an error, but at some point it may cascade into further bigger problems.

PS: and yes I did edit your question to put proper names and IP addresses. Please do not obfuscate badly and do not use resources that obviously exists and are in use.

0

You can force a query against the second nameserver with nslookup to return the information. A host with the second name server listed manually would also generate the same result. There is no other way that would do it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.