[net-dns-users] SOA rname as mailbox

Tue May 26 10:52:49 UTC 2015

On 26 May 2015, at 12:34, Willem Toorop <willem at nlnetlabs.nl> wrote:

> Signed PGP part
> Please!
> 
> We *are* listening to this list!  We will always post a release
> candidate before doing an actual release to this list for review.
> 
> Before we also did release candidates, only not via the list, but via
> developers releases on CPAN and via the website.  This did (obviously)
> not give us the desired feedback, so I have tried to inventory all
> developers of packages using Net::DNS and invited them personally to
> this list to improve on this situation.  Another step we have done to
> improve is that we release far more often and with smaller changes
> then before.
> 
> Net::DNS might never have given the lower level controls you needed
> for zonemaster.  Before it might have given the (wrong) impression
> that it did though.  For example with the writeable section counters
> in the header that were silently ignored.
> 
> ldns also has an intermediate (interpreted) host format b.t.w., though
> its rdata field structures are closer to the wire-format data than
> those of Net::DNS yes.  If you really want more finer-grained control
> to lower-level DNS, at the wire format, but also at the network and
> I/O level, you might give getdns a go; though perl bindings are still
> in the make.
> 
> Debugging DNS is not the only use case for Net::DNS.  There are also
> many application that use Net::DNS not to debug DNS, but to get to
> specific records and to do DNSSEC validation at the application level.
> 
> The SOA->rname change has been a mistake because it broke previous
> behaviour.  At the time I deemed it a minor issue and safe because the
> returned value was an parsed and formatted one anyway; and it did not
> affect the reading and writing of presentation format.  We will make
> sure to never break this way again or at least communicate very clear
> and loudly about it on this list beforehand.   We will listen and act
> on objections from the list.  The list was created for this very purpose.
> 
> — Willem

Thank you Willem. 

Parts of what you mention above added to the problem as we got errors from different distributions along the way as they changed which version of Net::DNS they chose to package so maintenance was getting harder, when it comes to flags and release notes and what was done and what wasnt; it’s over my head really... But this last confirmation that you will listen to the list before changing the API again is very, very welcome. Thanks again and I do apologize if I was rude; I just felt a bit ignored, I think many of us did. ;P

	/Regards, Einar

