<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><span></span></div></div></div>
<br><div class="gmail_quote">On 19 April 2016 at 08:51, Willem Toorop <span dir="ltr"><<a href="mailto:willem@nlnetlabs.nl" target="_blank">willem@nlnetlabs.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Doug,<br>
<br>
I just want to add that I'm sorry to hear upgraded Net::DNS is causing<br>
you trouble.  However, it would be wise to process zone files with<br>
Net::DNS::ZoneFile even if all resource records would have been on a<br>
single line, because it also anticipates comments and $INCLUDE, $ORIGIN,<br>
$TTL and even the non-standard $GENERATE directive.  Parsing zone files<br>
with Net::DNS::ZoneFile will make your scripts more generic (as it can<br>
read presentation format from other software as well).<br>
<br>
Having that said, we could consider influencing the parameters for<br>
presentation format (like for # columns) as a feature request.  It<br>
requires thinking about how to do this best architecturally though, and<br>
will not make the 1.06 release.<br></blockquote><div><br></div><div>I will be happy to fix contraventions of RFC1035, if there are any.<br><br></div><div>There is no architectural issue with increasing the line length parameter, but line folding is still going to happen with long RRs.  Folds only occur between RDATA elements, which in practical terms means that short elements are grouped on a line and long elements occupy a whole line.  The end result is remarkably insensitive to the line length parameter except in those rare cases where there is a long sequence of short elements.<br></div><div><br><br></div></div><br></div></div>