This is an annoying gap in the standards. If you are in a situation where you know the domain name must be fully qualified (you are a web server, say) it makes

This is an annoying gap in the standards. 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 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 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 https://www.rfc-editor.org/rfc/rfc1535.html The whatwg URL spec https://url.spec.whatwg.org/ 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&sektion=3 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&sektion=3 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.)