> Op 26-05-15 om 11:15 schreef Einar Lönn:
> > Also considering that basically every single user on this list
> > wants a tool that can be used to debug DNS and not a fancy tool
> > that does all the work for you I’m a bit sad that you let pride
> > guide the project instead of actual user needs and requests. I dont
> > think anyone, not one single user, has requested or wanted this
> > change and when we (the users) try and tell you so you basically
> > tell us how wrong we are.
> >
> > It’s tiresome to have Net::DNS version ranges in our code and it’s
> > even more tiresome when the maintainer(s) try and justify these
> > changes. We created Net::LDNS for our new projects as we didnt like
> > this user-unfriendly approach.
> >
> > /Regards, Einar
> >
> > On 25 May 2015, at 20:33, Chris Buxton <clists at buxtonfamily.us>
> > wrote:
> >
> >> Dick,
> >>
> >> Let me pose this question: This field of the SOA record is
> >> informational, and often (in the real world) doesn't lead to an
> >> actual functioning email address. When dealing with DNS records,
> >> how often does a script actually need this value in email address
> >> format? Compare that with the frequency of needing this in DNS
> >> domain name format, the way it is represented in DNS messages. I
> >> believe you will find that the latter need is far more prevalent
> >> than the former.
> >>
> >> Now consider that you are doing extra work to decode this value,
> >> which is basically never needed, and then asking the script
> >> writer to do extra work to convert it back again. As you said,
> >> it's an inconsequential amount of work in terms of execution time
> >> (though not inconsequential in terms of coding time), but given
> >> how infrequently anyone actually cares about the semantic meaning
> >> of this field, vs. simply wanting to accurately record the fields
> >> of an SOA record, it seems counterintuitive that the module would
> >> behave this way.
> >>
> >> And of course, there is the matter that it used to behave
> >> differently. My scripts broke in the 0.69 update. That bothered
> >> me. I rewrote them to stop using the (IMO broken) new behavior,
> >> and now use the SOA object's string method followed by 'split' to
> >> obtain the fields in DNS format.
> >>
> >> I don't understand why this matters to you so much. There's an
> >> easy conversion routine, so rather than break the API, it would
> >> have been better to simply advertise that you have a handy
> >> conversion routine available for those who want to work with the
> >> data in email address format. At this point, obviously, you risk
> >> breaking scripts either way, because you've allowed the situation
> >> to remain for so long, but I think it's pretty clear the change
> >> in 0.69 was a mistake.
> >>
> >> That's my opinion. I'll get off my soapbox now.
> >>
> >> Regards, Chris Buxton
> >>
> >>> On May 21, 2015, at 11:48 AM, Dick Franks <rwfranks at acm.org>
> >>> wrote:
> >>>
> >>>
> >>> On 19 May 2015 at 09:38, Doug Barton <dougb at dougbarton.us>
> >>> wrote: On 5/18/15 5:30 PM, Dick Franks wrote: All of this was
> >>> discussed at length on this list in 2012/2013
> >>>
> >>> Yes, and some of us told you at the time that while your
> >>> reasoning was air tight, and self-consistent; the resulting
> >>> change did not meet our needs.
> >>>
> >>> The air tight and self-consistent reasoning was founded on a
> >>> careful analysis of RFC1035. The present implementation of
> >>> Net::DNS got where it got by following that reasoning.
> >>> Analysis and air tight reasoning are investments with a
> >>> long-term yield in the form of design stability.
> >>>
> >>> The pre-0.69 implementation was not based on a sound analysis
> >>> of RFC1035, which is regrettable but these things happen.  This
> >>> is the only flaw in Michael Fuhr's original vision.
> >>>
> >>>
> >>> For example, the obvious, glaring exception to your statement
> >>> that "There is absolutely nothing useful you can do with the
> >>> wire-format domain name representation" is that you can, and
> >>> often need to, stuff it into a data store that will be used by
> >>> something other than Net::DNS to generate zone files down the
> >>> road.
> >>>
> >>> It is certainly arguable that RFC1035 was wrong in not using
> >>> RFC822 for the SOA RNAME field in zone file format. This is a
> >>> mistake we all have to live with.  The need to jump through
> >>> hoops to convert mail addresses into domain names is a direct
> >>> consequence of that mistake. The need to do so arises from
> >>> *your* design decision about what to stuff in *your* data
> >>> store.
> >>>
> >>>
> >>> So while it makes perfect sense to have a way to generate 822
> >>> format from Net::DNS, and it might even make sense to have that
> >>> be the default,
> >>>
> >>> RFC822 format is the primary representation of entities that
> >>> claim to be a mail address.  The wire-format and domain name
> >>> representations are encodings of that primary representation.
> >>>
> >>>
> >>> it ALSO makes sense to have a way to get the wire format
> >>> without having to jump through insane hoops to do so. ... and
> >>> just to save you time, no, it does not make sense for Net::DNS
> >>> to decode the wire format, then have the other system re-encode
> >>> it.
> >>>
> >>> We will have to agree to differ about what does, or does not,
> >>> make sense.
> >>>
> >>> The conversion can be done in a single line.  The computational
> >>> cost is insignificant compared with the cost of resolving the
> >>> SOA record.
> >>>
> >>> use Net::DNS::Mailbox;
> >>>
> >>> my $email = 'John.Doe at example.com';
> >>>
> >>> my $name = new Net::DNS::Mailbox($email)->string;  # zone file
> >>> format
> >>>
> >>>
> >>> The attractions of doing things this way are: 1) The conversion
> >>> will forever remain in sync with current understanding of
> >>> RFC1035 and RFC822 et seq. 2) If you discover any example which
> >>> violates the RFCs, I agree to let you kick me until it is
> >>> fixed. 3) The conversion accepts both RFC822 and the domain
> >>> name encoded format, so there is no need to check which you
> >>> have.
> >>>
> >>>
> >>> -- Dick
> >>>
> >>> _______________________________________________ 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
> >
> 
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150526/51f6de8e/attachment.bin>