CNAME and ANAME are both solutions for pointing a hostname to your website. For example, yourapp.netlify.com to yourwebsite.com.

You’ve probably been using CNAME to make domain names point to websites. But instead, you can use an ANAME which has some added advantages because it gives you more flexibility.

In this article, you will learn what ANAME is, the advantages it has over CNAME, and when to use it.

What is ANAME?

ANAME, also called ALIAS, is a domain record type that can be used in place of a CNAME record. It's available from domain name companies such as Namecheap, GoDaddy, Hostinger, Google Domain, and more.

ANAME was born out of the combination of CNAME and another record type called A. So, ANAME is a CNAME and A record in one package.

ANAME is not a read DNS record but a way of simulating it. And that’s why it is called Alias name, or ANAME for short.

When you purchase a domain name and log in to its management panel, you will always see an option to use ANAME.

N.B.: Some domain name providers call it ALIAS instead of ANAME

Below is the Namecheap panel for managing domains and they call it ALIAS.

How Does ANAME Work?

Just like CNAME, ANAME maps one domain name to another. So, an ANAME is configured to point to another domain.

When the domain name an ANAME points to is queried by the client browser, it responds with an IP address. A CNAME, on the other hand, cannot point to an IP address, but an ANAME can. This is one of the advantages ANAME has over CNAME.

In addition, another advantage ANAME has over CNAME is that it can coexist with other records on that domain name. So if you want to have subdomains, you should use ANAME instead of CNAME.

Final Thoughts

This article explained what ANAME is and compared it with CNAME so you can know the advantages it has over CNAME.

You might also be wondering which to use between ANAME and CNAME, or when you should use one over the other.

This is the logic:

• if you know you cannot have other records on a domain name, use CNAME. This is because it cannot coexist with other data on the record for a domain name.
• If you will have other records like subdomain on that domain name, then use ANAME. And if you don’t know whether you'll still have a subdomain or not, use ANAME.

Thank you for reading.

Domain names are important because they make it easy for people to remember the address of your website.

Imagine what would happen if you had to remember the IP address for every website you wanted to visit. It would be a real pain to get around the web.

What Characters Can Go in a Domain Name?

A domain name can be any combination of English alphabet letters (A-Z) and numbers (0-9).

You can also use the dash character. For example, Class Central's domain was originally class-central.com, but they were able to buy classcentral.com without the dash, which looks more official, and is easier to type.

You can use these names in combination with various domain name extensions, such as .com, .net, and .org. These extensions are also called Top Level Domains or TLD's for short.

What is a TLD? Top-Level Domain Meaning and Examples

TLD stands for Top Level Domain. When the Domain Name System (DNS) first came online back in the 1980s, there were only a few TLDs: .com, .org, and .net.

In the US, there were also three TLDs that were heavily restricted and still are:

• .edu domains are only for accredited universities
• .gov is only for US government organizations
• .mil is only for the US military

Many countries have their own TLDs. For example, the UK has .uk and .co.uk. You may have seen the .io TLD before – it is reserved for the British Indian Ocean Territory, but is popular with tech companies because the io is similar to I/O, or Input Output.

Other popular TLDs are .co (which is like .com, but for startups).

Note that .org is one of the original TLDs, and is designed for nonprofits. But in practice, anyone can register a .org domain. For example, Craigslist.org is a for-profit.

