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

Tue Apr 19 19:14:04 UTC 2016

On 04/19/2016 12:51 AM, Willem Toorop wrote:
> Hi Doug,
>
> I just want to add that I'm sorry to hear upgraded Net::DNS is causing
> you trouble.

Let's be clear. "Upgraded Net::DNS" didn't just happen, the lack of 
backwards compatibility is a direct result of decisions which you(pl) 
have made in regards to changing the format of the data as it's output 
to the caller.

That's not Ok.

I cannot emphasize this point strongly enough. Net::DNS is very old 
code. It has a huge installed base, with millions of scripts written 
against it.

The very concept of changing the data presentation format of data based 
on parameters not under the control of the caller (in this case line 
length) is horrifically bad design to start with. But even assuming that 
a rational argument could be made for doing that in new code, there are 
no circumstances where a change of this nature is Ok in a well 
established library.

I don't care what your justification is, I don't care how well 
established the new format is, I don't care. This isn't something that 
you do, ever.

Now if you think your new presentation format is awesome, or valuable, 
or whatever, that's fine .... create a NEW method for the NEW format, 
and let people vote with their feet. I'm all for innovation, and if you 
did that my only feedback would be that in over 20 years as a DNS admin 
and many tens of thousands of zones files reviewed I've never seen 
someone line wrap an A or AAAA record. But I don't care, because I'm not 
going to use that new method.

The string method however needs to be left alone ... it should return 
its data on one line, with no parens, just like it always has.

> However, it would be wise to process zone files with
> Net::DNS::ZoneFile

That's great advice, except that I'm not processing zone files.

> 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.

I am not asking for a new feature. I'm asking you to remove (or 
relocate) the incredibly wrong-headed new feature that you already added 
due to it causing significant regression in the established code base 
(and being a painfully bad idea in the first place).

Doug

> 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
>>
>
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>