minimal-responses is perfect. thanks. --- On Thu, 2/11/10, Kevin Darcy <k...@chrysler.com> wrote:
> From: Kevin Darcy <k...@chrysler.com> > Subject: Re: Recursive Replies > To: bind-users@lists.isc.org > Date: Thursday, February 11, 2010, 4:49 PM > 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 > _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