So be careful: just because a company is using a .org domain does not mean they are a tax-exempt nonprofit. (By the way, if you're wondering, freeCodeCamp is a tax-exempt nonprofit.)

How do you register a domain name?

When you register a domain name, you are essentially reserving that name for your own use. No one else can use that domain name as long as you continue to renew it.

And you will have to renew it each year with a domain registrar service. The annual fees for doing this can be anywhere from $12 for a .com domain to hundreds of dollars for some specialty domain names.

Domain names are typically registered through domain name registrars, such as Google Domains, Name.com, or Namecheap. The process is usually pretty simple and straightforward.

Once you've registered a domain name, you'll need to point it to your web hosting provider or your own servers. This will tell the domain name where to find your website.

Now you know the basics of how domain names work.

I hope you've found this helpful. If you want to learn more about programming and technology, try freeCodeCamp's core coding curriculum. It's free.

Introduction

By the end of this article, you should have a better understanding of:

1. What DNS is and what it does
2. What DNS servers do
3. How Internet Protocol (IP) Addresses work in the context of DNS

Important concepts

There are some essential mental models to be familiar with when learning about DNS, DNS servers, and IP addresses. Going over these concepts now, before starting to learn about DNS, will

• help make sense of all the different terms used to describe behavior that fits into these models, and
• aid in memory retention.

Mental models give you a frame of reference when things get a little weird and unfamiliar.

So let’s lay the groundwork.

• Query and response. This is when Thing 1 asks Thing 2 for something, and Thing 2 responds to that request. Like this:

Query and Response

• Parent-child node relationships and graphs that look like this (only more complicated).

Tree graph

• Messages. It’s not a query and response because there is no response. In the world of DNS, the formatting and content of messages vary according to usage.

Message

• Client-server relationship. In simplest terms, a server is a software or hardware device that provides functionality for other software or hardware devices, called “clients.”

Prepare for a lot of talk about servers. As it turns out, there’s a whole lot of servers that go into this thing we call DNS, and how we, as humans, use it when we connect to the Internet.

Client-server relationship

What is DNS?

The Domain Name System (DNS) maps human-readable domain names (in URLs or in email address) to IP addresses. For example, DNS translates and maps the domain freecodecamp.org to the IP address 104.26.2.33.

To help you fully understand this description, this section details:

• Historical context for the development of DNS - what problems were it and IP addresses solving?
• Domain names
• IP addresses

Historical Context

In 1966, the Advanced Research Projects Agency (ARPA), a US government agency, founded a computer network called ARPAnet. In simple terms, think of ARPAnet as the first iteration of what we now know today as the Internet.

The main goals of ARPAnet included

“(1) providing reliable communication even in the event of a partial equipment or network failure, (2) being able to connect to different types of computers and operating systems and (3) being a cooperative effort rather than a monopoly controlled by a single corporation. In order to provide reliable communication in the face of equipment failure, ARPANET was designed so that no one point or link was more critical than any other. This was accompanied by the building of redundant routes and the use of on-the-fly rerouting of data if any part of the network failed.”

The Problems

DNS and TCP/IP were critical in solving two issues with ARPAnet:

For ARPAnet, there was a single location (a file called HOSTS.TXT) that contained all name-to-address mapping for every host on the network.

“HOSTS.TXT was maintained by SRI’s Network Information Center (dubbed “the NIC”) and distributed from a single host, SRI-NIC.[*] ARPAnet administrators typically emailed their changes to the NIC, and periodically FTP’ed to SRI-NIC and grabbed the current HOSTS.TXT file. Their changes were compiled into a new HOSTS.TXT file once or twice a week.”

There were three challenges with this set-up:

1. Traffic and load - distributing the file was becoming too much for the responsible host to handle.
2. Name collisions - each host had to have a unique name, and there was no centralized authority that prevented network users from adding a host with a conflicting (non-unique) name, thereby “breaking the whole scheme.”
3. Consistency - the act of updating the file and ensuring all hosts had the most updated version became impossible or at least very difficult.

In essence, HOSTS.TX was a single point of failure, so the entire process here didn’t scale well past a certain number of hosts. ARPAnet needed a decentralized and scalable solution. DNS was it. Source

Host-to-host communication within the same network wasn’t reliable enough. TCP/IP helped solve this issue.

1. Transmission Control Protocol (TCP) provides quality assurance measures for the process of turning messages (between hosts) into packets. The TCP protocol is connection-oriented, which means a connection between source host and destination host must be established.
2. Internet Protocol (IP) defines how messages (packets) are carried between source host and destination host. An IP address is a unique identifier for a specific path that leads to a host on a network.
3. TCP and IP work closely together, which is why they’re usually referenced like “TCP/IP.”
4. While I won’t dive into it in this article, both TCP and User Datagram Protocol (UDP) are used in the data transport layer of DNS. UDP is faster, much less reliable, and doesn’t require connections; TCP is slower, much more reliable, but needs connections. They are used as needed and appropriate in DNS; needless to say, the inclusion of TCP in APRAnet was a valuable addition to the data transport layer.

By the early 1980s, DNS and TCP/IP (and therefore, IP addresses) were standard operating procedures for the ARPAnet.

This history is very abridged. If you’d like to learn more about these topics, please reference the Resources section at the end of this article.

Now that we have some historical context, let’s move on to learning more about domain names and IP addresses.

Domain Names

In the context of DNS, a domain name provides a user-friendly way to point to non-local resources. This could be a website, a mail system, print server, or any other server that is available on the Internet. A domain name can be more than just a website!

“The goal of domain names is to provide a mechanism for naming resources in such a way that the names are usable in different hosts, networks, protocol families, internets, and administrative organizations.”

A domain name is much easier to remember and enter into a terminal or Internet browser, than an IP address.

A domain name is part of a Uniform Resource Locator (URL), but the terms are not synonymous. A URL is the complete web address of a resource, while the domain name is the name of a website and is a sub-component of every URL.

While there are technical distinctions between URLs and domain names, web browsers usually treat them the same way, so you’ll get to the website if you type in the complete web address, or just the domain name.

Top Level Domains and Second Level Domains

There are two parts to any given domain: top-level domain (TLD) and second-level domain (SLD). The parts of a domain name become more specific when moving from the right (end) to the left (beginning).

This can be confusing at first. For example, let’s look at “freecodecamp.org”

• URL: https://www.freecodecamp.org
• Domain name: freecodecamp.com
• TLD: org
• SLD: freecodecamp

In the early days of ARPAnet, there were a limited number of TLDs available, including com, edu, gov, org, arpa, mil, and 2-letter country code domains. These TLDs were initially reserved for institutions participating in the ARPAnet, but some later became available on commercial markets.

Today, there is a comparative wealth of available TLDs, including net, aero, biz, coop, info, museum, name, and others.

Second-level domains are the domains that are available for individual purchase through domain registrars (for example, Namecheap).

IP Addresses

While IP addresses are related to DNS in their function, the Internet Protocol itself is technically separate from DNS. I’ve already provided historical context for this distinction, so now I’ll explain how IP addresses function.

An IP address, as previously mentioned, is a unique identifier for a specific path that leads to a host on a network. I’d like to reference the analogy of a phone number and a phone: a phone number doesn’t represent the phone itself, it’s just a way to reach the person with the phone.

This analogy is reasonably appropriate (at least, on a surface level), with IP addresses. An IP address represents an endpoint, but it isn’t the endpoint itself. IP assignments can be fixed (permanent) or dynamic (flexible and may be reassigned).

Like a domain name, the organization of IP addresses follows a hierarchical structure. Unlike domain names, IP addresses get more specific going left-to-right. This is an IPv4 example below:

This diagram shows that 129.144 is the network part and 50.56 is the host part of an IPv4 address.

• Network: the unique number assigned to your network
• Host: identifies the host (machine) on the network

If greater specificity is needed, network administrators can subnet the address space and delegate additional numbers.

How many IP addresses are there?

IPv4 was the very first iteration of IP that ARPAnet used in production. Deployed in the early 80s, it’s still the most prevalent IP version. It’s a 32-bit scheme, and can therefore support slightly over 4 billion addresses.

But wait, is that enough? Nope.

IPv6 has a 128-bit scheme, which allows it to support 340 undecillion addresses. It also offers performance improvements on IPv4.

Example IPv4 address:

• 104.26.2.33 (freeCodeCamp)

Example IPv6 address:

• 2001:db8:a0b:12f0::1 (the compressed format and not pointing to freeCodeCamp)

How does the Domain Name System work?

So, we’ve learned about domain names! We’ve learned about IP addresses! Now how do they relate to the Domain Name System?

First of all, they fit into the namespace.

The Domain Namespace

As implied by the language “top” level domain and “second” level domain, the namespace is based on a hierarchy

“...with the hierarchy roughly corresponding to organizational structure, and names using "." as the character to mark the boundary between hierarchy levels.” Source.

This tree graph, with the root at the top, best illustrates the structure:

The Namespace

Let’s break this down, starting at the top.

The top of this graph, noted with a “.” is called the “root.”

“The authoritative name servers that serve the DNS root zone, commonly known as the “root servers”, are a network of hundreds of servers in many countries around the world. They are configured in the DNS root zone as 13 named authorities.”

The root domain has a zero-length label.

From here-on down, each node (dot) in the graph has a unique label up to 63 characters long.

The first level down from the root are the TLDs: the com, org, edu, and gov. Please note that this graph does not contain a full list of TLDs.

Below TLDs are the SLDs, the second-level domains. The children of each node are called “subdomains,” which are still considered part of the parent domain. For example, in freecodecamp.org, freecodecamp (the SLD) is a subdomain of org (the TLD).

Depending on the hierarchy of the website, there may be third-, fourth, fifth- level domains. For example, in hypothetical-subdomain.freecodecamp.org, hypothetical-subdomain is the third-level domain, and the subdomain of freecodecamp. So on and so forth, at least up to 127 levels, which is the maximum allowed by DNS.

Who manages the namespace?

Wouldn’t it be nuts to try to have one person or organization administer everything? Yes, it would. Especially because one of the chief design goals of DNS was to promote distributed, decentralized management of the system at large.

I wish I could tell you the folks in charge are called the “Namespace Kings,” but alas.

Each domain (or subdomain) in the domain namespace is or is part of a zone, “an autonomously administered piece of the namespace.” So, the namespace is broken into zones.

Responsibility for those zones is managed through delegation and administration.

The process of assigning the responsibility of subdomains to other entities is called delegation.

For example, the Public Interest Registry administers the domain name org, and has since 2003. Public Interest Registry may delegate responsibility to other parties to manage subdomains of org, say freecodecamp. And then whoever administers freecodecamp may assign responsibility for the subdomains of freecodecamp (for example, hypothethical-subdomain.freecodecamp.com) to another party.

If someone (an organization, team, or individual) administers a zone, what they’re doing is administering the nameserver that is responsible for the zone.

This brings us into one of the most foundational concepts in the Domain Name System.

Domain Name Servers

“The programs that store information about the domain namespace are called nameservers.”

At this point is where thinking about a client-server relationship, at least initially, is useful. Domain nameservers are the “server” side of the client-server relationship. Nameservers may load one, hundreds, or even thousands of zones, but they never load the entire namespace. Once a nameserver has loaded the totality of a zone, it is said to be authoritative for that zone.

To understand why nameservers function the way they do, it’s useful to understand the “client” part of the relationship.

Resolvers

In DNS, the client (the requester of information) is called the “resolver,” which may seem backward at first. Wouldn’t the server that is resolving the request be called the “resolver?” I thought so, too, but it’s not. Best to just memorize that and move on.

Resolvers are typically included, de facto, in most operating systems, so the applications installed on the OS don’t have to figure out how to make low-level DNS queries.

DNS queries and their responses are types of DNS messages, and have their own data transport protocol (usually UDP). Resolvers are responsible for helping applications installed on the OS translate requests for DNS-related data into DNS queries.

In sum, resolvers are responsible for packaging and sending off requests for data. Once the resolver receives the response (if at all), it passes that back to the original requesting application in a format consumable to the requesting application.

Back to Nameservers

Now that we are a bit more familiar with the client-side of the relationship, we need to understand how domain nameservers respond to resolver queries.

Nameservers respond to DNS queries through resolution. Resolution is the process by which nameservers find datafiles in the namespace. Depending on the type of query, nameservers respond differently to different queries, but the end goal is resolution.

Query Types

Type of query? Yes, there are multiple types of DNS queries. But first, what’s usually in a DNS query? It’s a request for information, specifically for the IP address associated with a domain name.

• Recursive: recursive queries allow the query to be referred on to multiple nameservers to be resolved. If the first queried nameserver doesn’t have the desired data, then that nameserver sends the query along to the most appropriate next nameserver, until the nameserver with the desired datafiles is found and sends a response to the resolver.
• Iterative: iterative queries require the queried nameserver to respond either with the desired data or with an error. The response may contain the IP address of the most appropriate nameserver to send the request to next; the resolver may then send another request to that, more appropriate, nameserver.

In case you need it, you can also query for the domain name, if all you have is the IP address. This is called a reverse DNS lookup.

Once the query reaches a nameserver that contains the desired datafiles, then the query can be resolved. Nameservers have a number of datafiles associated with them, all or some of which may be used to resolve the query.

Resource Records (RRs)

These are the datafiles in the domain namespace. These datafiles have specific formats and contents.

The most common RRs:

• A Record: if you haven’t heard of any other RRs except for this one, that would make sense. It’s likely the best-known RR and contains the IP address of the given domain.
• CNAME Record: if you haven’t heard of any other RRs except for this one and the A record, that would also make sense. The “C” stands for “canonical”, and is used instead of an A record, to assign an alias to a domain.
• SOA Record: this record contains administrative information about the one, including the email address of the administrator. Hint: if you administer a zone, make sure there’s a valid email address here, so folks can get in touch with you if needed.
• Other important Resource Record (RR) types are PR, NS, SRV, and MX. Read about them here.

Caching and Time to Live (TTL)

When the local nameserver receives a response from a query, it caches that data (stores it in memory), so next time it receives the same query, it can just answer the query directly rather than go through the original, longer resolution process.

But once this information is cached, it is both static and isolated, and is therefore at risk of becoming out of date. Therefore, resource records all have what is called a time to live (TTL) value, which dictates how long that data can be cached. When that time runs out (reaches zero), the nameserver deletes the record.

Important note: TTL doesn’t apply to the name servers that are authoritative for the zone that contains the resource record. It just applies to the nameserver that cached that resource record.

A Day in the Life of a Query

We’ve covered a lot of ground in this article, and it’s been heavy on the concepts. To tie this all together and make it real, here’s a day (figurative day) in the life of a query.

Source

So why do I need to know all of this?

There are so many reasons to be familiar with DNS and IP address related concepts.

• First, it’s a backbone of the Internet, the thing many of us use, develop feelings for (love/hate/you-name-it), and take for granted every day. It’s important to be familiar with the structures that enable us to accomplish great things today with technology and the Internet today.
• Incredibly smart people spent decades of their lives building this stuff! Let’s acknowledge and appreciate their contributions.
• Now that I got the gushy stuff out of the way, it’s important to be familiar with DNS concepts in case you’re responsible for anything relating to infrastructure in your company or team or your own business. Having a frame of reference when significant issues crop up allows you to act that much faster and find solutions that much sooner.

Conclusion

At this point, you should understand what DNS is and what a nameserver is, as well as be familiar with technical concepts relating to IP addresses.

Many books have been written about and dive deeper into the fascinating world of DNS, and there is so much more to learn. The topics that were not included in this article but are either part of DNS or very related include:

• Nameserver implementations
• Forwarding
• (More about) node labels
• Primary and secondary nameserver relationships
• Retransmission algorithms
• Load balancing
• Plus, other more general topics about the how the Internet functions, like:
• World Wide Web
• HTTP
• FTP
• Communication protocol layers: link layer, IP layer, transport layer, Internet layer, etc.

For those of you who are still reading and want to learn more about DNS, I first and foremost recommend “DNS and BIND, 5th Ed.”, written by Cricket Liu and published by O’Reilly Media. It’s invaluable.

I also encourage everyone to poke around in the original Request for Comments (RFCs) linked below. Not only are there points for reading primary sources, but they’re also exceptionally well-organized and comprehensible documents, which is why I quoted them in this article.

Resources

1. RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES
2. RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
3. RFC 1122: Requirements for Internet Hosts -- Communication Layers
4. More about DNS Design Goals, from Connected: An Internet Encyclopedia
5. How the Internet was Born from the ARPAnet to the Interpret, from The Conversation
6. Learning DNS Video Course, by Cricket Liu, from O'Reilly Media

A bit about me

I'm Chloe Tucker, an artist and developer in Portland, Oregon. As a former educator, I'm continuously searching for the intersection of learning and teaching, or technology and art. Reach out to me on Twitter @_chloetucker and check out my website at chloe.dev.