--On Saturday, May 17, 2025 12:08 -0400 Donald Eastlake
<d3e3e3@xxxxxxxxx> wrote:
> The DNS protocol itself is binary clean. Bytes in labels can have
> any value. Of course this may cause problems in applications / user
> interface code or the like. And it is true that leading underscores
> and such like may, by convention be reserved. And "host" names are
> nominally supposed to start with a letter or digits and have only
> letters, digits, and hyphens. etc.
>
> The labels are length value encoded on the wire and there are only 6
> bits for length so labels are limited to 63 bytes. The label of
> length zero is reserved for the label of the root node. Labels only
> "end in a period" in their usual string representation, not on the
> wire.
+1
A few suggestions...
If one is looking for definitions of domain name syntax to reference
in a document, RFC 1035 is a better reference than 1034. It defines
a "preferred name syntax" that lies at the core of most applications
use of the DNS. It is also worth at least looking at Section 6.1.3.5
of RFC 1123 and Section 11 of RFC 2181 to get a better understanding.
While a particular application is free to define its own rules for
labels, that should be done (as those documents suggest) clearly and
with great care.
For example, if there are going to be dependencies on, or
recommendations about RFC 7542, whatever syntax rules are adopted
should be examined to determine whether UTF-8 labels are allowed or
whether IDNA ("xn--...") are needed or more appropriate.
Independent of the above, I thought there was an explicit agreement
among the IAB, IETF and assorted other parties to not add new
application uses or conventions to the ARPA. tree. The "control" of
ARPA. by the IAB mentioned in the I-D is, IIR, just the mechanism to
enforce that agreement, not an invitation to add additional
second-level domains. That issue probably should have been more
closely examined by the IAB and the community when "eap-noob.arpa."
was adopted but the fact that we have created one such second-level
domain does not imply that more of them, especially for the same
general set of protocols, are appropriate. Indeed, it may suggest
otherwise.
john
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
