[net-dns-users] Release candidate for Net::DNS 1.06

[Dick Franks]

On 19 April 2016 at 06:38, Doug Barton <dougb at dougbarton.us> wrote:

> This is better in some ways, and worse in others. :)
>
> The errorstring is being filled again for search/query/send, which is
> great. :)



  However the errorstring for AXFR is now empty (not undefined, there is
> actually a string there, but it seems to be one, or maybe two spaces.


If you are going to persist with this argument, at least do us the courtesy
of citing verifiable facts.

        my $resolver = Net::DNS::Resolver->new();
        $resolver->nameserver('185.49.140.63');`
        $resolver->domain('net-dns.org');

        my @zone = eval { $resolver->axfr() };
        print scalar(@zone), "\n";
        my $errorstring = $resolver->errorstring;
        print length($errorstring), "\t$errorstring\n";

produces

        2648
        0



> This is a regression against both 1.05 and versions previous to the
> errorstring nuking (1.04?).  The demo script I sent to the list previously
> can demonstrate the problem. Also the output from that script that I sent
> along with it shows the previous output for errorstring after AXFR for both
> 1.05 and 0.81.
>

0.81

        2648
        25    unknown error or no error

axfr() did not modify errorstring in any way at all.
It is easy to demonstrate that if other values occur in errorstring they
were left over from a previous query, which is downright unhelpful.

Worse, the documentation implied that errorstring() relates to axfr(),
which it clearly does not, and never did.


Today I also identified another problem with the way that DS records are
> printed that was also present in 1.05 release. In previous versions (for
> example 0.81 that I'm using on Ubuntu) The DS records were formatted like
> this when they were printed out using $rr->string:
>
> aaa.    86400   in      ds      \# 24
> 54cb08016d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2X
>

Because Net::DNS::SEC was not installed.

The DNSSEC RRs were moved into Net::DNS to allow users to see intelligible
data, even if they have no intention of doing signing or validation.


I can certainly see how this is suboptimal, and the new format is better,
> but the problem is that it has a newline embedded:
>
> aaa.        86400   in      ds      ( 21707 8 1
>         6d92dd0d0db0e392fa9d5f08ea15bbd297b8cbe2 )
>
> Can we get this in one line? It makes it a whole lot easier to process.
> (FWIW, the print method has the same issue)
>
And in the future can we avoid newlines in the data?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20160419/8afb125f/attachment.htm>