[net-dns-users] Fwd: Re: With 1.05 on OS X I'm not seeing errorstring on queries

[Dick Franks]

On 17 April 2016 at 22:11, Doug Barton <dougb at dougbarton.us> wrote:

> On 04/12/2016 05:32 PM, Dick Franks wrote:
>
>> axfr()
>>
>> Since 0.43 there has been no attempt to provide anything in errorstring.
>>
>
> My experience (which goes back well over a decade) is at odds with your
> assertion. For successful AXFRs it's filled with "unknown error or no
> error" and as far as I can tell by going back in RCS to at least 2004, it
> always has been.
>

Your experience is no match for my perl script which repeats a test using
every version from 0.12 to 1.05.
So I make my assertions without the slightest risk of contradiction.

[snip]


> Adding
>
>> RCODE: NOERROR provides no useful information because the transfer gets
>> aborted if anything else shows up in a packet header (per RFC1035, 6.3).
>>
>
> First, I'm not sure that's always been true, which is why I added the test
> I have for AXFR in the first place. Second, while it may be true that the
> transfer aborts in those circumstances now, using the RCODE to indicate
> that it was successful (as has already been done essentially since day 1)
> is good future-proofing.
>

Unconvinced.
If there is no error, there is no point in providing errorstring to explain
that there wasn't one.



>
> send()
>>
>> The proper place to test the outcome of the transaction is using
>> $result->header->rcode() which is a recognised feature of DNS protocol.
>>
>
> As I mentioned previously, that only works for the send method. It does
> not work for search or query.


Good point


> I note that errorstring has always been set (redundantly) the same as
>> rcode.  Perhaps we need to accept that as one of Net::DNS's historical
>> quirks, which probably arose from design indecision in its very early
>> history.  It is certainly present in 0.12, where hardly anything else
>> works exactly as it does now.
>>
>
> Maintaining consistency with previous code is its own value, and an
> incredibly important one. Making sure that RCODE remains available to the
> search and query methods is valuable as well.


Same point



> As with axfr(), TSIG errors get funnelled into errorstring, so there is
>> no longer any guarantee that it will be one of the usual RCODE
>> mnemonics.  Other than that, I am minded to restore the old behaviour.
>>
>
> Yay! That's a good start. :)
>
> Follows from your observation about search and query
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20160418/9fb23881/attachment.htm>