I had an interesting support ticket yesterday.
Someone was trying to do an apt-get update via BitFolk‘s apt cache and was ending up connecting to 2607:f0d0:1003:85::c40a:2942, where it was failing to update. This is not a BitFolk IPv6 address, nor is it the IPv6 address of a Debian mirror. Where was it coming from?
I’d asked the customer for the contents of a bunch of config files and output of the dig command, and while I was waiting for that I mentioned the problem on IRC, where Graham said:
<gdb> $ dig -t aaaa +short apt-cacher.com.net <gdb> 2a00:1c10:3:634::3486:75a0 <gdb> 2607:f0d0:1003:85::c40a:2942 <grifferz> interesting <gdb> Same for apt-cacher.bitfolk.com.net <grifferz> so he's probably got some search line in his resolv.conf <gdb> I would ask what the search line is <grifferz> r <grifferz> search lines always good entertainment for those times when wtf moments are scarce <gdb> Actually it's possible that the hostname is foo.net and there's no search line.
It seems that the enterprising folks at com.net have put in wildcard A and AAAA records which basically means that if you try to resolve *.com.net you end up at their “search portal”. That’s all web-based of course.
The customer didn’t have a search line, but the issue was that their host had a fully-qualified domain name (FQDN) along the lines of example.net.
This meant that according to default resolver settings it considered itself to be inside the domain net, and when searching for hosts (like apt-cacher.bitfolk.com) it would try to find them with .net appended first.
It can be fixed by giving the resolver libraries a hint as to which domain you are actually in, in the /etc/resolv.conf:
domain example.net nameserver 192.168.1.2 nameserver 192.168.1.3
Having said that, it’s better not to pick your domain as the FQDN for any host and this is just one of the weird issues I have seen.
Sometimes customers order a VPS with a FQDN set to something like this, and I’ve yearned for an authoritative bit of documentation that says it’s not recommended. I asked about it on HantsLUG a while back also, and while it seems there was some agreement, it still seems to be down to preference.
I’ve never really tried to tell a prospective customer that they should pick a host within their domain (e.g. foo.example.net) instead of the domain name as the FQDN, because it always seemed like too complicated a subject to explain. Maybe I should try to find a way in future.
5 thoughts on “Domain name as hostname not recommended”
I had the exact same issue recently, but it was not related to domain-name-as-hostname.
The machine was named foo.example.com, and the DNS provider for example.com, it turns out, had decided that it would be a good wheeze to put a wildcard A record for *.example.com.
I fixed it by putting “domain .” in /etc/resolv.conf.
I also have my hostname set as a FQDN, but I’ve never had any issues resolving domains on CentOS (that may be because the hostname is set in /etc/sysconfig/network, does that file even exist on Debian?). Although I do remember postfix thinking it was on moggers.moggers.co.uk :p
That said, it would be nice if this was mentioned as something ‘customers might like to do’ on the customer information page. It’s clearly expected by software and it’s not really much extra configuration.
The trouble I’m having with this issue
is my hostname is the same as my machine name which is the same as my FQDN and I also have on my /etc/hosts file
The weird effect and consequence:
http://www.dinerodigital.tk is working
dinerodigital.tk ( My hostname, FQDN,machine name, and /etc/hosts) is Not accessible
other tests were made using
and two more domains….. meaning the problem is not an A or C Name DNS record
nor a Virtual host server name or alias….
This is the only weird thing I can find…..
I’ve setup FQDN , machine, hostname, setting up a send-only mail server
There is no A record in DNS for dinerodigital.tk:
$ dig +short -t a dinerodigital.tk
http://www.clubdigital.tk and clubdigital.tk seem fine.