User:Mjb/FQDN and the trailing dot

Here are my notes on fully qualified domain names (FQDNs) and the mysterious "trailing dot" syntax that nobody can seem to agree on.

The idea is to make a case for changing the Wikipedia article on FQDNs so that it:

1. stops saying that the trailing dot is inherently part of FQDNs;
2. explains that the trailing dot is used only in certain situations;
3. stops taking RFC info out of context, and stops assuming the syntax for resolver input or DNS RRs applies to domain names generally;
4. cites better references (the appropriate RFCs, not MCSE instructors' personal websites);
5. stops giving undue weight to the term "PQDN".

If you have questions, comments, doubts, concerns, etc., then please leave a reply on this essay's talk page or on the FQDN article's talk page.

Wikipedia article problems

In my opinion, the Wikipedia article on fully qualified domain names is currently incorrect. Don't rely on it, nor on statements which may be derived from it.

In particular, there is this problematic statement:

The DNS root domain is unnamed, which is expressed by the empty label, resulting in a fully qualified domain name ending with the full stop (period) character.

The first part is correct, and a domain name conceptually includes the root domain, but the printed representation of a domain name—fully qualified or not—does not end with a period. In fact RFC 882 very clearly says so:

     The domain name space is a tree structure.  Each node and leaf on
     the tree corresponds to a resource set (which may be empty).  Each
     node and leaf has an associated label.  Labels are NOT guaranteed
     to be unique, with the exception of the root node, which has a
     null label.  The domain name of a node or leaf is the path from
     the root of the tree to the node or leaf.  By convention, the
     labels that compose a domain name are read left to right, from the
     most specific (lowest) to the least specific (highest).
     [...]
     When domain names are printed, labels in a path are
     separated by dots (".").  The root label and its associated dot
     are omitted from printed domain names [...]

This is reiterated by RFC 1594 § 5.2, which says:

     A Fully Qualified Domain Name (FQDN) is a domain name that
     includes all higher level domains relevant to the entity named.
     If you think of the DNS as a tree-structure with each node having
     its own label, a Fully Qualified Domain Name for a specific node
     would be its label followed by the labels of all the other nodes
     between it and the root of the tree.  For example, for a host, a
     FQDN would include the string that identifies the particular host,
     plus all domains of which the host is a part up to and including
     the top-level domain (the root domain is always null).  For
     example, atlas.arc.nasa.gov is a Fully Qualified Domain Name for
     the host at 128.102.128.50.  In addition, arc.nasa.gov is the FQDN
     for the Ames Research Center (ARC) domain under nasa.gov.

The examples there make it clear that a FQDN does not include a trailing dot.

RFC 1983 provides another example of how the trailing dot is not part of a fully qualified domain name:

  Fully Qualified Domain Name (FQDN)
     The FQDN is the full name of a system, rather than just its
     hostname.  For example, "venera" is a hostname and
     "venera.isi.edu" is an FQDN.

One source of confusion may be RFC 2181, which clarifies the syntax:

  The DNS itself places only one restriction on the particular labels
  that can be used to identify resource records.  That one restriction
  relates to the length of the label and the full name.  The length of
  any one label is limited to between 1 and 63 octets.  A full domain
  name is limited to 255 octets (including the separators).  The zero
  length full name is defined as representing the root of the DNS tree,
  and is typically written and displayed as ".".

It is important to understand that RFC 2181 is only referring to representations of the root domain by itself, in resource records, i.e. the data structures internal to DNS servers and the messages they exchange with DNS clients.

In much the same way, the Wikipedia article relies on and misunderstands the purpose of RFC 1035 § 5.1, which says:

  <domain-name>s make up a large share of the data in the master file.
  The labels in the domain name are expressed as character strings and
  separated by dots.  Quoting conventions allow arbitrary characters to be
  stored in domain names.  Domain names that end in a dot are called
  absolute, and are taken as complete.  Domain names which do not end in a
  dot are called relative; the actual domain name is the concatenation of
  the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
  an argument to the master file loading routine.  A relative name is an
  error when no origin is available.

Again, this is very specifically talking only about the syntax of data in the resource record files used by the DNS server reference implementation (BIND). Other implementations exist which have their own configuration file syntax.

The Wikipedia article also mentions the term partially qualified domain name (PQDN) as being synonymous with relative domain name. PQDN is not defined anywhere in IETF sources, nor does it seem to be very common. The term relative domain is not found very often in IETF sources, either. The Wikipedia article only cites two poor-quality sources for these terms. One is an engineer's personal website (which contains incorrect info about the trailing dot as well), and the other is the RFC 1035 reference above, which only mentions "relative names" in the context of resource records.

However, RFC 1535 discusses a security issue with the resolution of "partial domain names", referring to such resolver inputs as "hostnames that are not fully qualified domain names (FQDNs)". Its background section mentions:

  An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
  domain name is of the format {name}

This is specifically in reference to the behavior of DNS resolvers. The RFC gives various examples with and without the dot, implying that the dot's purpose is to indicate absoluteness when a domain is given as input to a resolver; it does not suggest the dot is not an essential feature of the FQDN itself.

Indeed, the trailing dot is a lexical convention for indicating a domain as "absolute", according to RFC 1035 § 5.1 (governing the format of master files containing resource records for a particular zone, as used by BIND) and RFC 1123 § 6.1.4.3 (governing the input to a resolver). The idea is that you can add the dot to ensure that the given name is not treated as possibly being relative; nothing will be appended to it.

RFC 1535 goes on to recommend that all DNS resolvers treat the presence of any dots (not just trailing ones) as indicative of a FQDN:

  Further, in any event where a "." exists in a specified name it
  should be assumed to be a fully qualified domain name (FQDN) and
  SHOULD be tried as a rooted name first.

That is, when submitted to a resolver, "www.example.com" is treated as a FQDN and would not get a search domain appended to it.

A trailing-dot proponent might point to the relatively recently authored RFC 6762, which says:

  Most computer users neglect to type the trailing dot at the end of a
  fully qualified domain name, making it a relative domain name (e.g.,
  "www.example.com").

The implication here, that a trailing dot is part of a FQDN, clearly conflicts with all the preceding evidence. Also, this RFC is not authoritative on this issue; it only serves to introduce the following text, describing a potential security problem:

  In the event of network outage, attempts to
  positively resolve the name as entered will fail, resulting in
  application of the search list, including ".local.", if present.  A
  malicious host could masquerade as "www.example.com." by answering
  the resulting Multicast DNS query for "www.example.com.local.".  To
  avoid this, a host MUST NOT append the search suffix ".local."

This warning overlooks the fact that most resolvers are configured by default, as per the recommendation in RFC 1535, to treat the presence of 1 or more dots as an indication of absoluteness. In order to get the behavior described in RFC 6762, you would have to be resolving a name with no dots (e.g. "www") or you'd have to specially configure your resolvers to have a 3-dot threshold for absoluteness, which is rare, except maybe in huge corporate intranets.

So, taking all of the above into consideration, I feel it is quite reasonable to assert:

• A fully qualified domain name does not include a trailing dot.

...full stop! :)

