ignoring incorrect nameservers in authority section

[pyh at mail.nsbeta.info]

What's the difference between these two flags in the response of dig? 

< ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
 ---
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
 

Thanks in advance. 


Sunil Shetye writes: 

> Quoting from David Sparro's mail on Tue, Dec 28, 2010:
>> >Here, I can see that the nameserver is giving the right replies to all
>> >queries except the NS queries. 
>> 
>> How can an authoritative server give "wrong" answers?
> 
> Due to misconfiguration of the NS records. My guess is that the domain
> was transferred from one nameserver to another without updating the NS
> records and the domain registration was updated. Another reason could
> be that some ill-informed DNS administrators are replacing their NS
> records with 'blackhole' or 'fake' nameservers to avoid DNS attacks on
> their actual servers. 
> 
>> >I was hoping that either bind should catch such cases automatically or
>> >allow some workaround which need not be monitored later. 
>> 
>> You're asking BIND to deduce the intent of the domain owner.
> 
> It is hard to say whether it is intentional or due to a
> misconfiguration. 
> 
> 
> Note that my aim is to ensure that dig +trace (or a non-caching
> nameserver) should give the same answer as named (ignoring TTL). If
> dig +trace is always landing at the right server while named is always
> landing at the wrong server (till the cached NS records expire) (see
> case 3 below), it is very hard to debug the problem. 
> 
> 
> Here are the detailed cases which are applicable here. When bind
> queries a nameserver, the following types of answers are expected
> (apart from referrals, refused replies, and other errors): 
> 
> Case 1: Authoritative Server Reply 
> 
> ===================================================================
> $ dig +norecurse @a.iana-servers.net. example.org.
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 
> 
> ;; QUESTION SECTION:
> ;example.org.		IN  A 
> 
> ;; ANSWER SECTION:
> example.org.	    172800  IN	A   192.0.32.10 
> 
> ;; AUTHORITY SECTION:
> example.org.	    172800  IN	NS  a.iana-servers.net.
> example.org.	    172800  IN	NS  b.iana-servers.net.
> =================================================================== 
> 
> This is the answer in the correct format. Both the A and NS records
> are cached. bind will give a similar reply back to the client. 
> 
> Case 2: Lame Server Reply 
> 
> ===================================================================
> $ dig +norecurse @a.iana-servers.net. example.org.
> ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 
> 
> ;; QUESTION SECTION:
> ;example.org.		IN  A 
> 
> ;; ANSWER SECTION:
> example.org.	    172800  IN	A   192.0.32.10 
> 
> ;; AUTHORITY SECTION:
> example.org.	    172800  IN	NS  ns1.example.org.
> example.org.	    172800  IN	NS  ns2.example.org.
> =================================================================== 
> 
> This is a lame server reply. bind ignores this reply. bind will give a
> server fail reply to the client. 
> 
> Case 3: "Authoritative Server Reply with Lame NS Records" 
> 
> ===================================================================
> $ dig +norecurse @a.iana-servers.net. example.org.
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 
> 
> ;; QUESTION SECTION:
> ;example.org.		IN  A 
> 
> ;; ANSWER SECTION:
> example.org.	    172800  IN	A   192.0.32.10 
> 
> ;; AUTHORITY SECTION:
> example.org.	    172800  IN	NS  ns1.example.org.
> example.org.	    172800  IN	NS  ns2.example.org.
> =================================================================== 
> 
> Here, we are getting an authoritative reply. This means that the A
> record can be cached. However, note that NS section here does not list
> a.iana-servers.net. Should bind cache this authority section? If
> ns[12].example.org. were the real nameservers, we should have got a
> referral from a.iana-servers.net. and not an authoritative answer. 
> 
> If bind does cache this (as it currently does), the next query for
> example.org will go to ns[12].example.org. directly. However, here we
> can see that a.iana-servers.net. is actually the authoritative
> nameserver, which means that it is ready to answer all example.org
> queries. 
> 
> If bind does not cache the NS records, it will land via referrals back
> to a.iana-servers.net. for the next query and get the correct
> authoritative answer. 
> 
> What should bind reply back to the client? It would be safe to drop
> the authority section in the reply. 
> 
> ===================================================================
> $ dig example.org.
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
> 
> ;; QUESTION SECTION:
> ;example.org.		IN  A 
> 
> ;; ANSWER SECTION:
> example.org.	    172800  IN	A   192.0.32.10
> =================================================================== 
> 
> 
> Hope that this elaborate example clears the picture of what I am
> trying to convey. Note that querying of NS records will also have to
> be handled in a consistent manner. However, some more thought may be
> required there. 
> 
> -- 
> Sunil Shetye.
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users