Skip Menu |

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

Report information
The Basics
Id: 123676
Status: resolved
Priority: 0/
Queue: Net-DNS
People
Owner: Nobody in particular
Requestors: cstamas [...] digitus.itk.ppke.hu
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Sat Nov 18 19:47:12 2017 cstamas [...] digitus.itk.ppke.hu - Ticket created
Subject: Net::DNS::Nameserver malformed message on big axfr
Date: Sun, 19 Nov 2017 01:41:46 +0100
To: bug-Net-DNS [...] rt.cpan.org
From: Csillag Tamas <cstamas [...] digitus.itk.ppke.hu>
Hi, I created a simple code to send ixfr and axfr replies with Net::DNS::Nameserver. The basic functionality works well. When I reach a certain size dig complains about a bad packet and hungs up the connection. ; <<>> DiG 9.10.3-P4-Debian <<>> +tcp -t axfr example.com @192.168.121.139 ;; global options: +cmd example.com. 3600 IN SOA test.example.com. hostmaster.example.com. 21 10800 3600 604800 3600 example.com. 3600 IN NS test1.example.com. example.com. 3600 IN NS test10.example.com. test1000000.example.com. 3600 IN A 125.233.234.248 test100000.example.com. 3600 IN A 21.120.82.94 test200000.example.com. 3600 IN A 31.208.103.174 [...] test953100.example.com. 3600 IN A 1.1.253.193 ;; WARNING: ID mismatch: expected ID 54921, got 14 ;; Warning: query response not set ;; Got bad packet: bad label type 256 bytes [...] I have a synthetic zone with 50k records and code to reproduce the data which are here: http://cstamas.hu/priv/2017-11-19-g1Hw/ This is in kvm/qemu and i run stuff as root the distro is debian jessie. libnet-dns-perl 1.07-1 This is the script's output: root@test1:~# perl dnsserver.pl big answer prepared Creating TCP socket 192.168.121.139#53 - done. Creating UDP socket 192.168.121.139#53 - done. Waiting for connections... TCP connection from 192.168.121.12:43671 Waiting for connections... Received 42 octets from tcp:192.168.121.12:43671 Removed 2 octets from the input buffer from tcp:192.168.121.12:43671. tcp:192.168.121.12:43671 said his query contains 40 octets. query 8647 : example.com IN AXFR - Received query from 192.168.121.12 to 192.168.121.139 ;; id = 8647 ;; qr = 1 aa = 1 tc = 0 rd = 0 opcode = QUERY ;; ra = 0 z = 0 ad = 0 cd = 0 rcode = NOERROR ;; qdcount = 1 ancount = 50100 nscount = 0 arcount = 0 ;; do = 0 Queued 1347387 octets to tcp:192.168.121.12:43671 Sent 111496 of 1347387 octets to tcp:192.168.121.12:43671. Waiting for connections... Received octets from tcp:192.168.121.12:43671 Connection to tcp:192.168.121.12:43671 closed or lost. Waiting for connections... Regards, Tamas
  Sun Nov 19 15:41:38 2017 rwfranks [...] acm.org - Correspondence added
From: rwfranks [...] acm.org
On Sat Nov 18 19:47:12 2017, cstamas@digitus.itk.ppke.hu wrote: 8< Show quoted text
> root@test1:~# perl dnsserver.pl > big answer prepared > > Creating TCP socket 192.168.121.139#53 - done. > Creating UDP socket 192.168.121.139#53 - done. > Waiting for connections... > TCP connection from 192.168.121.12:43671 > Waiting for connections... > Received 42 octets from tcp:192.168.121.12:43671 > Removed 2 octets from the input buffer from tcp:192.168.121.12:43671. > tcp:192.168.121.12:43671 said his query contains 40 octets. > query 8647 : example.com IN AXFR - Received query from 192.168.121.12 > to 192.168.121.139 > ;; id = 8647 > ;; qr = 1 aa = 1 tc = 0 rd = 0 opcode = QUERY > ;; ra = 0 z = 0 ad = 0 cd = 0 rcode = NOERROR > ;; qdcount = 1 ancount = 50100 nscount = 0 arcount = 0 > ;; do = 0 > Queued 1347387 octets to tcp:192.168.121.12:43671 > Sent 111496 of 1347387 octets to tcp:192.168.121.12:43671. > Waiting for connections... > Received octets from tcp:192.168.121.12:43671 > Connection to tcp:192.168.121.12:43671 closed or lost. > Waiting for connections...
Large AXFR transfers consist of a sequence of 64K blocks. There is no logic in Net::DNS::Nameserver to fragment a large response. The necessary redesign would require substantial effort, for which there is little or no justification. Net::DNS::Nameserver is a plaything used to generate small scale responses for test purposes. It is not, and never will be, a production-grade nameserver implementation.
  Sun Nov 19 15:41:39 2017 The RT System itself - Status changed from 'new' to 'open'
  Sun Nov 19 17:56:34 2017 cstamas [...] digitus.itk.ppke.hu - Correspondence added
Subject: Re: [rt.cpan.org #123676] Net::DNS::Nameserver malformed message on big axfr
Date: Sun, 19 Nov 2017 23:56:17 +0100
To: Dick Franks via RT <bug-Net-DNS [...] rt.cpan.org>
From: Csillag Tamas <cstamas [...] digitus.itk.ppke.hu>
On Sun, Nov 19, 2017 at 03:41:39PM -0500, Dick Franks via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=123676 > > > Large AXFR transfers consist of a sequence of 64K blocks. > > There is no logic in Net::DNS::Nameserver to fragment a large response. The > necessary redesign would require substantial effort, for which there is > little or no justification. > > Net::DNS::Nameserver is a plaything used to generate small scale responses > for test purposes. It is not, and never will be, a production-grade > nameserver implementation.
Ok, got it. Could this be added to the docs then? My use case would be axfr/ixfr only. The ixfr part (because of the smaller sizes) worked well. As I heard the only working ixfr (server-side) implementation is with BIND and this could have served my use case. Regards, Tamas
  Wed Nov 29 07:57:58 2017 rwfranks [...] acm.org - Correspondence added
From: rwfranks [...] acm.org
On Sun Nov 19 17:56:34 2017, cstamas@digitus.itk.ppke.hu wrote: Show quoted text
> On Sun, Nov 19, 2017 at 03:41:39PM -0500, Dick Franks via RT wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=123676 > > > > > Large AXFR transfers consist of a sequence of 64K blocks. > > > > There is no logic in Net::DNS::Nameserver to fragment a large > > response. The > > necessary redesign would require substantial effort, for which there > > is > > little or no justification. > > > > Net::DNS::Nameserver is a plaything used to generate small scale > > responses > > for test purposes. It is not, and never will be, a production-grade > > nameserver implementation.
> > Ok, got it. Could this be added to the docs then?
Although this should be obvious from even a casual glance at the code, the Net::DNS::Nameserver documentation now contains the explicit statement that it is not a general-purpose nameserver implementation.
  Thu Dec 07 05:20:23 2017 NLNETLABS [...] cpan.org - Status changed from 'open' to 'resolved'