A fully qualified domain name is a domain name that specifies a host’s exact position in the DNS tree, all the way to the root — api.example.com., trailing dot included. That dot is the root zone, and it is what makes the name absolute. Anything shorter is a partially qualified name that a resolver will complete by appending search domains, which is where surprising behaviour comes from.
The definition is dry. The reason it matters is that resolvers silently rewrite non-qualified names, and the rewrite depends on the machine you are standing on.
Table of contents
- Reading a name from the right
- Search domains, and the surprise they cause
- The trailing dot in zone files
- FQDNs and certificates
- Where FQDNs matter operationally
- Getting names right when you attach a domain
- How this fits the rest of the stack
- FAQ
Reading a name from the right
DNS names are hierarchical and read right to left, most general first.
api . example . com .
| | | |
| | | +-- root zone (the trailing dot)
| | +------ top-level domain
| +--------------- second-level domain
+---------------------- hostname / subdomain label- FQDN —
api.example.com.Absolute. No ambiguity, no completion. - PQDN —
apiorapi.example. Partially qualified. The resolver appends something to finish it. - Hostname —
api. Just the leftmost label, the machine’s local name.
In practice almost every tool accepts api.example.com without the dot and treats it as absolute anyway. The dot becomes load-bearing in DNS zone files and in a few resolvers, where its absence changes the meaning entirely.
Search domains, and the surprise they cause
When you type a non-qualified name, the resolver appends each entry in the search list until something resolves.
cat /etc/resolv.conf
# search corp.example.com example.com
# nameserver 10.0.0.2
# So 'api' is tried as:
# api.corp.example.com
# api.example.com
# apiThis is convenient inside a corporate network and a genuine source of confusion. The same command resolves differently on two machines, and a name that works on your laptop fails in a container because the container has no search domain configured.
Using the FQDN removes the variable entirely. In any configuration file, service definition, or connection string, write the full name — a partially qualified name in a config file is a dependency on the resolver configuration of whatever machine reads it.
hostname # short name -- api
hostname -f # FQDN -- api.example.com
hostname -d # domain part -- example.com
# What does the resolver actually do with it?
dig +search api
dig api.example.com.The trailing dot in zone files
This is where omitting the dot causes real damage, because in a zone file the name is relative to the zone origin when the dot is missing.
$ORIGIN example.com.
$TTL 3600
; With the dot -- absolute
www IN CNAME cdn.provider.net.
; Without the dot -- becomes cdn.provider.net.example.com.
www IN CNAME cdn.provider.netThe second record is valid syntax and completely wrong. It resolves to a name that does not exist, and the error is invisible until someone queries it.
Most hosted DNS control panels handle this for you and some silently add the dot. When editing BIND zone files directly, the rule is: every name outside the current zone needs a trailing dot.
FQDNs and certificates
TLS certificates are issued to fully qualified names. This is why https://api never works and https://api.example.com does — the certificate’s subjectAltName lists FQDNs, and the browser compares against the exact name in the address bar.
# What names does this certificate actually cover?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -ext subjectAltNameA wildcard certificate for *.example.com covers api.example.com and www.example.com but not example.com itself, and not a.b.example.com — a wildcard matches exactly one label. Certificates for the bare domain and the wildcard are separate entries, which is why an apex domain sometimes fails while every subdomain works.
SNI means the client sends the hostname during the handshake so the server knows which certificate to present. Connect by IP address and there is no name to send, which is why curl https://203.0.113.10 fails verification even when the server is correct — and why --resolve exists.
Where FQDNs matter operationally
- Mail — SPF, DKIM, and DMARC records are all keyed to fully qualified names, and reverse DNS for a sending IP should resolve to an FQDN that resolves back. Mismatches here cost deliverability.
- Kubernetes — services resolve as
service.namespace.svc.cluster.local.The short form works within a namespace because of the search domain, and breaks across namespaces. - Databases — a connection string with a short hostname is a bug waiting for a machine with different resolver configuration.
- Monitoring and TLS verification — certificate checks compare against the FQDN, so a monitor configured with a short name reports failures that are not real.
The through-line is the same in every case: a short name delegates a decision to /etc/resolv.conf, and that file differs between your laptop, your CI runner, and your production container.
Getting names right when you attach a domain
Most of the practical FQDN work in a small project is one task: point a domain at a service and get a certificate for it. The details are apex records, CNAMEs for subdomains, and the wildcard-does-not-cover-the-apex rule above.
The apex is the fiddly part, because the DNS specification does not allow a CNAME at the zone apex — which is why providers offer ALIAS or ANAME records that behave like one. Getting example.com and www.example.com both working, both with valid certificates, is where the time goes.
Attaching a custom domain on RunxBuild covers that path — the DNS records to create are shown for the domain you enter, and the certificate is issued and renewed as part of attaching it rather than as a separate task with its own expiry date to remember.
How this fits the rest of the stack
An FQDN names a host absolutely, from label to root, and the trailing dot is the root zone. Use full names in every configuration file, connection string, and monitor, because a short name hands the decision to whichever resolver happens to read it. In zone files, remember that a name without a trailing dot gets the origin appended — silently, and validly.
For certificates, remember that a wildcard covers one label and not the apex. If you are working out what a project with custom domains and managed certificates costs, the RunxBuild hosting calculator itemises service, database, storage, and bandwidth separately.
Useful related references:
- What Is a .link Domain, and When Does It Fit a Project?
- What Is a Parked Domain? And Why Yours Might Be a Liability
- Multi-Domain SSL: SAN Certificates, Wildcards, and What to Use
- Custom domains and certificates on RunxBuild
FAQ
What is a fully qualified domain name?
A domain name that specifies a host’s complete position in the DNS hierarchy, from the hostname label all the way up to the root zone — for example api.example.com. with the trailing dot. It is unambiguous, so no resolver needs to append anything to complete it.
What is the trailing dot in a domain name for?
It represents the DNS root zone and marks the name as absolute. Most tools accept a name without it and treat it as absolute anyway, but in a DNS zone file its absence means the name is relative to the zone origin, so cdn.provider.net becomes cdn.provider.net.example.com.
What is the difference between a hostname and an FQDN?
The hostname is just the leftmost label, such as api. The FQDN is that label plus every domain above it, such as api.example.com. Run hostname for the short form and hostname -f for the fully qualified one.
Why does my short hostname work locally but not in a container?
Because your machine has search domains in /etc/resolv.conf that the resolver appends to complete the name, and the container does not have the same list. Using the FQDN in configuration files removes the dependency on whichever resolver configuration happens to be present.
Does a wildcard certificate cover the apex domain?
No. A wildcard for *.example.com matches exactly one label, so it covers api.example.com but not example.com itself and not a.b.example.com. You need the apex listed separately, which is why a site sometimes works on www and fails on the bare domain.