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