Lacking the trailing dot that anchors the FQDN to the root zone, how would I be able to determine that I need to use the global root zone rather than local lookups? The DNS spec allows users to have local zones named similarly to all TLDs, which would be authorative responders for DNS requests that don't anchor to the root with a trailing dot - or have I missed something?
You are completely right - but this distinction is just dead today. I read a lot of technical documentation that involves FQDNs and they almost never include a dot. Adding the dot often leads to problems as example.com and example.com. will not be normalized. End users also are just befuddled when they encounter the extra dot.
On practice, instead of trying to follow a dead specification it makes your live easier to never use local zones and always use FQDN search domains if you can. Having a local zone that appears in the public suffix list is outright dangerous, and with how fast that grows, no local name is safe.
not only this, if webservers can treat both versions as the same, and if in fact the specification treats them as the same, then so should search engines. if there is a problem, then the search engines are at fault. it seems ridiculous that i have to configure a webserver to add a redirect in order to avoid this. actually i think this is something that could also be fixed in the browser. i just checked, firefox treats them as separate domains. i don't think it should.
in practice of course this is not a problem because nobody really puts a trailing dot on hostnames.
I would also expect search engines to (a) ~never end up on a URL with a dot, unless someone explicitly linked to one, (b) merge the two sites on their end if they appeared.
A lot of people learn about things like this configuring DNS servers.
If you're setting up bind and forget a trailing dot, it is quite easy to get extra weird resolver queries like foo.com.example.com before foo.com is resolved.
The web has never coherently dealt with the trailing dot issue. Roughly the only standard that makes a clear requirement is for TLS PKIX certificates, which cannot have a trailing dot. So to avoid certificate matching bugs it’s best to redirect a trailing-dot domain to a no-trailing-dot domain. Sadly web servers do not make this easy, and traditionally they encourage configurations that do unpredictably wrong things with requests that have trailing-dot domains. It sucks.
I also think it is interesting. I didn't want to dismiss it - content marketing can still contain valuable information, that's the whole point of it after all.
This article, and the article linked upthread, is giving a novel definition of FQDN.
https://en.wikipedia.org/wiki/Fully_qualified_domain_name
https://datatracker.ietf.org/doc/html/rfc1594#section-5
The trailing dot (root zone) is implicit in a Fully Qualified Domain Name. The trailing dot is not what makes a domain name fully qualified.
Lacking the trailing dot that anchors the FQDN to the root zone, how would I be able to determine that I need to use the global root zone rather than local lookups? The DNS spec allows users to have local zones named similarly to all TLDs, which would be authorative responders for DNS requests that don't anchor to the root with a trailing dot - or have I missed something?
You are completely right - but this distinction is just dead today. I read a lot of technical documentation that involves FQDNs and they almost never include a dot. Adding the dot often leads to problems as example.com and example.com. will not be normalized. End users also are just befuddled when they encounter the extra dot.
On practice, instead of trying to follow a dead specification it makes your live easier to never use local zones and always use FQDN search domains if you can. Having a local zone that appears in the public suffix list is outright dangerous, and with how fast that grows, no local name is safe.
Is duplicate content really a problem for search engines? I thought you just have to set the canonical URL and it’s ok.
not only this, if webservers can treat both versions as the same, and if in fact the specification treats them as the same, then so should search engines. if there is a problem, then the search engines are at fault. it seems ridiculous that i have to configure a webserver to add a redirect in order to avoid this. actually i think this is something that could also be fixed in the browser. i just checked, firefox treats them as separate domains. i don't think it should.
in practice of course this is not a problem because nobody really puts a trailing dot on hostnames.
I would also expect search engines to (a) ~never end up on a URL with a dot, unless someone explicitly linked to one, (b) merge the two sites on their end if they appeared.
A lot of people learn about things like this configuring DNS servers.
If you're setting up bind and forget a trailing dot, it is quite easy to get extra weird resolver queries like foo.com.example.com before foo.com is resolved.
On this topic, I believe it's obligatory to bring up JdeBP's comment: http://jdebp.info./FGA/web-fully-qualified-domain-name.html
The web has never coherently dealt with the trailing dot issue. Roughly the only standard that makes a clear requirement is for TLS PKIX certificates, which cannot have a trailing dot. So to avoid certificate matching bugs it’s best to redirect a trailing-dot domain to a no-trailing-dot domain. Sadly web servers do not make this easy, and traditionally they encourage configurations that do unpredictably wrong things with requests that have trailing-dot domains. It sucks.
Chris Siebenmann blogged this, 2 months ago: https://utcc.utoronto.ca/~cks/space/blog/tech/DomainDotAtEnd...
This is a commonly used attack vector by threat actors to get around various defenses.
This reminds me of how you can use different bases for urls. Take http://3520653007/item?id=41982974 or http://032166163317/item?id=41982974 for example
For anyone wondering, this is just the IP address written in a different form: https://stackoverflow.com/a/56814434
Adding this dot used to be a way to bypass the paywall on nytimes.com. It's been fixed in the last 2 years or so.
Don't leave it out in your named config files!
This seems to be content marketing for their company.
I found it fascinating.
I also think it is interesting. I didn't want to dismiss it - content marketing can still contain valuable information, that's the whole point of it after all.
[flagged]