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

[Willem Toorop]

Hi Doug,

I just want to add that I'm sorry to hear upgraded Net::DNS is causing
you trouble.  However, it would be wise to process zone files with
Net::DNS::ZoneFile even if all resource records would have been on a
single line, because it also anticipates comments and $INCLUDE, $ORIGIN,
$TTL and even the non-standard $GENERATE directive.  Parsing zone files
with Net::DNS::ZoneFile will make your scripts more generic (as it can
read presentation format from other software as well).

Having that said, we could consider influencing the parameters for
presentation format (like for # columns) as a feature request.  It
requires thinking about how to do this best architecturally though, and
will not make the 1.06 release.

Kind regards,

-- Willem Toorop

Op 19-04-16 om 09:15 schreef Willem Toorop:
> Hi Doug,
> 
> The output format is simply DNS presentation format.  It is a well known
> and reasonably well defined format (already described in RFC1035 as
> "Master file" format).  It is not something which is specific for Net::DNS.
> 
> You can use the zone parsing functions of Net::DNS to read this output,
> or the output from any other software that writes DNS presentation
> format for that matter.  Have a look at the documentation of
> Net::DNS::ZoneFile.
> 
> Kind regards,
> 
> -- Willem Toorop
> 
> 
> 
> Op 19-04-16 om 08:42 schreef Doug Barton:
>> April 18 2016 10:39 PM, "Doug Barton" <dougb at dougbarton.us> wrote:
>>
>>> 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? 
>>
>> So it's actually worse than I thought. :(  The wrapping and adding of parens seems to be a function of line length, not record type. There are DS records in the root zone that don't trigger the wrapping, and there are AAAA records in the root zone that do:
>>
>> d.xn--node.globalanycastcloud.freenom.net.	172800	IN	AAAA	( 
>> 	2a04:1b00:b::4 )
>>
>> dns1.u-registry.com.	172800	IN	AAAA	( 
>> 	2604:4300:a:8c:5054:ff:fe47:8582 )
>>
>> Can we please remove this ill-advised change altogether? When processing these records it magnifies my code complexity significantly if I have to test every record for the presence of newlines, join them if they are present, extract patterns with and without parens, etc. I can absorb the development cost of testing for two different  DS record formats because the new format is a legitimate improvement. But having to deal with the multiline/paren issue appearing at random for certain (all?) record types is not Ok.
>>
>> Doug
>> _______________________________________________
>> net-dns-users mailing list
>> net-dns-users at nlnetlabs.nl
>> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>>
> 
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>