Recursive Replies

Kevin Darcy kcd at chrysler.com
Thu Feb 11 21:49:46 UTC 2010


They're the same in the Answer Section, different in the Authority 
Section. Whether they're "wrong" or not is a value judgement. No RFCs 
and/or Internet Standards are broken here, as far as I can see.

The closest thing in BIND to ensuring that the "same" response is always 
given to a particular query (or, more technically, the combination of 
QNAME and QTYPE, since there are "meta" types such as AXFR and ANY), is 
to set the global option "minimal-responses" to "yes". That will 
suppress unnecessary Authority and/or Additional Section contents. Note 
that the ordering of the records within the Answer Section are not 
guaranteed to be "the same" (although this can be controlled in BIND 
through the rrset-order and/or sortlist options), and there are other 
attributes/aspects of a response -- which you don't show -- such as 
EDNS0 buffer size, which can differ, depending on how the question was 
asked, whether intermediate devices are messing with the packets in 
transit, etc. Depends on how rigorous you want to be about "sameness", 
really. With DNSSEC you may see even more variability.

Note, also, that sometimes Authority and/or Additional Section contents 
are required by the protocol, so, for some QNAMEs, and some QTYPEs, at 
certain points in the delegation hierarchy, Authority and/or Additional 
Section contents *can't* legally be suppressed by "minimal-responses". 
Usually, such *required* Authority and/or Additional Sections will be 
consistent, however, for the same query made at different times, 
assuming the actual data doesn't change, and subject to the "extraneous" 
variability mentioned above (address-record ordering, EDNS0 buffer size 
and so forth).

Generally, however, I've found in my own personal experience that when 
people try to conceal at what level of the DNS hierarchy certain records 
exist, e.g. .com versus test.com, it's because they're trying to mask a 
deeper architectural problem. The way to keep your cache from getting 
"poisoned" by unwanted NS records is to define the relevant delegation 
point(s) as master/slave/stub, rather than skinnying the responses from 
your upstream and hoping for the best...

                                                                         
                                                                         
                                                                         
                     - Kevin

