So, it's to be able to indicate that we wrote a FQDN, otherwise the DNS client, if it has a local search path, will check if it's a relative domain first.
I have to admit it's technically a benefit, but if you have a search path that resolves FQDNs as relative domains, isn't half of your software broken anyway? I can't say I've ever seen a FQDN with a dot at the end on any hardcoded or default value.
> but if you have a search path that resolves FQDNs as relative domains, isn't half of your software broken anyway
That’s correct, but it shouldn’t be that way.
I should be able to have google.com resolve to google.com.local.kuschku.de in my resolver, without issue, and the actual website should use google.com.
The fact that we don’t do that today breaks many parts of the original DNS and URL RFCs.
DNS software has absolute domain names in config files. In BIND zone files you have entries like "IN NS ns1.example.com." specifying the nameserver for the domain.
I bet some software implicitly uses absolute domains. URLs are just specified not to work like that.
I have to admit it's technically a benefit, but if you have a search path that resolves FQDNs as relative domains, isn't half of your software broken anyway? I can't say I've ever seen a FQDN with a dot at the end on any hardcoded or default value.