ignoring incorrect nameservers in authority section

[Sunil Shetye]

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.