ignoring incorrect nameservers in authority section
pyh at mail.nsbeta.info
pyh at mail.nsbeta.info
Thu Dec 30 04:36:25 UTC 2010
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
More information about the bind-users
mailing list