On 30 Jan 2018, at 16:29, Warren Kumari wrote:
There is one matter of substance (but, IMO, very minor substance!) --
the original document said that the names are of the form:
_is-ta-[key].example.com
_not-ta-[key].example.com
This works, but some implementations really don't like having A/AAA
records for names which start with an underscore... So, we are
proposing to use instead:
xm--is-ta-[key].example.com
xm--not-ta-[key].example.com
Why XM--? Well, we wanted some sort of identifier (that isn't an
underscore), and XM-- felt "similar" to XN--. A quick look through the
.com and .net zonefiles didn't show any collisions (yes, I realize
that this is a tiny slice of the namespace, but it was quick and
easy), nor did looking in various passive-dns and similar places.
Please, no. As the originator of the original
<letter><letter><hyphen><hyphen> hack, I think this is the wrong thing
to do for many reasons. The biggest one is, sadly, the fact that some
software now has <letter><letter><hyphen><hyphen> as reserved even
though it should not.
Further, it is not needed. When you say but some implementations really
don't like having A/AAA records for names which start with an
underscore", you could have easily added "...but they allow it with a
minor configuration change".
The problem you hit was in BIND. To get around it, you simply add
"check-names master warn;" to the options.
The purpose of the special label in this draft is to mark the whole name
as being used for testing. Making that more obvious with an underscore
prefix seems a lot better than making it seem like a label that would
work in a normal host name.
And if you really hate the _ and want to use
<letter><letter><hyphen><hyphen>, please do *not* use something that
will look a lot like an invalid IDN. There are plenty of other choices.
The document could really benefit from a better introduction /
explanation of how this will be used (similar to my earlier
conversational description) and integrating the comments received.
The authors intend to publish this soon.
Thanks!
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
