Basics

5 MIN READ

Apr 13, 2026

IP Address vs. FQDN: Two Names for the Same Thing

An IP address is the numerical identifier routers use to forward packets, while an FQDN is the human-readable hostname resolved by DNS. Understanding how they work together explains how websites survive server migrations and how virtual hosting works.

Two Different Names for the Same Network Endpoint

Every server reachable on the internet has at least one IP address. Many of those same servers also have one or more human-readable names. These names—Fully Qualified Domain Names (FQDNs)—are what you type into a browser. The IP address is what the network infrastructure actually routes packets to. DNS (Domain Name System) is the distributed database that connects these two identifiers.

Understanding the relationship between IP addresses and FQDNs is not optional background knowledge—it explains why websites survive server migrations without users noticing, why a single IP can host hundreds of different websites, why HTTPS certificates require matching names, and why internal DNS matters just as much as external DNS for enterprise networks.

What Makes a Name Fully Qualified

A Fully Qualified Domain Name is a complete hostname that specifies the exact location in the DNS hierarchy. The syntax reads right-to-left in terms of hierarchy. Take mail.example.com.:

The trailing dot represents the DNS root (often omitted in everyday use but technically required for full qualification)
com is the Top-Level Domain (TLD)
example is the second-level domain, registered by the organization
mail is the subdomain (or hostname) within that domain

A partially qualified domain name or simple hostname (like mailserver) requires the DNS resolver to append a search domain to resolve it. An FQDN needs no such appending because it completely specifies the location in the hierarchy.

How DNS Resolves an FQDN to an IP Address

When your browser needs to connect to www.example.com, the following sequence occurs (assuming no cached answers exist at any level):

