On 6/28/22 8:14 AM, Viktor Dukhovni wrote:
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.
Noted. :-)
Rather, I was just
responding to the posted question of what *might be* the definition
of a (DNS) FQDN.
It doesn't seem to be well-defined anywhere. We could, of course, simply
remove the phrase from 6125bis, but it's in common use and I suspect
that removing it could cause more confusion.
Peter
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