When a trailing dot is used

So what is a trailing dot for, and when do you use it? I would say this:

• Appending a trailing dot to a domain name is a lexical convention only for use in certain applications, to flag the domain as absolute (meaning it is relative to the root, a.k.a. fully qualified). It is only used in certain circumstances where there could be ambiguity about whether the name is relative to another leaf of the domain name tree.

Examples follow.

DNS resource records, always

As mentioned above, RFC 1035 § 5.1 says:

  <domain-name>s make up a large share of the data in the master file.
  The labels in the domain name are expressed as character strings and
  separated by dots.  Quoting conventions allow arbitrary characters to be
  stored in domain names.  Domain names that end in a dot are called
  absolute, and are taken as complete.  Domain names which do not end in a
  dot are called relative; the actual domain name is the concatenation of
  the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
  an argument to the master file loading routine.  A relative name is an
  error when no origin is available.

So, yes a fully qualified ("absolute") domain name provided in a resource record must be written with a trailing dot, in order to ensure that it is treated as absolute.

Implementations other than BIND are in fact free to use their own configuration file formats with or without trailing dots, but presumably must produce the same kinds of responses that BIND would. Indeed, when monitoring UDP port 53 traffic and comparing the output of various clients like nslookup and host(1), I observed that a FQDN provided in DNS server responses normally do contain a trailing dot. However, the client (e.g. nslookup on Windows) may choose not to print the trailing dot, depending on the degree to which it is interpreting the transmitted resource record.

Input to a resolver, rarely

RFC 1123 § 6.1.4.3 says:

            User interfaces MAY provide a method for users to enter
            abbreviations for commonly-used names.
            [...]
            If an abbreviation method is provided, then:

            (a)  There MUST be some convention for denoting that a name
                 is already complete, so that the abbreviation method(s)
                 are suppressed.  A trailing dot is the usual method.

This is saying that a FQDN provided as input to a resolver should be written with a trailing dot.

However, as discussed above, per RFC 1535, most resolvers are configured nowadays with a 1-dot threshold for absoluteness; that is, they assume the domain is absolute when it contains any dots at all. So in practice, the trailing dot is almost always redundant!

