Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
truncated responses vs. minimal-responses?
2,000 views
Skip to first unread message
Matus UHLAR - fantomas
Nov 27, 2012, 12:28:36 PM11/27/12
to bind-...@lists.isc.org
Hello,
last few weeks I have seen many discussions over UDP truncating and using
"minimal-responses yes;" to prevent BIDN from doing that.
I've read article stating that nameserver should avoid truncating packets
even by skipping additional and authority sections in its responses, which
should mean that using minimal-responses would not help.
However, I've seen a few mails mentioning that a query can get truncated
when the authority section is too big and advices to turn minimal-responses
on.
Reading the 9.9.2 docs and even looking at the sources (I am not a C coder)
did not help me with this.
Can anyone enlight me in this?
Thank you.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watson. -- Daffy Duck & Porky Pig
last few weeks I have seen many discussions over UDP truncating and using
"minimal-responses yes;" to prevent BIDN from doing that.
I've read article stating that nameserver should avoid truncating packets
even by skipping additional and authority sections in its responses, which
should mean that using minimal-responses would not help.
However, I've seen a few mails mentioning that a query can get truncated
when the authority section is too big and advices to turn minimal-responses
on.
Reading the 9.9.2 docs and even looking at the sources (I am not a C coder)
did not help me with this.
Can anyone enlight me in this?
Thank you.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watson. -- Daffy Duck & Porky Pig
Mike Hoskins (michoski)
Nov 27, 2012, 12:41:42 PM11/27/12
to Matus UHLAR - fantomas, bind-...@lists.isc.org
-----Original Message-----
From: Matus UHLAR - fantomas <uh...@fantomas.sk>
Date: Tuesday, November 27, 2012 12:28 PM
To: "bind-...@lists.isc.org" <bind-...@lists.isc.org>
Subject: truncated responses vs. minimal-responses?
>Hello,
>
>last few weeks I have seen many discussions over UDP truncating and using
>"minimal-responses yes;" to prevent BIDN from doing that.
>
>I've read article stating that nameserver should avoid truncating packets
>even by skipping additional and authority sections in its responses, which
>should mean that using minimal-responses would not help.
>
>However, I've seen a few mails mentioning that a query can get truncated
>when the authority section is too big and advices to turn
>minimal-responses
>on.
>
>Reading the 9.9.2 docs and even looking at the sources (I am not a C
>coder)
>did not help me with this.
It seems it should help... less bits in the packet relating to additional
and authority should leave room for other data.
That said, I think the better way (when possible) is to adjust RRs not to
return "too much data" (e.g. NS, A, etc. not returning more than ~8 hosts
-- which in turn could be multicast, load balanced, etc to get the desired
scale).
Akamai, for example, defaults to limiting up to 8 "RDATAs" per RR (or
however you'd describe that). If you add 20 As for a name you'll rotate
through 8 at a time. You can request more at your own risk...they assume
you'll ensure the larger answer will fit in a UDP packet and not cause TCP
responses which cripple performance.
From: Matus UHLAR - fantomas <uh...@fantomas.sk>
Date: Tuesday, November 27, 2012 12:28 PM
To: "bind-...@lists.isc.org" <bind-...@lists.isc.org>
Subject: truncated responses vs. minimal-responses?
>Hello,
>
>last few weeks I have seen many discussions over UDP truncating and using
>"minimal-responses yes;" to prevent BIDN from doing that.
>
>I've read article stating that nameserver should avoid truncating packets
>even by skipping additional and authority sections in its responses, which
>should mean that using minimal-responses would not help.
>
>However, I've seen a few mails mentioning that a query can get truncated
>when the authority section is too big and advices to turn
>minimal-responses
>on.
>
>Reading the 9.9.2 docs and even looking at the sources (I am not a C
>coder)
>did not help me with this.
and authority should leave room for other data.
That said, I think the better way (when possible) is to adjust RRs not to
return "too much data" (e.g. NS, A, etc. not returning more than ~8 hosts
-- which in turn could be multicast, load balanced, etc to get the desired
scale).
Akamai, for example, defaults to limiting up to 8 "RDATAs" per RR (or
however you'd describe that). If you add 20 As for a name you'll rotate
through 8 at a time. You can request more at your own risk...they assume
you'll ensure the larger answer will fit in a UDP packet and not cause TCP
responses which cripple performance.
Matus UHLAR - fantomas
Nov 28, 2012, 10:19:07 AM11/28/12
to bind-...@lists.isc.org
>>last few weeks I have seen many discussions over UDP truncating and using
>>"minimal-responses yes;" to prevent BIDN from doing that.
>>
>>I've read article stating that nameserver should avoid truncating packets
>>even by skipping additional and authority sections in its responses, which
>>should mean that using minimal-responses would not help.
>>
>>However, I've seen a few mails mentioning that a query can get truncated
>>when the authority section is too big and advices to turn
>>minimal-responses
>>on.
>>
>>Reading the 9.9.2 docs and even looking at the sources (I am not a C
>>coder)
>>did not help me with this.
>>"minimal-responses yes;" to prevent BIDN from doing that.
>>
>>I've read article stating that nameserver should avoid truncating packets
>>even by skipping additional and authority sections in its responses, which
>>should mean that using minimal-responses would not help.
>>
>>However, I've seen a few mails mentioning that a query can get truncated
>>when the authority section is too big and advices to turn
>>minimal-responses
>>on.
>>
>>Reading the 9.9.2 docs and even looking at the sources (I am not a C
>>coder)
>>did not help me with this.
On 27.11.12 17:41, Mike Hoskins (michoski) wrote:
>It seems it should help... less bits in the packet relating to additional
>and authority should leave room for other data.
OTOH, some of the data may be needed (later), and adding them into response
>It seems it should help... less bits in the packet relating to additional
>and authority should leave room for other data.
may avoid need for another request.
>That said, I think the better way (when possible) is to adjust RRs not to
>return "too much data" (e.g. NS, A, etc. not returning more than ~8 hosts
>-- which in turn could be multicast, load balanced, etc to get the desired
>scale).
>
>Akamai, for example, defaults to limiting up to 8 "RDATAs" per RR (or
>however you'd describe that). If you add 20 As for a name you'll rotate
>through 8 at a time. You can request more at your own risk...they assume
>you'll ensure the larger answer will fit in a UDP packet and not cause TCP
>responses which cripple performance.
am asking is, if BIND really does skip authority section, if it helps to
avoid sending truncated packets.
If it does, the minimal-responses does NOT affect packet truncation. if it
does not, I ask why...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
M$ Win's are shit, do not use it !
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Tony Finch
Nov 28, 2012, 1:38:08 PM11/28/12
to Matus UHLAR - fantomas, bind-...@lists.isc.org
Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>
> I know. But there are cases you just have much of data in the DNS and what I
> am asking is, if BIND really does skip authority section, if it helps to
> avoid sending truncated packets.
Yes it does. For example, have a look at responses to queries for dotat.at
>
> I know. But there are cases you just have much of data in the DNS and what I
> am asking is, if BIND really does skip authority section, if it helps to
> avoid sending truncated packets.
in mx for various buffer sizes and observe that RRsets are dropped but the
TC bit is not set.
; <<>> DiG 9.9.2-vjs287.12 <<>> +norec +dnssec +ignore +multiline mx dotat.at @puck.nether.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31890
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dotat.at. IN MX
;; ANSWER SECTION:
dotat.at. 3600 IN MX 1 mx.cam.ac.uk.
dotat.at. 3600 IN RRSIG MX 5 2 3600 (
20121217120814 20121117113945 56700 dotat.at.
FLOLFiTEbnAsBka05qJK9nbY3sknNIbG2zSewoqIUkI1
fnm8PDzOB42WoAI2N4vNcQQVkd560B8hRB5a0+tLLZOB
+lz7EA1uLnqCaINJ46BOA0+hXAcAMZMbzYFfVOTN8T/K
89WkExApwdXxffi2dSGOKXAj4KuM3ryfz1g/n7g= )
;; AUTHORITY SECTION:
dotat.at. 3600 IN NS black.dotat.at.
dotat.at. 3600 IN NS ns1.gratisdns.dk.
dotat.at. 3600 IN NS ns3.gratisdns.dk.
dotat.at. 3600 IN NS puck.nether.net.
dotat.at. 3600 IN RRSIG NS 5 2 3600 (
20121225040504 20121125035952 56700 dotat.at.
Hdvs1a2cdGOezLYbNTr1T47g+ZYA9ceBgUQD1tkHvJjL
0+nwREF/0JRs9Neb/Y+jpe0+PeIcDKCEOyD8GTeyc0ve
Ez4sKt3OmkVUp1QN4gFmaeH/oPnPmhYzIuSrlgLkDwOl
IoiixyHNKdF1Op14uUOS8bG3Qn8/HrHS3VjvogM= )
;; ADDITIONAL SECTION:
puck.nether.net. 86400 IN A 204.42.254.5
puck.nether.net. 86400 IN AAAA 2001:418:3f4::5
black.dotat.at. 3600 IN A 131.111.11.130
black.dotat.at. 3600 IN AAAA 2001:630:212:100:646f:7461:742e:6174
black.dotat.at. 3600 IN RRSIG A 5 3 3600 (
20121217151010 20121117143125 56700 dotat.at.
ASD2mv5bJgCvope4pfPMxG9LULCOgnUEgRfpw6BIYaRi
1wGMbezO2L7e9PVPeZ6vN5Cc0T+faN5NpgT0o9aJTdSK
vRoFABIyNsPAMS41ekPL6KdAoz5vbHvplDaNBIfIXs+B
NMySjVw+K/kDFjdW2ygPaRQb8WzfCQoCUEuUc7Y= )
black.dotat.at. 3600 IN RRSIG AAAA 5 3 3600 (
20121224154647 20121124151930 56700 dotat.at.
sb5EcG/+C8PG4E5BFUVag59M9zDDwxZGAFdgnMHSacVX
2kBPoLx+O7IwyO/wanYFpW/sINojumV0NVvE48AI2Ubs
5R/YKIKwHOwgrbwXB2S86x9xGUIGljMJtN07NxbGGpKS
CDhlGH7za4Au32srZFVNu3cozq0Q20dsWKHQ3DA= )
;; Query time: 93 msec
;; SERVER: 2001:418:3f4::5#53(2001:418:3f4::5)
;; WHEN: Wed Nov 28 18:33:16 2012
;; MSG SIZE rcvd: 922
; <<>> DiG 9.9.2-vjs287.12 <<>> +norec +dnssec +bufsize=512 +ignore +multiline mx dotat.at @puck.nether.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46694
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dotat.at. IN MX
;; ANSWER SECTION:
dotat.at. 3600 IN MX 1 mx.cam.ac.uk.
dotat.at. 3600 IN RRSIG MX 5 2 3600 (
20121217120814 20121117113945 56700 dotat.at.
FLOLFiTEbnAsBka05qJK9nbY3sknNIbG2zSewoqIUkI1
fnm8PDzOB42WoAI2N4vNcQQVkd560B8hRB5a0+tLLZOB
+lz7EA1uLnqCaINJ46BOA0+hXAcAMZMbzYFfVOTN8T/K
89WkExApwdXxffi2dSGOKXAj4KuM3ryfz1g/n7g= )
;; Query time: 98 msec
;; SERVER: 2001:418:3f4::5#53(2001:418:3f4::5)
;; WHEN: Wed Nov 28 18:35:32 2012
;; MSG SIZE rcvd: 233
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
Matus UHLAR - fantomas
Nov 30, 2012, 7:30:35 AM11/30/12
to bind-...@lists.isc.org
>Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>> I know. But there are cases you just have much of data in the DNS and what I
>> am asking is, if BIND really does skip authority section, if it helps to
>> avoid sending truncated packets.
>> I know. But there are cases you just have much of data in the DNS and what I
>> am asking is, if BIND really does skip authority section, if it helps to
>> avoid sending truncated packets.
On 28.11.12 18:38, Tony Finch wrote:
>Yes it does. For example, have a look at responses to queries for dotat.at
>in mx for various buffer sizes and observe that RRsets are dropped but the
>TC bit is not set.
Nice to see. I'm seeing recommendations to set minimal-responses to avoid
>Yes it does. For example, have a look at responses to queries for dotat.at
>in mx for various buffer sizes and observe that RRsets are dropped but the
>TC bit is not set.
truncation problem anywhere and I'd like to have documented somewhere that
it just won't help...
I still can advise to test it, but official info from ISC would be the best.
I feel some people try to do that to avoid proper EDNS0 implementation...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Tony Finch
Nov 30, 2012, 10:04:00 AM11/30/12
to Matus UHLAR - fantomas, bind-...@lists.isc.org
Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>
> Nice to see. I'm seeing recommendations to set minimal-responses to avoid
> truncation problem anywhere and I'd like to have documented somewhere that
> it just won't help...
It will reduce the likelihood of a fragmented response and therefore poor
>
> Nice to see. I'm seeing recommendations to set minimal-responses to avoid
> truncation problem anywhere and I'd like to have documented somewhere that
> it just won't help...
interactions with misconfigured firewalls. But another way to avoid that
problem is to reduce the EDNS UDP buffer size.
Gilles Massen
Dec 3, 2012, 3:41:56 AM12/3/12
to bind-...@lists.isc.org
On 11/30/2012 01:30 PM, Matus UHLAR - fantomas wrote:
> On 28.11.12 18:38, Tony Finch wrote:
>> Yes it does. For example, have a look at responses to queries for
>> dotat.at
>> in mx for various buffer sizes and observe that RRsets are dropped but
>> the
>> TC bit is not set.
>
> On 28.11.12 18:38, Tony Finch wrote:
>> Yes it does. For example, have a look at responses to queries for
>> dotat.at
>> in mx for various buffer sizes and observe that RRsets are dropped but
>> the
>> TC bit is not set.
>
> Nice to see. I'm seeing recommendations to set minimal-responses to avoid
> truncation problem anywhere and I'd like to have documented somewhere that
> it just won't help...
Truncation happens only if the ANSWER section is too large, and as
> truncation problem anywhere and I'd like to have documented somewhere that
> it just won't help...
minimal-responses only affects AUTHORITY and ADDITIONAL the effect on
truncation should be null.
For UPD fragmentation it is an entirely different matter, of course. But
should default settings really be optimized to accomodate broken firewalls?
Gilles
--
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473
Matus UHLAR - fantomas
Dec 5, 2012, 7:50:24 AM12/5/12
to bind-...@lists.isc.org
>> On 28.11.12 18:38, Tony Finch wrote:
>>> Yes it does. For example, have a look at responses to queries for
>>> dotat.at
>>> in mx for various buffer sizes and observe that RRsets are dropped but
>>> the
>>> TC bit is not set.
>On 11/30/2012 01:30 PM, Matus UHLAR - fantomas wrote:
>> Nice to see. I'm seeing recommendations to set minimal-responses to avoid
>> truncation problem anywhere and I'd like to have documented somewhere that
>> it just won't help...
>>> Yes it does. For example, have a look at responses to queries for
>>> dotat.at
>>> in mx for various buffer sizes and observe that RRsets are dropped but
>>> the
>>> TC bit is not set.
>On 11/30/2012 01:30 PM, Matus UHLAR - fantomas wrote:
>> Nice to see. I'm seeing recommendations to set minimal-responses to avoid
>> truncation problem anywhere and I'd like to have documented somewhere that
>> it just won't help...
On 03.12.12 09:41, Gilles Massen wrote:
>Truncation happens only if the ANSWER section is too large, and as
>minimal-responses only affects AUTHORITY and ADDITIONAL the effect on
>truncation should be null.
I'm curious if there's any case where the AUTHORITY section is needed to
>Truncation happens only if the ANSWER section is too large, and as
>minimal-responses only affects AUTHORITY and ADDITIONAL the effect on
>truncation should be null.
proper function of DNS. I think I've seen reports about truncaetd responses
with AUTHORITY section added ... maybe intermediate firewall or
loadbalancer truncating them...
>For UPD fragmentation it is an entirely different matter, of course. But
>should default settings really be optimized to accomodate broken firewalls?
know when they cause troubles.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Mark Andrews
Dec 5, 2012, 8:13:05 AM12/5/12
to bind-...@isc.org
In message <20121205125...@fantomas.sk>, Matus UHLAR - fantomas writes:
> >> On 28.11.12 18:38, Tony Finch wrote:
> >>> Yes it does. For example, have a look at responses to queries for
> >>> dotat.at
> >>> in mx for various buffer sizes and observe that RRsets are dropped but
> >>> the
> >>> TC bit is not set.
>
> >On 11/30/2012 01:30 PM, Matus UHLAR - fantomas wrote:
> >> Nice to see. I'm seeing recommendations to set minimal-responses to avoid
> >> truncation problem anywhere and I'd like to have documented somewhere that
> >> it just won't help...
>
> On 03.12.12 09:41, Gilles Massen wrote:
> >Truncation happens only if the ANSWER section is too large, and as
> >minimal-responses only affects AUTHORITY and ADDITIONAL the effect on
> >truncation should be null.
>
> I'm curious if there's any case where the AUTHORITY section is needed to
> proper function of DNS. I think I've seen reports about truncaetd responses
> with AUTHORITY section added ... maybe intermediate firewall or
> loadbalancer truncating them...
not optional in a referral. Records added at step 6 of Section
4.3.2. of RFC 1034 are optional. Records added to the additional
section at other steps are not optional. There have been demonstated
cases of referrals failing due to not adding glue records in a
referral.
Named will produce responses with TC=1 as a result of not being
able to add records to the additional section. Every referral from
the root servers to COM or NET using plain DNS should result in
TC=1 being set.
> >For UPD fragmentation it is an entirely different matter, of course. But
> >should default settings really be optimized to accomodate broken firewalls?
>
> default or non-default, if weare behind firewall or loadbalancer, we should
> know when they cause troubles.
>
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Enter any 12-digit prime number to continue.
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Tony Finch
Dec 5, 2012, 2:05:20 PM12/5/12
to bind-...@isc.org
Mark Andrews <ma...@isc.org> wrote:
> In message <20121205125...@fantomas.sk>, Matus UHLAR - fantomas writes:
> >
> > I'm curious if there's any case where the AUTHORITY section is needed to
> > proper function of DNS.
>
> Yes. Referrals.
> In message <20121205125...@fantomas.sk>, Matus UHLAR - fantomas writes:
> >
> > I'm curious if there's any case where the AUTHORITY section is needed to
> > proper function of DNS.
>
And, (to a lesser extent) negative answers, since the negative cache TTL
comes from the SOA record in the authoruty section.
0 new messages