Why your domain name sometimes gets an extra dot

If you’ve ever run dig example.com, you’ve probably noticed something odd in the output:

$ dig example.com
example.com.		5678	IN	A	93.184.216.34

The trailing dot might look like a typo or a display quirk, but it’s meaningful. It marks the domain as “fully qualified,” meaning it’s complete and nothing else should be appended. A bare example.com, by contrast, is technically a relative name that software might expand by adding a suffix.

How DNS actually encodes names

It’s tempting to think the dot in dig output mirrors what’s on the wire — that DNS packets literally include a trailing period. They don’t. In fact, domain names in DNS requests and responses contain no dots at all.

Instead, each name is a sequence of length-prefixed labels. The name example.com becomes 13 bytes:

7example3com0

The human-readable dotted form — with or without a trailing dot — is a translation layer that DNS software provides. Where that translation happens depends on the tool.

Zone files: where the trailing dot is mandatory

If you manage DNS records by hand, you’ll likely write a zone file and feed it to server software like nsd or bind. Here’s an imaginary zone file for example.com:

orange  300   IN    A     1.2.3.4
fruit   300   IN    CNAME orange
grape   3000  IN    CNAME example.com.

In this format, any name that doesn’t end in a dot is treated as relative to the zone. So orange becomes shorthand for orange.example.com. The server knows which zone it’s serving and automatically appends the suffix.

The intent is simply to reduce typing. Writing every record with its full name works too:

orange.example.com.  300   IN    A     1.2.3.4
fruit.example.com.   300   IN    CNAME orange.example.com.
grape.example.com.   3000  IN    CNAME example.com.

But that gets verbose fast. The trailing dot is the explicit way to say, “this name is absolute; don’t add anything.”

You don’t have to use zone files to run DNS, though. AWS Route 53, for instance, stores records in a database and manages them through a web interface or API. But it — like many other tools — supports zone-file import and export, which makes the format useful for moving records between providers.

Why dig prints the dot

dig output has another quirk: almost every line begins with ;;. That’s because ; is the comment character in zone files. The output format is designed so you could paste it straight into a zone file and have it work.

That explains the dot too. Because zone files require absolute names to end with a period, dig prints example.com. so its output is zone-file-compatible. A +human flag that produced cleaner output would be nice, but that’s not a feature today.

Search domains: the other place names get rewritten

Zone files aren’t the only context where names get expanded. Your local machine can do it too. Suppose there’s a computer called grapefruit on your network running a web server. Running curl grapefruit works fine:

$ curl grapefruit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<html>
<head>

But adding a trailing dot breaks it:

$ curl grapefruit.
curl: (6) Could not resolve host: grapefruit.

The difference comes down to how your system resolves bare names. When you run curl grapefruit, it calls getaddrinfo, which consults /etc/resolv.conf. That file typically contains something like:

nameserver 127.0.0.53
search lan

The search lan line tells the resolver to try appending lan to names that aren’t already qualified. A packet capture confirms the lookup is actually for grapefruit.lan, not grapefruit:

$ sudo tcpdump -i any port 53
[...] A? grapefruit.lan. (32)

Search domain expansion doesn’t happen in every case. If the name ends with a dot — like curl grapefruit. — your system treats it as fully qualified and skips the search list. The same is true by default for names with an internal dot, such as example.com, though that behavior can be changed (Kubernetes’ ndots setting is a prominent example).

Where does the search domain come from? When your machine connects to your router via DHCP, the router supplies not only an IP address but also the search domain, typically lan on home networks.

The practical upshot

Two common mechanisms — zone file expansion and search domains — can silently turn a short name into a longer one. That ambiguity is why a trailing dot is useful: it signals “this name is complete, nothing gets appended.” The technical term for that is a fully qualified domain name, or FQDN. So google.com. is a FQDN; google.com isn’t.

If you spend most of your time working with public internet names, the concern can feel theoretical — of course google.com means google.com. But for people who manage zone files or run systems that use search domains (Kubernetes, for example), the trailing dot removes ambiguity.

As for when to use one:

  • - When configuring DNS: Fully qualified names are always accepted. Some DNS systems even require them, warning that a non-qualified name will have a suffix appended.
  • - In a browser: Usually don’t. Typing https://twitter.com. can produce a 404 because the HTTP Host header becomes twitter.com., which the server doesn’t expect. https://jvns.ca. similarly triggers an SSL error.

Relative names like grapefruit for grapefruit.lan were more natural when DNS was primarily used inside universities and large institutions with big internal networks. Today, absolute names dominate the public internet, so the trailing dot is something you’ll mainly encounter in DNS tooling — but it’s worth knowing what it means when you see it.