Skip Menu |

This queue is for tickets about the Net-DNS CPAN distribution.

Report information
The Basics
Id: 81941
Status: resolved
Priority: 0/
Queue: Net-DNS

People
Owner: Nobody in particular
Requestors: dhyan [...] nataraj.su
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: bgsend/bgread does not work correctly with long DNSKEY replys
Date: Thu, 13 Dec 2012 17:28:14 +0400
To: bug-Net-DNS [...] rt.cpan.org
From: Nikolay Shaplov <dhyan [...] nataraj.su>
It seems to me that I've found a bug with background request when used with massive DNSSEC data. It does not returns all records that were replayed by server. For now in org zone there are four DNSKEYs, if they finished a rotation change an example to a zone that has four keys in it. ========= my $server = 'a0.org.afilias-nst.info'; my $host = 'org'; while (1) { print scalar(dig_normal()),"\t", scalar(dig_bg()),"\n"; } sub dig_normal { my $res = Net::DNS::Resolver->new(nameservers=>[$server], usevc=>0); my $packet = $res->send($host,'DNSKEY'); return $packet->answer; } sub dig_bg { my $res = Net::DNS::Resolver->new(nameservers=>[$server]); my $req = $res->bgsend($host,'DNSKEY'); my $count =0; my $packet; while ($count++<10) { if ($res->bgisready($req)) { $packet = $res->bgread($req); last; } sleep 1; } return $packet->answer; } For me this example prints 4 1 4 1 4 0 4 2 4 0 4 2 4 2 4 1 4 2 4 1 4 2 4 0 The first number is a number of DNSKEY records obtained by normal request, and a second one is number of records returned by background request. Adding a sleep before bgread does not help. I am using last version of IO and last stable version of Net::DNS.
From: rwfranks [...] acm.org
Net::DNS is working as expected. The response to your query is larger than the DNS default packet size, and is being truncated at the nameserver. The "normal" query fails at the initial attempt using UDP, then falls back on TCP to obtain the full response (length 869 for your example). It is not possible to restrict send() to use UDP by setting usevc=>0. Using bgsend() uses UDP only, with no fall back to TCP. The packet is truncated by the server, which removes records to make the response no larger than 512. The number of RRs varies because the full response contains 4 RRs with two different sizes, which appear in no particular order. Use of large UDP packets is only possible by using EDNS(0) to negotiate the extended UDP packet size for each server.
Subject: Re: [rt.cpan.org #81941] bgsend/bgread does not work correctly with long DNSKEY replys
Date: Fri, 14 Dec 2012 12:53:21 +0400
To: bug-Net-DNS [...] rt.cpan.org
From: Nikolay Shaplov <dhyan [...] nataraj.su>
Show quoted text
> Net::DNS is working as expected. The response to your query is larger > than the DNS default packet size, and is being truncated at the nameserver. > > > The "normal" query fails at the initial attempt using UDP, then falls > back on TCP to obtain the full response (length 869 for your example). > > It is not possible to restrict send() to use UDP by setting usevc=>0. > > > Using bgsend() uses UDP only, with no fall back to TCP. > > The packet is truncated by the server, which removes records to make the > response no larger than 512. > > The number of RRs varies because the full response contains 4 RRs with > two different sizes, which appear in no particular order. > > Use of large UDP packets is only possible by using EDNS(0) to negotiate > the extended UDP packet size for each server.
Ah! I see! Then may be it would be good to cover this issue right in manual, in the description of bgread function or something. That would help less experienced developers (like me for example) to handle $packet->header->tc==1 situation just from the beginning, and not when they accidentally find a huge response packet. This would also prevent developers from explaining and closing stupid bugs :-) Thanks!
On Fri 14 Dec 2012 03:56:19, dhyan@nataraj.su wrote: Show quoted text
> Then may be it would be good to cover this issue right in manual, in > the description of bgread function or something.
In Net::DNS::Resolver at the end of bgsend it says: bgsend does not support the usevc option (TCP). Shall I extent the line with "Beware that truncated packets will not be retried over TCP automatically and should be handled by the caller."?
On Fri 14 Dec 2012 07:01:10, NLNETLABS wrote: Show quoted text
> Shall I extent the line with "Beware that truncated packets will not be > retried over TCP automatically and should be handled by the caller."?
I have applied this in trunk. If you have a better suggestion you can reopen the ticket by replying. -- Willem
Subject: Re: [rt.cpan.org #81941] bgsend/bgread does not work correctly with long DNSKEY replys
Date: Mon, 17 Dec 2012 12:18:17 +0400
To: bug-Net-DNS [...] rt.cpan.org
From: Nikolay Shaplov <dhyan [...] nataraj.su>
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=81941 > > > On Fri 14 Dec 2012 07:01:10, NLNETLABS wrote:
> > Shall I extent the line with "Beware that truncated packets will not be > > retried over TCP automatically and should be handled by the caller."?
> > I have applied this in trunk. If you have a better suggestion you can > reopen the ticket by replying.
I think it would be good to add to examples of bgread and bgready code if ($packet->header->tc) { warn (or even die) "The answer were too big to fit in UDP packet and were truncated by server"; } so developer would be informed that he _SHOULD_ manually control the consistency of the answer in this case And the text should be something like this: NOTE: bgread tool uses only UDP protocol to receive the answer, so big answers would be truncated due to UDP packet size limitations. Since there is no possibility to fallback to TCP request, as non-background read method do, developer should manually check truncated flag ($packet->head->tc) and properly handle the situation with incomplete data: throw an exception or repeat the request over TCP. I am not very good in writing English. But such note wold help me better understand the situation, than the phrase you offered. (Some people that uses Net::DNS might be not so good in knowing DNS internals and it is good to explain them some issues in places where it can directly effect the bugness of the code)
Thanks! The example code is an excellent idea! The note is a bit excessive tough. Too much focus on the corner cases is distracting and I believe the example code and "Beware" line make it explicit enough.
Subject: Re: [rt.cpan.org #81941] bgsend/bgread does not work correctly with long DNSKEY replys
Date: Wed, 19 Dec 2012 13:22:04 +0400
To: bug-Net-DNS [...] rt.cpan.org
From: Nikolay Shaplov <dhyan [...] nataraj.su>
Show quoted text
>> Shall I extent the line with "Beware that truncated packets will not be >> retried over TCP automatically and should be handled by the caller."?
Show quoted text
> Thanks! The example code is an excellent idea! The note is a bit > excessive tough. Too much focus on the corner cases is distracting and I > believe the example code and "Beware" line make it explicit enough.
This beware sentence does not have information that response can be truncated as an expected result, not as a result of some server, network or other errors. That is why I mentioned UDP packet size. I think developer should be warned that this truncation is common thing in this routine and _should_ be properly processed.
Hi Nikolay, On Wed 19 Dec 2012 04:25:05, dhyan@nataraj.su wrote: Show quoted text
> This beware sentence does not have information that response can be > truncated > as an expected result, not as a result of some server, network or > other > errors. That is why I mentioned UDP packet size. I think developer > should be > warned that this truncation is common thing in this routine and > _should_ be > properly processed.
Truncation is a common thing in DNS whatsoever and is not specific to these bg* methods, but I appreciate that awareness should be stimulated at this point though. How about this as the last paragraph?: *BEWARE*: bgsend does not support the usevc option (TCP) and operates on UDP only; Answers may not fit in an UDP packet and might be truncated. Truncated packets will *not* be retried over TCP automatically and should be handled by the caller. Regards, -- Willem
Subject: Re: [rt.cpan.org #81941] bgsend/bgread does not work correctly with long DNSKEY replys
Date: Wed, 19 Dec 2012 15:27:50 +0400
To: bug-Net-DNS [...] rt.cpan.org
From: Nikolay Shaplov <dhyan [...] nataraj.su>
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=81941 > > > Hi Nikolay, > > On Wed 19 Dec 2012 04:25:05, dhyan@nataraj.su wrote:
> > This beware sentence does not have information that response can be > > truncated > > as an expected result, not as a result of some server, network or > > other > > errors. That is why I mentioned UDP packet size. I think developer > > should be > > warned that this truncation is common thing in this routine and > > _should_ be > > properly processed.
> > Truncation is a common thing in DNS whatsoever and is not specific to > these bg* methods, but I appreciate that awareness should be stimulated > at this point though. How about this as the last paragraph?: > > *BEWARE*: > bgsend does not support the usevc option (TCP) and operates on > UDP only; Answers may not fit in an UDP packet and might be > truncated. Truncated packets will *not* be retried over TCP > automatically and should be handled by the caller.
Yeah. This is is good in my opinion!