If your DHCP server supports it you might want to try and have your client send the desired hostname that it wants. Add the following to the file /etc/dhcp/dhclient.conf:
send host-name 'your-hostname-here';
If you want to send a fully qualified domain name (fqdn) - myhost.mydomain.com instead of just myhost you need to add these lines too:
send fqdn.fqdn "myhost.mydomain.com.";
send fqdn.encoded on;
send fqdn.server-update off;
also request fqdn, dhcp6.fqdn;
Edit #1
The OP was asked to try the following commands and report back:
dig <hostname> @<router ip>
The OP reported that this worked so it was determined to try adding the router's IP explicitly to his dhclient.conf file.
Edit #2
It was suggested to try adding the following to the /etc/dhcp/dhclient.conf file:
prepend domain-name-servers 192.168.2.1;
Edit #3
Given you're able to now ping servers using your router's DNS server when you added 192.168.2.1, but not the internet, I would suggest you add some external DNS servers as well using the above prepend option like so:
prepend domain-name-servers 192.168.2.1, 8.8.8.8, 8.8.4.4;
This will add your router as a DNS resolver along with Google's DNS servers.
hostname returns the configured hostname or nodename. In practice, it can either be a short name (in most configurations) or a long name (normally the FQDN in this case). The short name is given by hostname --short.
hostname --fqdn returns the FQDN, which is gethostbyname on the nodename (as returned by the uname system call, see uname(2) man page).
hostname -A is something obscure and non-intuitive. In particular, despite its name and description ("all FQDNs"), it doesn't give the standard FQDN, by design. Thus I would say: do not use it. One reason is that it misses valid IP addresses of the machine, such as 127.0.1.1, with which the FQDN may be associated in the /etc/hosts file (this is currently the default under Debian and Ubuntu, for instance). Another issue with the hostname -A method is that the reverse resolution of an IP address doesn't necessarily give a FQDN; it can just be a short name.
Concerning your problem with python, it may be a bug there. I don't know. I suggest that you try the following Perl script:
#!/usr/bin/env perl
use strict;
use POSIX;
my $nodename = (POSIX::uname)[1];
print "Nodename: $nodename\n";
my @ghbn = gethostbyname $nodename;
print "FQDN: $ghbn[0]\n";
$ghbn[0] !~ /\./ && $ghbn[1] =~ /(\S+\.\S+)/
and print "Fixed FQDN from aliases: $1\n";
Best Answer
Yes, and no. The are two distinct things called hostnames.
The "internal" hostname is basically a string kept by the kernel. This is the one returned by the
hostnamecommand (or thegethostname()call) and it's unique within a system(*).It's mostly used when a program wants to output some identifier for the system it's running on. E.g.
\hin Bash'sPS1expands to the hostname. Similarly, syslog-style logfiles also include the hostname on log entries.(* Though as Stephen Kitt comments, namespaces can be used to show different hostnames to processes on the same system. That's mostly used for containers, which try to act like they're distinct systems.)
Then there's also DNS names that are used by other systems to look up the IP address of another. There might be more than one DNS name that point to the same IP address, and so the same host.
The internal hostname and the DNS names don't need to be the same. Suppose someone has a webserver they've decided to call
orange(*), with the IP address192.0.2.9. It could serve two different domains and the DNS would be set up to havewww.example.organdwww.example.comboth point to192.0.2.9, while the internal hostname of the system might beorange.example.orgor justorange. In that case, the DNS setup would usually also have a reverse lookup on192.0.2.9point back to the nameorange.example.org, but there's nothing to force that.(* because they like to name their servers after fruit. Someone might use
webserver1or such, but the point is that it doesn't need to be named after one of the actual domains.)In addition to that, virtual hosting requires that the browser tell the web server the name of the site it tried to access. Otherwise the server would not know which virtual site the client tried to reach. HTTP has the
Hostheader for that.What muddies the distinction between a DNS name and the internal hostname is the mDNS protocol (implemented e.g. by the avahi daemon) and other discovery protocols. mDNS makes it possible for hosts to query all other hosts on the same network for name information, and to make their own hostnames visible on other hosts without explicitly setting them up in DNS.