Recursive Replies
prock111 at yahoo.com
prock111 at yahoo.com
Fri Feb 12 18:06:17 UTC 2010
minimal-responses is perfect. thanks.
--- On Thu, 2/11/10, Kevin Darcy <kcd at chrysler.com> wrote:
> From: Kevin Darcy <kcd at chrysler.com>
> Subject: Re: Recursive Replies
> To: bind-users at 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, 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
> >
> >
> >
> >
> >
>
>
> _______________________________________________
> 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