On 2/11/2010 2:18 PM, prock111 at yahoo.com wrote:
> The following two DIG replies were obtained in a closed lab for the same query.  Note the Header and Answer sections are similar (the response ID was stripped out).  But the Authority and Additional sections of the response differ.
>
> My questions:  These responses are not wrong.  They are differnet, but not wrong.  Would you agree?
>
> Second question is: is there a way to make a recursive NS provide the same response to a query?  (Minus the ID data in the header section of course.)  In the example below, is there a setting in named.conf (or anything else) that can provide the same response for a query?  (thanks)
>
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
> ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 31, AUTHORITY: 7, ADDITIONAL: 14
> ;; QUESTION SECTION:
> ;a.test.com. IN AAAA
> ;; ANSWER SECTION:
> a.test.com. in aaaa   a:b:c:d:e:f:f:55
> a.test.com. in aaaa   a:b:c:d:e:f:f:56
> a.test.com. in aaaa   a:b:c:d:e:f:f:57
> a.test.com. in aaaa   a:b:c:d:e:f:f:58
> a.test.com. in aaaa   a:b:c:d:e:f:f:59
> a.test.com. in aaaa   a:b:c:d:e:f:f:60
> a.test.com. in aaaa   a:b:c:d:e:f:f:61
> a.test.com. in aaaa   a:b:c:d:e:f:f:62
> a.test.com. in aaaa   a:b:c:d:e:f:f:63
> a.test.com. in aaaa   a:b:c:d:e:f:f:64
> a.test.com. in aaaa   a:b:c:d:e:f:f:65
> a.test.com. in aaaa   a:b:c:d:e:f:f:66
> a.test.com. in aaaa   a:b:c:d:e:f:f:67
> a.test.com. in aaaa   a:b:c:d:e:f:f:68
> a.test.com. in aaaa   a:b:c:d:e:f:f:69
> a.test.com. in aaaa   a:b:c:d:e:f:f:70
> a.test.com. in aaaa   a:b:c:d:e:f:f:71
> a.test.com. in aaaa   a:b:c:d:e:f:f:72
> a.test.com. in aaaa   a:b:c:d:e:f:f:73
> a.test.com. in aaaa   a:b:c:d:e:f:f:74
> a.test.com. in aaaa   a:b:c:d:e:f:f:75
> a.test.com. in aaaa   a:b:c:d:e:f:f:76
> a.test.com. in aaaa   a:b:c:d:e:f:f:77
> a.test.com. in aaaa   a:b:c:d:e:f:f:78
> a.test.com. in aaaa   a:b:c:d:e:f:f:79
> a.test.com. in aaaa   a:b:c:d:e:f:f:80
> a.test.com. in aaaa   a:b:c:d:e:f:f:81
> a.test.com. in aaaa   a:b:c:d:e:f:f:82
> a.test.com. in aaaa   a:b:c:d:e:f:f:83
> a.test.com. in aaaa   a:b:c:d:e:f:f:84
> a.test.com. in aaaa   a:b:c:d:e:f:f:85
> ;; AUTHORITY SECTION:
> com.                    in      ns      a.gtld-servers.com.
> com.                    in      ns      c.gtld-servers.com.
> com.                    in      ns      d.gtld-servers.com.
> com.                    in      ns      e.gtld-servers.com.
> com.                    in      ns      f.gtld-servers.com.
> com.                    in      ns      g.gtld-servers.com.
> com.                    in      ns      l.gtld-servers.com.
> ;; ADDITIONAL SECTION:
> a.gtld-servers.com.     in      a       192.168.5.10
> a.gtld-servers.com.     in      aaaa    2001:4f8:0:2::d
> c.gtld-servers.com.     in      a       192.168.5.10
> c.gtld-servers.com.     in      aaaa    2001:4f8:0:2::d
> d.gtld-servers.com.     in      a       192.168.5.10
> d.gtld-servers.com.     in      aaaa    2001:4f8:0:2::d
> e.gtld-servers.com.     in      a       192.168.5.10
> e.gtld-servers.com.     in      aaaa    2001:4f8:0:2::d
> f.gtld-servers.com.     in      a       192.168.5.10
> f.gtld-servers.com.     in      aaaa    2001:4f8:0:2::d
> g.gtld-servers.com.     in      a       192.168.5.10
> g.gtld-servers.com.     in      aaaa    2001:4f8:0:2::d
> l.gtld-servers.com.     in      a       192.168.5.10
> l.gtld-servers.com.     in      aaaa    2001:4f8:0:2::d
>
>
>
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR
> ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 31, AUTHORITY: 1, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;a.test.com. IN AAAA
> ;; ANSWER SECTION:
> a.test.com. in aaaa   a:b:c:d:e:f:f:55
> a.test.com. in aaaa   a:b:c:d:e:f:f:56
> a.test.com. in aaaa   a:b:c:d:e:f:f:57
> a.test.com. in aaaa   a:b:c:d:e:f:f:58
> a.test.com. in aaaa   a:b:c:d:e:f:f:59
> a.test.com. in aaaa   a:b:c:d:e:f:f:60
> a.test.com. in aaaa   a:b:c:d:e:f:f:61
> a.test.com. in aaaa   a:b:c:d:e:f:f:62
> a.test.com. in aaaa   a:b:c:d:e:f:f:63
> a.test.com. in aaaa   a:b:c:d:e:f:f:64
> a.test.com. in aaaa   a:b:c:d:e:f:f:65
> a.test.com. in aaaa   a:b:c:d:e:f:f:66
> a.test.com. in aaaa   a:b:c:d:e:f:f:67
> a.test.com. in aaaa   a:b:c:d:e:f:f:68
> a.test.com. in aaaa   a:b:c:d:e:f:f:69
> a.test.com. in aaaa   a:b:c:d:e:f:f:70
> a.test.com. in aaaa   a:b:c:d:e:f:f:71
> a.test.com. in aaaa   a:b:c:d:e:f:f:72
> a.test.com. in aaaa   a:b:c:d:e:f:f:73
> a.test.com. in aaaa   a:b:c:d:e:f:f:74
> a.test.com. in aaaa   a:b:c:d:e:f:f:75
> a.test.com. in aaaa   a:b:c:d:e:f:f:76
> a.test.com. in aaaa   a:b:c:d:e:f:f:77
> a.test.com. in aaaa   a:b:c:d:e:f:f:78
> a.test.com. in aaaa   a:b:c:d:e:f:f:79
> a.test.com. in aaaa   a:b:c:d:e:f:f:80
> a.test.com. in aaaa   a:b:c:d:e:f:f:81
> a.test.com. in aaaa   a:b:c:d:e:f:f:82
> a.test.com. in aaaa   a:b:c:d:e:f:f:83
> a.test.com. in aaaa   a:b:c:d:e:f:f:84
> a.test.com. in aaaa   a:b:c:d:e:f:f:85
> ;; AUTHORITY SECTION:
> test.com.       in      ns      ns1.test.com.
>
>
>
>
>
> _______________________________________________
> 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