A fully qualified domain name or FQDN is the complete URL of a certain site or server. Using a site’s FQDN is often more reliable than using its IP address or, in some cases, its partially qualified domain name.
For example, let’s say your company website’s URL is “yourcompany.com.” If you were hosting an email service on your company website (which you probably would), the email service might have an FQDN of mail.yourcompany.com. By specifying “mail.” before the rest of the domain name, you’ve provided a fully qualified domain name that refers to a specific service.
If that isn’t entirely clear, don’t worry. In this article, we’ll dive deep into FQDNs, how they work, and when you might (or might not) want to use one.
What Is a Fully Qualified Domain Name?
A fully qualified domain name (FQDN) is the complete domain name of a specific server or host on the Internet. But what makes a domain name “complete?”
The answer depends on the domain — and its many parts.
While one host might have an FQDN of “www.myserver.com,” another might have an FQDN of “mail.anotherserver.com.” For the second case, if specifying the “mail” subdomain is required to reach a specific host (in this case, it’s likely a mail server), then “mail.anotherserver.com” is that host’s FQDN.
To put it a little more simply, an FQDN is almost like a complete path to a certain host. Where each part of a domain name (such as the name itself, “.com,” and so on) specifies one part of the path, the FQDN is the full path or address.
It’s almost like specifying an apartment number after the address of an apartment building. For example, if you lived in unit 21 of 123 Kinsta Drive, then “123 Kinsta Drive #21” or “123-21 Kinsta Drive” would be the FQDN of your apartment. As we’ll see later, the address of the apartment building itself is called a partially qualified domain name (PQDN).
To make a little more sense of this, let’s dive deeper into the structure of FQDNs and domain names in general.
Structure of an FQDN
An FQDN consists of two distinct parts: a host name and a domain name. Going back to the “myserver.com” example, “myserver” is the host name, while “.com” is the domain name.
But isn’t the entire address (“myserver.com”) technically the domain name? Yes, but there are a few distinctions. Depending on what you’re referring to, some terms can even be used interchangeably — even by your domain registrar!
Before things get too complicated, let’s look at a clear example.
The domain shown in the link is a complete URL or uniform resource locator. In this case, the FQDN is just “www.internetx.com,” with “internetx” as the second-level domain and “.com” as the top-level domain extension. Together, the top and second-level domains come together to form the single domain name “internetx.com.”
But our FQDN isn’t complete yet! We need just one more component, which is the subdomain name.
By default, the subdomain for most URLs is “www,” short for World-Wide Web. This subdomain specifies that the domain name can be viewed in a web browser and accessed using the hypertext transfer protocol (HTTP, or the “https://” prefix shown in the image).
While you don’t need to worry about HTTP, the subdomain is a very important part of an FQDN. With the default “www” subdomain, the FQDN of our example is “www.internetx.com.” While there can be variations depending on which page you want to visit (such as “www.internetx.com/contact”), “www.internetx.com” remains the FQDN or host name.
For example, let’s say you registered “www.mysite.com” with your domain registrar.
- .com is the top-level domain
- mysite is the second-level domain
- mysite.com is the domain name
- www.mysite.com is the fully-qualified domain name (FQDN)
By specifying the complete path “www.mysite.com,” we’ve specified the full or fully-qualified domain name.
Now here’s where things get a little interesting. Remember the subdomain “www?” Well, it turns out that’s not the only possible subdomain — or the only possible FQDN, for that matter.
Depending on the owner’s or administrator’s settings, a host might have multiple subdomains that can take on names other than “www.” We saw this earlier with the “mail.anotherserver.com” example, where the preceding “mail.” is the subdomain of “anotherserver.com.”
Here, “mail.anotherserver.com” is the FQDN of “anotherserver.com”’s mail server. The administrator could also set up another subdomain, such as “test,” which would have the separate FQDN “test.anotherserver.com.”
From this example, you can see that it’s possible for a single domain to have multiple FQDNs. Since each subdomain specifies a different resource (such as a mail server or something else), each also has its own FQDN that also specifies that same resource. In other words, if you want to access something specific on a web host, you need to specify its full path — in this case, the domain with the appropriate subdomain attached to it.
So, just to recap: an FQDN is the full domain name for a specific resource. If you’re simply trying to access the homepage at “myserver.com,” then “myserver.com” is the FQDN for the homepage. Similarly, if you’re trying to access the mail server at “mail.myserver.com,” then “mail.myserver.com” is — you guessed it — the FQDN for the mail server.
However, an FQDN isn’t the only type of “qualified” domain name. In the next section, we’ll take a look at partially qualified domain names and how they differ from FQDNs.
FQDN vs Partially Qualified Domain Name (PQDN)
A partially qualified domain name (or PQDN) specifies only part of a domain name. This is usually the host name, such as “myserver.com” rather than the complete FQDN “mail.myserver.com.”
However, a PQDN can be any part of an FQDN. For example, check out the slide below.
While you don’t have to worry about “null strings” and other jargon, take a close look at the two boxes at the bottom of the slide.
See the three examples of FQDNs (“challenger.atc.fhda.edu,” etc.) and the associated PQDN for each. Note how a PQDN can be any partial segment of an FQDN, such as just the “www” in “www.funny.int.”
But why bother making the distinction or even caring about PQDNs in the first place?
Many of the reasons are largely technical — and we won’t bore you with them. However, if you’re planning on using an FQDN for your blog or website (which you probably should), accounting for certain PQDNs is key to making it accessible.
For example, if a user uses a PQDN to access your website, you may want to enable settings that automatically fill in the missing parts to create an FQDN and redirect them to a specific resource. Most hosting providers will provide different options for configuring this setting.
Though the technical specifics are beyond the scope of this article (and can vary between hosting providers anyway), it’s important to keep in mind. Being able to convert a PQDN to an FQDN automatically is the primary reason web hosts should be aware of FQDNs in the first place!
Let’s wrap up with one more example to tie everything together.
An Apartment Example
Remember our apartment building from earlier? Well, here’s a picture of it.
Pretty swanky, right?
Suppose you’ve just moved into the top-right apartment shown in the red box (and lucky you, it’s a corner unit). You get the keys from the landlord, and you’re ready to update your mailing address and start receiving spam mail again.
Now let’s say your apartment number is #10, and the address of the apartment building is 123 Kinsta Drive. What would you write as your address?
Common sense would say something like “123 Kinsta Drive #10” or “123-10 Kinsta Drive.” However, if you only specified “123 Kinsta Drive,” your mail would only show up in the building’s lobby and not in your mailbox. Similarly, if you just said “#10,” then your mail wouldn’t get anywhere at all.
To make sure your mail gets to you, you specify your full address — 123 Kinsta Drive #10. You can think of this as the FQDN for your apartment.
Similarly, you can think of “123 Kinsta Drive ”as the PQDN (or domain/host name) of your apartment. Here, adding your unit number is the subdomain that creates the FQDN (your full address).
Sometimes the PQDN is enough for both web hosts and apartment buildings. For example, if the sender specified your name but not your unit number on the sending address, the apartment concierge might recognize that it was intended for you and complete the address themselves. This is the same as a web host recognizing a PQDN and filling in missing information to complete an FQDN.
Whew! That was a lot of information, but hopefully, you get the idea by now.
So, after all of that, what’s the benefit of having an FQDN? While we’ve already mentioned how it can help users navigate to specific resources, there are a few more benefits that make FQDNs invaluable.
Why Have an FQDN for Your Site?
Whether you’re a site administrator or just a visitor, using an FQDN is useful for many possible reasons. Here are some of the most common benefits.
More Convenient Than an IP Address
There are two ways to address a website: the website’s FQDN or IP address.
Short for Internet Protocol, IP is a set of rules responsible for how data is formatted and sent over the Internet. It’s this set of rules that allows us to visit websites, download files, and more.
Part of this set of rules is an addressing scheme known as an IP address. Just like our apartment building at 123 Kinsta Drive, every device connected to the Internet — be it a computer, server, or one of those smart refrigerators — has its very own IP address. Accessing a website requires sending “mailing” data back and forth between your computer and the website’s server.
When we provide a domain name, we’re providing a label for an IP address. For example, a quick test shows that the IP for the FQDN “kinsta.com” is 104.18.42.131.
Now, which would you rather type into your browser: a clunky chain of numbers or simply “kinsta.com?” If you’re like most people, you’d probably prefer the domain name.
Such is the benefit of having a dedicated FQDN. While most web hosting plans allow easy integration with domain names, it’s technically not the default option. As a result, having an FQDN or domain name for your site is crucial for making it accessible and easy to navigate.
As we’ll see in the next section, we can also have multiple FQDNs for multiple resources.
A Unique Path for Every Resource
Sometimes, your website can be more than just a website. You might want to have a separate email server under the same domain name. Or maybe you want to link to a separate server so you can host an app or software platform.
In any case, adding other resources — namely servers for hosting email and apps — usually requires a separate IP address for each resource. As a result, each resource can also have a separate FQDN.
For example, the diagram below shows multiple clients (personal devices) connecting to servers over the Internet.
Here, each server in the diagram could fulfill a different function on the same website, such as one being a web host and the other a mail server. However, despite being used for the same website, each might have a separate IP address or FQDN.
Having a separate FQDN for separate resources is extremely convenient when trying to access, say, your site’s email server without visiting the homepage. For FQDNs, this split is usually done using subdomains, such as prefixing “mail” to “myserver.com” to create the FQDN “mail.myserver.com.”
No matter how it’s done, FQDNs make it much easier to segment and access specific resources for your website. As we’ll see in the next section, this also helps keep things tidy.
Better Organization
By assigning FQDNs to distinct sections of your website, you’ll enjoy greater visibility while also keeping everything organized.
Though the last section focused on different FQDNs for different servers, it’s also possible to divide a single server to create multiple virtual servers. Each of these virtual servers can have its own IP address and, by extension, FQDN.
That may seem a bit high-tech, but it’s a common practice known as virtualization. In fact, many managed hosting services provide virtualization features.
For an example, check out the image below.
Here, a single server is virtually divided into multiple servers using virtualization. The virtualization is handled by a special type of operating system known as a hypervisor, which assigns a portion of the server’s physical hardware (memory, CPU, etc.) to each virtual server.
If the server is also connected to the Internet (such as a web server), then the hypervisor can also assign virtual IP addresses, which are each accessible through FQDNs. While the server itself will still have only one IP address, the hypervisor can help route traffic to different virtual servers depending on the provided FQDN.
But don’t worry too much about the specifics of virtualization — it’s only an example to show how organized you can be with FQDNs. Similar to this example, you can also use FQDNs to access individual domain services and protocols (such as the File Transfer Protocol or FTP) on the same server.
Necessary for Obtaining SSL Certificates
Secure sockets layer (SSL) certificates are only granted to websites with an FQDN. As a result, it’s not only beneficial for anyone looking to establish trust — it’s also a necessity.
But what’s an SSL certificate?
When you shop online, you may (hopefully) notice that your browser bar changes when you make a transaction. As shown in the image above, this change is usually in the form of a padlock and an “https” (instead of a plain “http”) in front of the URL.
It may be a subtle change, but it’s an important one. The change is thanks to SSL certificates, which are small data files that secure and encrypt the connection between a user and a website. As a result, SSL certificates are extremely important for safe transactions and establishing trust.
However, the only way to get an SSL certificate is to have an FQDN for your website. Since SSL certificates try to link an organization’s identity to a location (such as an ecommerce store to its physical server),
While we won’t dive too deeply into the types of SSL certificates, note that one is required for each FQDN on your website. In other words, if your site has FQDNs “www.myserver.com” and “shop.myserver.com,” then you’ll need two SSL certificates if you want to secure both.
Since domains and SSL certificates usually cost money (unless you get a free one with Kinsta’s hosting plans), it’s typically best to secure the FQDN where a secure connection is necessary. For example, “shop.myserver.com” would have priority over “www.myserver.com,” assuming that users would be completing secure transactions there. That way, when the user goes to check out, the HTTP traffic will be automatically routed to HTTPS and secure the connection.
Having an SSL certificate and FQDN can also help boost your search engine rankings in Google and more.
Easier Alternative for Remote Connections
An FQDN is usually the most convenient way to establish remote connections. The following screenshot might be familiar to some enterprise users.
It may seem obvious, but specifying an FQDN for a remote host or virtual machine isn’t the only option available. Just like connecting to a website with its IP address, you can also connect to a remote host using the host’s IP address.
Of course, FQDNs and IP addresses still represent the same thing. However, when you establish a remote connection with an FQDN, the DNS server compares it against a table of linked IP addresses. Once a match is found, the server connects to the remote host, which will usually send back a login prompt.
Apart from being the more convenient option, using an FQDN is sometimes your only option. For example, if you’re trying to connect to a remote host that doesn’t share the same Internet service provider (ISP) as you, you’ll often need to use an FQDN. This is so your DNS can resolve the name and connect you to the right host.
Summary
An FQDN is an easy and convenient way to specify a complete path to a particular server or host. Apart from being convenient, having an FQDN is also useful for organizing your resources, obtaining SSL certificates, and connecting remotely.
Of course, every FQDN needs a reliable, managed host. For more information on Kinsta’s Application Hosting, Database Hosting, and Managed WordPress Hosting, schedule a free demo or contact a hosting expert today.