Can I have dots in a hostname?

Question

I'm using names like "a.alpha" for the hostname of my linux box, but it seems that these names are not completely usable. The response of a hostname shell command is correct (a.alpha). But the name printed after my user account is "user@a" instead of "[email protected]". When I use avahi, I can reach (by hostname) "a.alpha", but not "b.alpha". Is that normal?

Solution 1

Chopper is right. Due to how DNS works, the "alpha" component of "a.alpha" is considered a discrete 'label' in DNS. Using a hostname with a dot in it will cause inconsistent results from any system that consumes DNS.

Avahi does interact with DNS names, and specifically the <host-name> directive needs to have the DNS FQDN of the service in it, so it's also subject to DNS inconsistency with dotted names.

Don't use dotted name.

Solution 2

You're asking for trouble with that naming scheme due to DNS, consider a-alpha instead.

Solution 3

As other people have mentioned, you definitely want to avoid dots in your hostnames due to DNS, and I also found that this can give a problem if you are using wildcard certificates to perform SSL, as wildcard certs will only wildcard for one level of a subdomain. So if your wildcard cert is for *.mycompany.com, but you have a hostname that is a.alpha, the wildcard cert might not work if it treats "alpha" as a subdomain.

Solution 4

A host's full hostname IS typically the domain-equipped FQDN (fully qualified domain name), and in linux should end up being the output of host --fqdn, with the part before the first dot being regarded as the host's nickname. However, different systems (Linux, SunOS, whatever) have implemented the "hostnick" concept in various ways. Such as:

• /etc/hostname contains just the hostnick, and the rest is in /etc/domainname
• /etc/hostname contains the entire FQDN, and the domain is also in /etc/domainname
• Domain name only exists in the YP/NIS configuration
• Domain name only exists in certain subsystems instead of being a system global
• (other, generally weirder approaches)

Additionally, the idea of a hostnick is a little variable:

• The part of the FQDN before the first dot
• Some left-side portion of the FQDN, expressed exclusively without a trailing dot
• The part of the FQDN before the actual domainname (as set somewhere)

And, to further complicate things, the host command from bind9-host violates DNS standards by having a -N <int> option to control whether or not search domains are used. This breaks DNS lookups in various ways depending on the scenario. DNS is supposed to take any lookup for a name with a trailing dot as being literally what to look up, and for other names, to look them up with appended domains from the /etc/resolv.conf until a match is found or they all fail (those domains implicitly have a trailing dot). [This is from memory, please comment if the general process got changed in an RFC I missed]

As such, if you use dots in your hostnick, the host command will probably botch thing, breaking scripts that use it for lookups. I personally find it unfathomable that host is broken, and it appears to even today be breaking a lookup on a system in my home network, since I have both IPv4 and -v6 at home, and have names like .v4. as extra, version-specific short forms, which host fails to lookup even though ping finds them just fine.

It was extremely rare to attempt to put dots in hostnicks anyway, so even without host's braindamage, I would have recommended sticking to dotless hostnicks even from a simple semantics perspective.

Solution 5

The correct answer definitely "don't do that", as stated above.

For some possibly useful and definitely tangential reading, please continue:

Are you talking about dns resolution or your command line prompt? If you want to fix your command line prompt, just fiddle with $PS1 (or similar non-bash/sh equivalent where applicable).

If you really want to have a.alpha be a hostname that resolves to an IP address on the interwebs, you can do it, but that might involve a subdomain for each hostname suffix (EG alpha, beta etc..).

It's even possible that you could configure your DNS server to work without making subdomains. You can serve the IP address of the name servers of a subdomain in the zone files of the parent domain, so it might "just work". This is because when someone asks your DNS server for the IP address of a.alpha.examaple.com, they ask the DNS server for example.com, and if that DNS server has the address already hanging around, it will respond with the answer, rather than trying to hand you over to the subdomain's authoritative server. It might get horked up around the missing SOA... so maybe you add an A record for each host prefix and and an SOA for each host suffix. Yeah, that's the ticket...

Everything on the internet will still think your hostname is 'a', and your domain is alpha.example.com.

View more solutions

Comments

[benzen]

I'v ask the same question on askubuntu, and no one can answer me nether. So i will use this method

[Alex Egli]

This is correct, but needs references to be considered a reliable answer. Someone saying 'Due to how DNS works' on Stack Overflow doesn't prove anything.

[Dinesh Kumar P]

Is it rigid rule that hostname cannot contain '.' ?

[Deb]

@DineshKumarP Yes. The DNS RFCs describe the period character as the delimiter between DNS labels. While non-DNS services such as Avahi or SLP may allow it, DNS itself does not.

[Tony Garnock-Jones]

This is not quite right. DNS is perfectly happy to allow dots in labels, though it does suggest conformance to a restricted syntax (the "LDH rule"; see tools.ietf.org/html/rfc1035#section-2.3.1). Applications of DNS -- such as storing host names in DNS -- are where restrictions on DNS label syntax come into play.