Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

[[e-mail] (Martin Rex)]

John C Klensin wrote:
> 
> --On Thursday, July 6, 2017 09:11 +1000 Mark Andrews
> <[e-mail]> wrote:
> 
>>...
>> And the actual presentation limit for LDH with DNS is 253
>> (encodes as 255 octets on the wire).  Remember URI names do
>> not have a final period and the each label has length octet
>> when encoded as a DNS name and the name is terminated by the
>> root label (0x00) in DNS wire form and the DNS wire name is
>> limited to 255 octets.
> 
> My apologies for nit-picking, but RFC 3986, Section 3.2.2 is
> quite clear than DNS names in URIs are permitted to have a final
> period and encouraged to do so under some circumstances.
> Specifically,
> 
> 	"The rightmost domain label of a fully qualified domain
> 	name in DNS may be followed by a single "." and should
> 	be if it is necessary to distinguish between the
> 	complete domain name and some local domain."


Also apologies from my side for nitpicking.

While I do believe that final periods on DNS names in URLs should work,
they still seem somewhat unusual, and there is a varing amount of breakage
around _matching_ DNS names with a final period to names without one
in various areas of communication protocols.

example: rfc2818 section 3.1 server endpoint identification
While _recent_ versions of Firefox & Chrome seem to no longer fail to
match them to TLS server certs, users of the blue stuff from Redmond
seem to be less lucky and still face cert hostname mismatch errors.

(but Google Chrome started delibertatly violating a MUST requirement from
 rfc2818 3.1 for certs without SANs, so name matching in Chrome _is_ broken,
 just differently broken).

There are other places where the DNS names from URLs will be placed,
e.g. TLS extension SNI client-side, TLS extension SNI server-side (virtual
hosts), HTTP Host: header fields, Cookies?, Same-origin-policies?

and I would not be surprised about more failures comparing DNS names
where one carries a final period.

-Martin