No, dots do not necessarily correspond to zone cuts. The most common counterexample is the IPv6 reverse DNS, but you can also see it in (eg) www.dns.cam.ac.uk which has only three zone cuts.
When it comes to certificates, the specification explicitly says that only www.something.example is correct† even if in DNS terms that should be www.something.example.
Thus it's misissuance (ie against the rules, you'd need to stop doing it or risk being distrusted) to issue that site a certificate for "www.something.example." instead of (or as well as) "www.something.example" and I'd guess that since we have CT (and thus can see mistakes in almost real time) nobody does that.
Of course a web browser could, AFAIK just accept that www.something.example is the correct name to see in the certificate, it seems Firefox at least does that and perhaps all popular browsers do.
Unfortunately the web server also needs to understand how this works and the linked site reports that (at least when it was written) Apache httpd doesn't. That wouldn't surprise me, Apache httpd was probably a great web server a quarter century ago, but not today.
† I think it's in PKIX somewhere? I might be wrong about exactly where it is, but it's something people have thought about and decided will be settled to work the way it actually does in practice today and too bad if we don't like that.
Google/gmail had a bug where if you changed the page to a trailing dot and logged out, it would "log out" but the non-dot version would stay logged in if you navigated back.
Report was dismissed as a non-issue, if i recall. The Edge browser team at least seemed interested when reporting a separate dot-handling issue
I remember a tester reporting a weird issue a couple of years ago - turns out he accidentally had a a trailing . in the URL and as a result login wasn't working (I think there was CORS code that was checking the base domain that didn't account for the trailing .).
Ah! That sounds like a fun bug that makes you scratch your head.
Reminds me of one a few months ago. I was reviewing a weird bug that our QA team found with phone regexes, if the phone number started I think with a 1, and it had all 1's if you typed anything else, it would wipe it all out, turns out area codes in the US never begin with 1 or 0, so regexes will wipe it out since its invalid.
If you are in a situation where you know the domain name must be fully qualified (you are a web server, say) it makes sense to canonicalize the domain by removing any trailing dot.
And so software that handles URLs has to cope with unqualified or partially-qualified domain names and the associated ugly problems with resolver search paths. https://www.rfc-editor.org/rfc/rfc1535.html The whatwg URL spec https://url.spec.whatwg.org/ doesn’t simplify; it insists that FQDNs with and without trailing dots are different.
What is missing is a clear specification of how resolver APIs should handle partially qualified domain names (wrt search paths and number of dots etc.) and how to turn a name into a fully-qualified domain name. User interfaces such as browser URL bars should use this to canonicalize hosts in URLs.
I would prefer to restrict partially-qualified names to simple single-label unqualified hostnames. This restriction means anything with a dot can be assumed to be an FQDN, so you don’t need to talk to the resolver to canonicalize it. Dunno how upset people would be at forbidding dots in partially-qualified names.
Turning a hostname into a fully-qualified domain name is more tricky. A name’s FQDN is not the same thing as its canonical name, as returned by getaddrinfo https://man.freebsd.org/cgi/man.cgi?query=getaddrinfo&sektio... - ai_canonname is the last name in the CNAME chain, which is often some artifact of how the server is provisioned. (eg, www.apple.com -> e6858.dscx.akamaiedge.net for me just now.) Instead, you (or rather the stub resolver) get the FQDN by appending each of the stub resolver’s search domains to the unqualified name in turn, until a DNS lookup succeeds; the FQDN is the name the stub resolver successfully queried for. You can’t get this from getaddrinfo. The old resolver API https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&sekt... returns a list of aliases, which I think you can use to get an FQDN, though it might be confusing if the result comes from /etc/hosts instead of the DNS.
For added fun, there are situations such as mail domains where a trailing dot is forbidden, so it isn’t possible to disambiguate between fully-qualified and partially-qualified domains. The consensus in the mail world is basically that mail domains should only be FQDNs, which is a fairly solid solution. (There was also a mistake when the grammar was revised for RFC 2821 that required at least one dot in a mail domain, which made it even harder to send mail to the few ccTLDs with joke MX records.)
15 comments
[ 762 ms ] story [ 1090 ms ] threadEach dot before that trailing dot is also an authoritative name server(s).
* https://en.wikipedia.org/wiki/Root_name_server
Go down to "DNS Zone Cut" section:
https://egbert.net/blog/articles/dns-dnssec-private.html
There are 13 root servers (operated by 12 different organizations).
You don't have to have zone cuts at each dot.
http://microsoft.com./ is a 404 for instance. http://google.com./ redirects. https versions often give certificate errors.
Thus it's misissuance (ie against the rules, you'd need to stop doing it or risk being distrusted) to issue that site a certificate for "www.something.example." instead of (or as well as) "www.something.example" and I'd guess that since we have CT (and thus can see mistakes in almost real time) nobody does that.
Of course a web browser could, AFAIK just accept that www.something.example is the correct name to see in the certificate, it seems Firefox at least does that and perhaps all popular browsers do.
Unfortunately the web server also needs to understand how this works and the linked site reports that (at least when it was written) Apache httpd doesn't. That wouldn't surprise me, Apache httpd was probably a great web server a quarter century ago, but not today.
† I think it's in PKIX somewhere? I might be wrong about exactly where it is, but it's something people have thought about and decided will be settled to work the way it actually does in practice today and too bad if we don't like that.
Report was dismissed as a non-issue, if i recall. The Edge browser team at least seemed interested when reporting a separate dot-handling issue
Reminds me of one a few months ago. I was reviewing a weird bug that our QA team found with phone regexes, if the phone number started I think with a 1, and it had all 1's if you typed anything else, it would wipe it all out, turns out area codes in the US never begin with 1 or 0, so regexes will wipe it out since its invalid.
Here's a corrected submission:
https://news.ycombinator.com/item?id=39773646
(TIL that HN doesn't canonicalize the hostname in submissions for de-duplication purposes.)
If you are in a situation where you know the domain name must be fully qualified (you are a web server, say) it makes sense to canonicalize the domain by removing any trailing dot.
The article cites RFC 1738 https://www.rfc-editor.org/rfc/rfc1738#page-6 which specified that a host name in a URL must be a fully qualified domain name. RFC 3986 https://www.rfc-editor.org/rfc/rfc3986#page-21 is much more relaxed: it doesn’t have to be fully qualified, or even a domain name – it could be a NETBIOS name, for example.
And so software that handles URLs has to cope with unqualified or partially-qualified domain names and the associated ugly problems with resolver search paths. https://www.rfc-editor.org/rfc/rfc1535.html The whatwg URL spec https://url.spec.whatwg.org/ doesn’t simplify; it insists that FQDNs with and without trailing dots are different.
What is missing is a clear specification of how resolver APIs should handle partially qualified domain names (wrt search paths and number of dots etc.) and how to turn a name into a fully-qualified domain name. User interfaces such as browser URL bars should use this to canonicalize hosts in URLs.
I would prefer to restrict partially-qualified names to simple single-label unqualified hostnames. This restriction means anything with a dot can be assumed to be an FQDN, so you don’t need to talk to the resolver to canonicalize it. Dunno how upset people would be at forbidding dots in partially-qualified names.
Turning a hostname into a fully-qualified domain name is more tricky. A name’s FQDN is not the same thing as its canonical name, as returned by getaddrinfo https://man.freebsd.org/cgi/man.cgi?query=getaddrinfo&sektio... - ai_canonname is the last name in the CNAME chain, which is often some artifact of how the server is provisioned. (eg, www.apple.com -> e6858.dscx.akamaiedge.net for me just now.) Instead, you (or rather the stub resolver) get the FQDN by appending each of the stub resolver’s search domains to the unqualified name in turn, until a DNS lookup succeeds; the FQDN is the name the stub resolver successfully queried for. You can’t get this from getaddrinfo. The old resolver API https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&sekt... returns a list of aliases, which I think you can use to get an FQDN, though it might be confusing if the result comes from /etc/hosts instead of the DNS.
For added fun, there are situations such as mail domains where a trailing dot is forbidden, so it isn’t possible to disambiguate between fully-qualified and partially-qualified domains. The consensus in the mail world is basically that mail domains should only be FQDNs, which is a fairly solid solution. (There was also a mistake when the grammar was revised for RFC 2821 that required at least one dot in a mail domain, which made it even harder to send mail to the few ccTLDs with joke MX records.)