differences between hostname and fully qualified domain name(FQDN)

Question

First of all I searched the site for similar topic, and read the RFC 1535 and FQDN wiki, they don't seem to answer the question.

Let me use www.youtube.com as an example. Python script I used:

import socket

for host in ["www.youtube.com"]:
    print(host)
    try:
        hostname, aliases, addresses = socket.gethostbyname_ex(host)
        fqdn = socket.getfqdn(host)
        print("  Aliases : ", aliases)
        print(" Hostname : ", hostname)
        print("     FQDN : ", fqdn)
        print("Addresses : ", addresses)
    except socket.error as msg:
        print("%15s : ERROR: %s" % (host, msg))

Output:

  Aliases :  www.youtube.com
 Hostname :  youtube-ui.l.google.com
     FQDN :  sa-in-f93.1e100.net
Addresses :  ['74.125.200.93', '74.125.200.190', '74.125.200.136', '74.125.200.91']

1) What is the relation between hostname and FQDN?

According to the website http://kb.iu.edu/d/aiu (and many other sites): For a mail server "mymail.somecollege.edu", the hostname is "mymail", the domain is "somecollege.edu", and combined together these form the FQDN. But clearly this isn't the case for www.youtube.com. So, what is FQDN exactly and what is the relation between all these names?

2) When I reverse lookup the IP 74.125.200.93, the hostname become sa-in-f93.1e100.net. Why does the reverse lookup give me FQDN as a hostname? Are these names interchangeable?

socket.gethostbyaddr('74.125.200.93')

 Hostname :  sa-in-f93.1e100.net
  Aliases :  []
Addresses :  ['74.125.200.93']

3) Is Aliases : www.youtube.com also know as CNAME? According to http://support.dnsimple.com/articles/cname-record/ the answer seems to be yes:

For example, if you have a server where you keep all of your documents online, it might normally be accessed through docs.example.com. You may also want to access it through documents.example.com. One way to make this possible is to add a CNAME record that points documents.example.com to docs.example.com. When someone visits documents.example.com they will see the exact same content as docs.example.com.

4) If that is true why I can't use "youtube-ui.l.google.com" or "sa-in-f93.1e100.net" to visit YouTube? This is what I got by visiting hostname and FQDN directly:

Google

404. That’s an error.

The requested URL / was not found on this server. That’s all we know.

EDIT #1

Sorry about the slow reply, I'm still reading those RFC docs, and I have some new questions:

Again using www.youtube.com as example.

5)How FQDN is generated? Does it query parent domain until root(dynamically generated) each time I call socket.getfqdn() or host -t PTR? Or is it just a PTR record?(seems like query FQDN rely on reverse look up) If it is a PTR record, then how can I be sure it is a FQDN, actually it can be FQDN, CNAME, alias, hostname or some other name if zone dns admins want to set it up like that. Just like David and Esa Jokinen pointed out (RFC 1912, 2.1), if these rules are not enforced then how can I be sure what am I getting?

So I'm thinking maybe query parent domain until root IS the most reliable way to get FQDN. But how can I do that? Is it even possible to get FQDN without using PTR(since it's not relialbe)

6)Is it possible for DNS query go backwards?

Normally query for IP is cache/recursive server ask root then TLD then subdomain until it gets the IP. Is it possible to do this backward? Got the IP then somehow got the subdomain then TLD then root then I got the FQDN?

7)Isn't FQDN and IP should be 1 to 1 mapped?

Here is what I got when I run

host 216.58.193.78

output:

78.193.58.216.in-addr.arpa domain name pointer sea15s07-in-f78.1e100.net.
78.193.58.216.in-addr.arpa domain name pointer sea15s07-in-f14.1e100.net.

How come one IP mapped to two FQDN? One machine two FQDN, how does it work?

Answer 1

Regardless of the semantics of term FQDN we must see what Python's socket.getfqdn() does.

socket.getfqdn([name])

Return a fully qualified domain name for name. If name is omitted or empty, it is interpreted as the local host. To find the fully qualified name, the hostname returned by gethostbyaddr() is checked, followed by aliases for the host, if available. The first name which includes a period is selected. In case no fully qualified domain name is available, the hostname as returned by gethostname() is returned.

socket.gethostbyaddr(ip_address)

Return a triple (hostname, aliaslist, ipaddrlist) where hostname is the primary host name responding to the given ip_address, aliaslist is a (possibly empty) list of alternative host names for the same address, and ipaddrlist is a list of IPv4/v6 addresses for the same interface on the same host (most likely containing only a single address).

In other words, getfqdn() looks for reverse PTR record first, regardless of what A or CNAME record has pointed to it in the first place. It looks for a fully qualified domain name (FQDN) and simply gives you the first suitable one i.e. the first one that ends with ., the root.

