On Mon, Jun 27, 2022 at 04:31:25PM -0600, Peter Saint-Andre wrote:
> >> I'm not necessarily saying that - I'm saying only that Jeff and I tried
> >> to find a canonical definition of "fully-qualified domain name" and the
> >> best we could do was RFC 1034. Alternative proposals are welcome.
> >
> > There are only two possible answers:
> >
> > - All DNS names are valid, so long as they have a wire form that
> > meets the requirements of RFC 1034.
> >
> > - Only names that comply with section 2.1 of the Host Requirements RFC:
> >
> > https://datatracker.ietf.org/doc/html/rfc1123#page-13
> >
> > are valid. These are LDH forms, whose labels therefore require no
> > special processing in presentation form, and so the limits are at
> > most 63 octets per label, and at most 254 bytes total (allowing for
> > an extra byte for the final 0 length wire-form label).
> >
> > In LDH form the hyphens must not be the first or last character of
> > any label. Names starting with "xx--" for various values of "xx"
> > are special reserved forms with (IIRC) "xn" being the only presently
> > defined prefix, but I don't think that it is appropriate for the
> > present document to delve into this level of detail.
> >
> > The host requirements RFC further recomments staying under 63 bytes,
> > and though this is somewhat dated, it is nevertheless prudent if
> > possible.
>
> RFC 6125 (and now 6125bis) are not documents about the definition or
> enforcement of DNS naming rules, only about client-side matching of
> service identifiers presented in X.509 certificates against the client's
> conception of what the service ought to be (i.e., against a reference
> identifier). I see no reason to expand the scope of 6125bis in the
> direction you might be proposing. Thus I would favor the first option above.
Note, I was not proposing anything for 6125bis. Rather, I was just
responding to the posted question of what *might be* the definition
of a (DNS) FQDN.
One might however make a reasonable case that if DNS names in DNS
subject alternative names are not constrained to RFC 1123 Section 2.1
LDH names, then their representation in DNS-ID values is of course
constrained to "7-bit" (IA5String) characters and needs to use DNS
presentation form escaping rules for at least some special characters.
At a minimum "." and "\" may need to be escaped, as "\." and "\\". Other
"special" IA5 characters could arguably be rendered verbatim, but better
I think also escaped, probably via "\DDD" decimal escapes for control
characters, <DEL>, punctuation, double-quotes and whitespace.
The above is perhaps not terribly appealing, and interoperability for
escaped forms would likely be limited. So non-LDH names could
reasonably be "discouraged".
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