Hosts table, never

The libc (C standard library) resolver—e.g., the function gethostbyname(3) or getaddrinfo(3)—is typically configured to resolve hostnames to IP addresses in two ways. First, the resolution is attempted through the use of local files, e.g. a table defined in /etc/hosts. Then, if that didn't work, a DNS server is queried.

As per the hostname(7) and hosts(5) manpages on both FreeBSD and Debian Linux, a FQDN written in /etc/hosts should not contain a trailing dot. Even when asked to resolve a name with a dot, the resolver will look for the entry in the hosts file without the dot, conforming to RFC 1123 § 6.1.4.3.

The hosts(5) manpage is a little more specific about this on Debian Linux than it is on FreeBSD, I noticed. Also, I found that FreeBSD's resolver has long had a bug where it doesn't actually strip the dot for the /etc/hosts lookup! I reported it.

Email message headers, never

RFC 822 and RFC 2822 define the syntax of email messages, including headers. Neither "Received:" headers nor email addresses in any header can include a trailing dot.

I found that Sendmail does not strictly enforce this; if it thinks your hostname has a trailing dot, it will happily put them into message headers.

SMTP transactions, never

In all SMTP transactions, domain names must be FQDNs written without a trailing dot. This is as per the syntax of SMTP commands given in RFC 821 § 4.1.2 and RFC 2821 § 2.3.5 and § 4.1.2.

Here is RFC 2821 § 2.3.5:

  The domain name, as described in this document and in [RFC 1035], is the
  entire, fully-qualified name (often referred to as an "FQDN").  A
  domain name that is not in FQDN form is no more than a local alias.
  Local aliases MUST NOT appear in any SMTP transaction.

(Even if the grammar in § 4.1.2 didn't explicitly forbid the trailing dot, you could observe that the numerous examples of domains in valid SMTP commands in this RFC do not have trailing dots, thus they must be valid FQDNs.)

SMTP servers are encouraged to reject SMTP commands with syntax errors, which would include a HELO/EHLO domain with the trailing dot. However, as per RFC 2821 § 7.7, SMTP servers which choose to reject possibly-forged mail should give a 550 response, but should also try not to reject mail excessively. So, in the spirit of interoperability, most apparently actually do accept and ignore the trailing dot, since the domain is still obviously a FQDN and there's no harm in doing so.

Ideally, it should not be possible to make an SMTP client ever put trailing dots in domains. Nevertheless, when generating SMTP commands, some clients don't sanitize their data or warn their operators; they just use whatever hostname they are configured or told to use, or whatever hostname they get from their local system. If this name includes the trailing dot, then there's a good chance this will get copied into SMTP commands and message headers verbatim. This is what happens with Sendmail on FreeBSD if the hostname is defined with a trailing dot. One can customize the Sendmail config files to mitigate this somewhat, but I'm unsure whether it's possible to prevent the dot from getting into the HELO command.

Linux or BSD hostname definition, never

Every OS has a slightly different way of defining its hostname. Some, like Debian Linux, expect it to be defined as the local node's label in one place and rest of the domain somewhere else. Others, like the BSDs, expect it to be defined as a FQDN in /etc/rc.conf or /etc/myname, or a choice of one or the other.

Incidentally (this has no bearing on the Wikipedia article):

I have observed that despite mandating one or the other, both Debian Linux and FreeBSD work just as well if the hostname is defined as a FQDN or local node name when the opposite was expected, at least when the resolver follows the RFC 1535-recommended 1-dot threshold as mentioned above.

The manual pages for the systems requiring a FQDN don't provide examples or specify whether a trailing dot would be needed. It is safe to assume that it is not, though, because of my arguments above, and the utter lack of example configurations showing a trailing dot in the hostname definition. Also, my own research (again, incidental) on FreeBSD confirms it is not a good idea:

When using DHCP, I noticed that the search domain appended to relative URLs may end up being a string like "example.org." with a trailing dot. So I thought that if the libc resolver believes "myhost" is short for "myhost.example.org." with the trailing dot, then maybe that's what I should put in /etc/rc.conf as my hostname. I mean, if the point of the dot is to ensure that it's treated as a FQDN, what's the harm?

Well, I found that it's just too risky for mail apps & services. If you define the FreeBSD hostname as a FQDN and you append a dot, as mentioned above, I found that Sendmail (which is still the default MTA/MSA on FreeBSD) will not strip the dot from its SMTP commands, and there are some email servers out there which will reject messages with trailing dots in the HELO/EHLO command. The dot also ends up in Received headers. I also observed that my MUA, Mutt, will put it into outgoing mail headers and envelope addresses.