A Fully Qualified Domain Name (FQDN) is the complete, unambiguous address of a host on the internet or a private network – the hostname plus every domain level up to the root, such as mail.example.com. Unlike a partial or relative hostname, an FQDN identifies exactly one location, which is why systems rely on it wherever precise host identification matters.
Key takeaways
- An FQDN names a host completely: hostname plus every domain level to the root.
- It differs from a relative hostname, which is ambiguous outside its local zone.
- DNS resolves an FQDN to the IP address that actually reaches the host.
- Wildcard and elastic FQDNs extend the concept to policy matching and failover.
- Versa configurations use FQDNs as match values in address objects and monitors.
On this page: Why it mattersHow it worksTypesFQDNs & VersaFAQ
Why are FQDNs important?
An FQDN removes ambiguity. A bare hostname like web1 only resolves inside its local DNS zone; the same label could point to a different machine elsewhere. An FQDN – web1.branch12.example.com – is globally unique, so any system needing to reach a specific host addresses it by FQDN, not context.
That reliability underpins everyday dependencies. TLS certificates bind trust to an FQDN in their Subject Alternative Name field, so a client can confirm it reached the right server. Load balancing resolves an FQDN to whichever IP currently serves it, essential now that apps sit behind CDNs with constantly changing IPs. Security policy also matches traffic by FQDN, since an IP-based rule breaks once a SaaS provider reassigns addresses.
What is an FQDN?
An FQDN is built from labels separated by dots, read right to left from most general to most specific: a top-level domain (.com, .net), one or more domain/subdomain labels (example, branch12), and a hostname label (web1) – followed, formally, by a trailing dot for the DNS root, almost always omitted in practice.
DNS resolves an FQDN through a chain of lookups: a resolver asks the root servers which server is authoritative for the top-level domain, that server refers it to the authoritative name server, which returns the matching A, AAAA, or CNAME record – the reachable IP. Because the chain is anchored at the root, resolution works the same way regardless of where the query originates, a property no relative hostname offers.
Types of FQDNs
Most FQDNs are static: a fixed label that always resolves to the same host, such as mail.example.com. Wildcard FQDNs use an asterisk in place of a label – *.example.com – to match any subdomain in one rule, common in certificates and address-matching policy. Elastic (floating) FQDNs stay constant while the IP behind them moves, typically a shared virtual IP on an active/standby node, so clients keep working through a failover; Versa’s VMS clusters use this pattern. FQDNs also split by visibility: internal FQDNs resolve only inside a private DNS zone, while external FQDNs resolve through public DNS.
FQDNs & Versa
Versa configurations use FQDNs as a match value in several places: address objects, SLA and SaaS application monitors, DNS/IP-filtering profiles, and as a peer-identity format for IPsec tunnels – letting policy reference a service by name instead of a volatile IP.
FQDNs also identify VMS (Versa Message Service) infrastructure itself. During VMS installation, the northbound, southbound, and elastic interfaces each get their own FQDN, carried in the TLS certificate’s SAN fields. HA-based VMS deployments add an elastic FQDN fronting the active/standby pair, so devices keep one stable name regardless of which node is active. Once running, enabling VMS services – RADIUS, Kafka, SCIM, Panorama – reuses that FQDN as the connection target.
Frequently asked questions
What is the difference between an FQDN and a hostname?
A hostname is just the leftmost label, such as web1. An FQDN adds every domain level above it up to the root, such as web1.branch12.example.com. The bare hostname is only meaningful in its local DNS context; the FQDN is globally unique and resolvable anywhere.
What is the difference between an FQDN and a domain name?
A domain name identifies a zone of administration, such as example.com. An FQDN identifies one specific host within that zone, such as web1.example.com. Every FQDN contains a domain name, but a domain name alone does not point to a host.
How long can an FQDN be?
Each label can be up to 63 characters, and the entire name, dots included, is capped at 253 characters – limits set by how DNS encodes names in its wire format. In practice, real-world FQDNs run far shorter than either limit, typically well under 100 characters total.
Can an FQDN resolve to more than one IP address?
Yes. DNS load balancing and round-robin records let one FQDN return multiple A or AAAA records, and CDNs often return different IPs depending on the client’s network location for lower latency. The FQDN itself stays constant even as the underlying IP addresses change behind it.
Why do TLS certificates use FQDNs instead of IP addresses?
Certificates bind trust to a name a client can verify against what it typed or clicked; IP addresses change too often to serve as a stable identity. The FQDN in the certificate’s Subject Alternative Name field lets a client confirm it reached the intended host.
More on FQDN
If you want to learn more, these are sources we trust.
| RFC 1035: Domain Names | NIST CSRC Glossary |
|---|---|
| The foundational IETF standard defining domain names, labels, and how the DNS hierarchy resolves them. | NIST’s security glossary, which defines FQDN and related identity and naming terms used in federal guidance. |
Related terms
If you’re reading about FQDN, these are worth looking at next.
| Address Group | Routing Instance | SD-WAN |
|---|---|---|
| A reusable object grouping FQDNs with IP subnets, ranges, and other address objects as Layer 3 match criteria. | The forwarding context referenced when configuring the SLA and SaaS application monitors that FQDNs feed. | The networking approach whose application-aware routing depends on identifying SaaS destinations by FQDN. |