Local cache check: The operating system checks its local DNS cache. If a valid record for the FQDN exists, the cached IP is used immediately and the remaining steps are skipped.
Stub resolver to recursive resolver: The OS stub resolver sends a query to the configured DNS resolver (typically your ISP's resolver, Google's 8.8.8.8, or Cloudflare's 1.1.1.1).
Recursive resolver queries root servers: If the recursive resolver lacks a cached answer, it queries one of the 13 root nameserver clusters to find the authoritative nameserver for the .com TLD.
TLD nameserver query: The recursive resolver queries the .com TLD nameserver, which returns the address of the authoritative nameserver for example.com.
Authoritative nameserver query: The recursive resolver queries the authoritative nameserver for example.com, which returns the A record (for IPv4) or AAAA record (for IPv6) containing the IP address.
Response delivery: The recursive resolver returns the IP address to the stub resolver, which passes it to the browser. The browser opens a TCP connection to that IP.

The entire process typically completes in 20–100 milliseconds, depending on how many levels are uncached. Results are cached at each level according to the TTL (Time to Live) value in the DNS records.

DNS Record Types That Connect FQDNs to IPs

A record: Maps an FQDN to an IPv4 address. www.example.com IN A 93.184.216.34
AAAA record: Maps an FQDN to an IPv6 address. www.example.com IN AAAA 2606:2800:220:1:248:1893:25c8:1946
CNAME record: Maps an FQDN to another FQDN (an alias). blog.example.com IN CNAME www.example.com. The resolver follows the chain until it reaches an A or AAAA record.
PTR record: The reverse of an A record. Given an IP address, returns the associated FQDN. Used for reverse DNS lookups, email sender verification, and logging. PTR records are stored in the in-addr.arpa zone for IPv4.

Virtual Hosting: One IP, Many FQDNs

One of the most important practical consequences of the IP/FQDN relationship is virtual hosting—the ability to serve completely different websites from a single IP address. This is how most web hosting works today.

When a browser connects to a web server on port 80 (HTTP), it sends an HTTP request that includes a Host header identifying which FQDN the user requested. The server inspects this header and serves the content for the matching virtual host configuration. Without the Host header, the server would have no way to distinguish between requests for different domains arriving on the same IP.

For HTTPS (TLS), the equivalent mechanism is SNI (Server Name Indication). SNI is a TLS extension that allows the browser to specify which hostname it is connecting to during the TLS handshake, before any HTTP data is exchanged. The server uses the SNI value to select the correct TLS certificate for the requested FQDN. This is why thousands of HTTPS sites can share a single IP address—each site has its own certificate identified by SNI.

IP Address vs FQDN Comparison

Attribute	IP Address	FQDN
Format	Numeric (e.g., 93.184.216.34 or 2001:db8::1)	Text label hierarchy (e.g., www.example.com)
Used by	Routers, switches, firewalls, operating systems	Browsers, email clients, applications, humans
Stability	Can change when servers migrate	Remains constant regardless of server changes
Requirement for HTTPS	Not usable for SNI; certificate must match FQDN	Required; certificate Common Name must match
Virtual hosting	Single IP serves many FQDNs via Host header/SNI	FQDN distinguishes sites on shared IPs
Security controls	Firewall rules, IP allowlists	URL filtering, DNS-based blocking
Reverse lookup	Can be looked up via PTR record	Forward lookup via A/AAAA record

Why Enterprises Need Internal DNS

Enterprise networks rely on internal DNS—DNS infrastructure that resolves private FQDNs to private IP addresses. Without internal DNS, every server reference in scripts, configurations, and applications would use private IP addresses. Internal DNS provides the same flexibility benefits as public DNS:

When a database server is migrated to new hardware with a new private IP, only the DNS record changes. All applications pointing to db.internal.example.com continue working without reconfiguration.
Internal hostnames are human-readable, reducing the cognitive load of managing dozens of servers.
Split-horizon DNS allows the same FQDN to resolve to different IPs internally and externally, keeping private infrastructure addresses invisible to the public internet.

Common Misconceptions

One FQDN always maps to one IP address

Not necessarily. A single FQDN can have multiple A records pointing to different IP addresses—a technique called DNS load balancing or Round-Robin DNS. Each resolver query may return different IPs, distributing traffic across multiple servers. CDNs like Cloudflare and Akamai go further, returning different IPs based on the geographic location of the resolver.

Typing an IP address in a browser is equivalent to typing the FQDN

Functionally they connect you to the same server, but the experience differs significantly. If the server uses name-based virtual hosting, connecting by IP address may serve a default or error page because the server does not know which virtual host you intended. More critically, HTTPS connections by IP require the certificate to include the IP address as a Subject Alternative Name (SAN), which most certificates do not have. Attempting HTTPS by IP against a typical web server produces a certificate error.

DNS changes are instant

DNS changes propagate according to TTL values in the records. If your A record had a TTL of 3600 seconds (1 hour), resolvers that cached the old value will continue using it for up to one hour after you update it. For planned migrations, reduce the TTL to 300 seconds (5 minutes) at least 48 hours before the migration so caches expire quickly. After the migration, you can restore the higher TTL.

An FQDN and a URL are the same thing

They are not. A URL (Uniform Resource Locator) is a complete reference to a resource: it includes the scheme (https://), the FQDN, optionally a port, and a path. https://www.example.com/path/to/resource is a URL. www.example.com is the FQDN within it. The terms are often used loosely but are technically distinct.

Pro Tips for Working With IP/FQDN Relationships

Always lower your TTL before planned server migrations. A TTL of 300 seconds allows DNS changes to propagate globally within 5 minutes. A TTL of 86400 (24 hours) means half your users might get the old IP for up to a day after migration. Change the TTL 48 hours before the migration, execute the migration, verify, then restore a higher TTL.
Configure reverse DNS (PTR records) for all sending mail servers. Most mail server spam filters check that the sending IP has a PTR record matching the sending FQDN. Missing PTR records cause mail to be rejected or spam-scored negatively. Ask your hosting provider or ISP to set the PTR record on your IP.
Use FQDNs in configuration files, not IP addresses. Hard-coding IP addresses in application configurations creates maintenance debt. When the IP changes, every config file must be updated manually. Using an FQDN means a single DNS record change propagates everywhere.
Test DNS resolution from multiple locations. DNS resolution can return different results depending on the resolver's location (for CDN-based geoDNS) or whether your changes have fully propagated. Use tools like 'dig @8.8.8.8 example.com A' to query a specific resolver and verify that your intended record is being returned.
Set up monitoring for your FQDN-to-IP mapping. If your DNS record is hijacked or accidentally changed (misconfiguration, domain hijacking), traffic to your FQDN routes to the wrong server. Automated monitoring that checks the resolved IP against an expected value detects this within minutes rather than hours.
Understand the difference between authoritative and non-authoritative DNS answers. An authoritative answer comes directly from the nameserver responsible for the zone. A non-authoritative answer comes from a caching resolver. When troubleshooting, query the authoritative nameserver directly with 'dig +norecurse FQDN @authoritative_ns_ip' to see the actual published record, bypassing any cached values.

The IP address and FQDN are complementary identifiers that serve different audiences and different purposes. The IP address is for machines; the FQDN is for humans and applications. DNS keeps them synchronized. When you understand how this relationship works, DNS configuration, server migrations, virtual hosting, and certificate management all become significantly easier to reason about. Verify the IP address your FQDN resolves to right now.

Frequently Asked Questions

Q.What is an FQDN?

A Fully Qualified Domain Name (FQDN) is a complete hostname that specifies an exact location in the DNS hierarchy. For example, 'mail.example.com.' is an FQDN that includes the subdomain, second-level domain, top-level domain, and the implied DNS root. It fully identifies a specific host without ambiguity, unlike a partial hostname that requires a search domain to resolve.

Q.How does DNS translate an FQDN to an IP address?

Your OS stub resolver queries a recursive DNS resolver, which queries root nameservers, then TLD nameservers, then the authoritative nameserver for the domain, progressively narrowing down to the A or AAAA record containing the IP address. Results are cached at each level according to the TTL value in the DNS records, typically for minutes to hours.

Q.Can one FQDN point to multiple IP addresses?

Yes. A single FQDN can have multiple A records pointing to different IP addresses—this is Round-Robin DNS or DNS load balancing. Each query may return a different IP, distributing traffic across servers. CDN providers use geoDNS to return different IPs based on the querying resolver's location.

Q.Can multiple FQDNs point to the same IP address?

Yes. This is virtual hosting. A single server IP can host hundreds of FQDNs. HTTP connections use the Host header to identify the requested site. HTTPS connections use SNI (Server Name Indication) in the TLS handshake. The server selects the correct content or certificate based on the FQDN provided.

Q.What is a PTR record?

A PTR record provides reverse DNS lookup—given an IP address, it returns the associated FQDN. PTR records are stored in the in-addr.arpa zone for IPv4 and ip6.arpa for IPv6. They are essential for mail server sender verification and appear in log files and network diagnostics tools like traceroute.

Q.What is TTL in DNS and why does it matter?

TTL (Time to Live) is a value in DNS records specifying how long resolvers may cache the answer in seconds. A TTL of 3600 means the cached answer is valid for one hour. Lower TTLs allow faster propagation of changes but increase DNS query load. For planned server migrations, reduce TTL to 300 seconds at least 48 hours before the change.

Q.Why can't I just use an IP address in my browser instead of a domain name?

Technically you can, but on servers using name-based virtual hosting you will often get a default or error page because the server cannot identify which site you want. For HTTPS, the server's certificate typically does not include the IP as a Subject Alternative Name, causing a certificate error. FQDNs also survive server IP changes invisibly, while direct IP access breaks when the server migrates.

Q.What is SNI and why is it needed?

Server Name Indication (SNI) is a TLS extension that allows the browser to specify which hostname it is connecting to during the TLS handshake, before the HTTP layer. This lets the server select the correct TLS certificate for the requested FQDN when multiple HTTPS sites share one IP. Without SNI, a server could only present one certificate per IP address.

Q.What is split-horizon DNS?

Split-horizon (or split-brain) DNS serves different DNS responses for the same FQDN depending on where the query originates. Internal clients receive private IP addresses for internal servers, while external clients receive public IPs or CDN addresses. This keeps internal infrastructure addresses hidden from the public internet while allowing consistent naming internally and externally.

Q.How does a DNS change propagate across the internet?

DNS changes propagate as cached records expire according to their TTL. There is no active push notification to resolvers. Each resolver holds the old answer until the TTL expires, then fetches the new value from the authoritative nameserver. Full propagation for a record with a 24-hour TTL can take up to 48 hours to clear all caches worldwide. Lowering the TTL before making a change accelerates propagation.

Q.What is the difference between a CNAME and an A record?

An A record maps an FQDN directly to an IP address. A CNAME record maps an FQDN to another FQDN (an alias). When a resolver encounters a CNAME, it follows the chain until it reaches an A or AAAA record. CNAMEs are useful for pointing multiple names at the same server without duplicating IP addresses in each record. CNAME records cannot exist at the zone apex (the root domain itself).

Q.Does FQDN matter for TLS/SSL certificates?

Yes. TLS certificates are issued for specific FQDNs or wildcard patterns. The certificate's Common Name (CN) and Subject Alternative Names (SANs) must match the FQDN the user is connecting to. Browsers reject certificates where the name doesn't match, displaying a security warning. Wildcard certificates (*.example.com) cover all single-level subdomains of a domain but not the apex domain itself.

Q.What tools can I use to inspect DNS resolution?

The 'dig' command (Linux/macOS) is the standard tool for DNS inspection. Use 'dig example.com A' for IPv4, 'dig example.com AAAA' for IPv6, 'dig -x IP_ADDRESS' for reverse lookup. On Windows, 'nslookup' provides similar functionality. For testing specific resolvers, use 'dig @8.8.8.8 example.com A' to query Google's resolver directly.

TOPICS & TAGS

ip vs fqdndns relationshipnetworking basicshostnamehow the web worksrelationship between ip address and fqdnhuman vs machine identity in networkinghow dns translates names to numbersstreet address vs gps coordinates analogybenefits of using fqdns for accessibilityvirtual hosting one ip for multiple fqdnshow servers know which fqdn you wantmachine efficiency of numerical addressesmigrating servers using dns resolutionit guide to hostname and domain setupsyncing identities for a faster internethow browsers perform domain name lookupsdomain records a registers and pointersunderstanding the dual nature of identityconnecting users to global server clustersDNS A record AAAA recordPTR reverse DNS lookupCNAME canonical name recordTTL DNS caching explainedSNI TLS virtual hostingHost header HTTP/1.1FQDN fully qualified domain name syntax