I think we should align to the RFCs. First thing to note is hostnames do not have the same rules as domain names. For terminology purposes, I will use the RFC terminology: <hostname>.<domain name> RFC 952 [1] and RFC 1123 [2] define the valid strings for a hostname. A short summary is alphabet (A-Z), digits (0-9), minus sign (-) up to 255 characters. Internationalized hostnames are converted to these rules using Punycode [3]. This is also true for domain names. One of the most common differences between hostnames and domain names is underscores. Underscore is invalid in a hostname, but valid in a domain name. So, I think I am in alignment with Sean. The hostname component should return a 400 if there is an illegal character in the string, such as a period. We also should use Punycode to store/handle unicode hostnames correctly. Michael [1] https://tools.ietf.org/html/rfc952 [2] https://tools.ietf.org/html/rfc1123#page-13 [3] https://www.rfc-editor.org/rfc/rfc3492.txt On Mon, Nov 30, 2020 at 8:54 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2020-11-30 15:16:08 +0000 (+0000), Sean Mooney wrote: [...]
so that has never actully been supported, the server name has to be a hostname not a FQDN. any use of a an fqdn has never been intended to be supproted. [...] techinally you can set an fqdn in /etc/hostname but its discuraged [...]
Yes, we directly set /etc/hostname to contain the "short" hostname and set the FQDN in /etc/hosts as an alias for it bound to a (secondary) v4 loopback consistent with the default configurations for Debian/Ubuntu systems. We don't rely on hostname metadata or cloud-init to provide correct representations, as cloud providers like to mess around with things like default domains and that leads to an inconsistent experience across different environments. -- Jeremy Stanley