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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
