[net-dns-users] SOA rname as mailbox

Tue May 26 09:15:31 UTC 2015

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

-------------- 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/2e296a4e/attachment.bin>