So, FQDN : sa-in-f93.1e100.net comes from the PTR record for IP 74.125.200.93.

93.200.125.74.in-addr.arpa. 86400 IN    PTR     sa-in-f93.1e100.net.

Here, the FQDN for this hostname www having domain youtube.com is actually by definition www.youtube.com., including the dot. Likewise, the sa-in-f93.1e100.net is not a FQDN, as it should actually be sa-in-f93.1e100.net.:

• hostname sa-in-f93 as subdomain for 1e100
• sa-in-f93.1e100 as subdomain for net
• sa-in-f93.1e100.net as subdomain for the root, ..

Why sa-in-f93.1e100.net. is chosen over www.youtube.com. simply comes from how the socket.getfqdn() is designed to determine the FQDN of a given name.

On the other hand, the Canonical Name CNAME record SHOULD by design (RFC 1035, 3.2.2) point to the canonical name, but it's commonly used like it was just an alias, because it works like one. Also, the PTR record SHOULD (RFC 1912, 2.1) give the same result, as it should represent the canonical name for the given IP.

If only that was obeyed, the method socket.getfqdn() uses would have been completely appropriate. Here, the CNAME youtube-ui.l.google.com. without the corresponding PTR record (93.200.125.74.in-addr.arpa. IN PTR youtube-ui.l.google.com.) made this assumption false.

Answer 2

"Hostname" is an ill-defined term that is used in many different contexts to mean many different things that, roughly speaking, have nothing in common except being some sort of name for something that can be considered a host. Trying to treat everything that is called "hostname" as the same thing, or even some sort of well-defined thing, will only lead to frustration and confusion.

A fully qualified domain name (FQDN) is a DNS-specific term going back to RFC 1035, meaning a DNS domain name that is fully spelled out with all its component labels (as opposed to a domain name that leaves some labels implied by context).

The only relation between a "hostname" and an FQDN is that for some uses of "hostname", the value of it is supposed to be an FQDN.

Answer 3

1) It is complex and the results from these are dependent on the system name resolution settings, libraries used and the context. In a typical linux install hostname is the canonical name associated with a host and can either be a FQDN or a short name but should be resolvable by either (if properly setup). If something like NIS is used the hostname can only be the short name rather than a FQDN.

Your example (using DNS):

$host www.youtube.com
www.youtube.com is an alias for youtube-ui.l.google.com.
youtube-ui.l.google.com has address 216.58.193.78

www.youtube.com has a CNAME in the DNS response (the "C" stands for canonical) of youtube-ui.l.google.com so the "hostname" returned by your library call is the canonical name according to DNS.

The reverse query on the IP address using DNS is made by asking for a PTR record at 78.193.58.216.in-addr.arpa

$ host -t PTR 78.193.58.216.in-addr.arpa
78.193.58.216.in-addr.arpa domain name pointer sea15s07-in-f78.1e100.net.

Note that it points to a different name than the "hostname" we got earlier. This is due to how the ISP that owns the IP address sets this up and will vary from host to host when using DNS. It is fairly common practice to setup a fixed 1-to-1 mapping between IP addresses and names for this kind of use even if they don't represent what the host has for a name.

Another example (using /etc/hosts):

#example hostfile
1.2.3.4 hosta hosta.example.net myothername.example.net
4.3.2.1 hostb.example.net hostb anothername

When using your code but changing "www.youtube.com" to "hosta","hostb" we get:

hosta
('  Aliases : ', ['hosta.example.net', 'myothername.example.net'])
(' Hostname : ', 'hosta')
('     FQDN : ', 'hosta.example.net')
('Addresses : ', ['1.2.3.4'])
hostb
('  Aliases : ', ['hostb', 'anothername'])
(' Hostname : ', 'hostb.example.net')
('     FQDN : ', 'hostb.example.net')
('Addresses : ', ['4.3.2.1'])

So in the host file "hostname" is the first name after the IP address. Aliases are everything after that. The FQDN is the first name with a dot.

Again, this can vary between systems and libraries.

2) The reverse lookup gives you a PTR in DNS which can be anything really. It could return localhost if it wanted. There is no requirement that a PTR be a FQDN but but makes the most sense to return one as such. Results from this cannot and should not be used interchangeably.

3) Yes in DNS www.youtube.com is a CNAME for youtube-ui.l.google.com.

4) For the HTTP 1.1 protocol your client tells the server in the request the server name in the URL bar if the server gets a name it's not expecting it can reject it. Youtube expects to be called www.youtube.com and the server handling this request returns a 404 error if you connect to it and call it by any other name.