Table of Contents

• Table of Contents

• The DNS Resolution Process

• Finding the First DNS Server: Defaults, DHCP, and Manual Settings

• How DNS Resolution Powers Your Application’s Network Requests

  • Valid IP Check

  • Application Cache Lookup

  • Operating System Cache Check

  • Forwarding to Configured DNS Server

  • Recursive Resolution Across Servers

• Understanding the Role of the Recursive Resolver

  • Recursive Resolver and Root Name Server Interaction

  • Recursive Resolver and TLD Server Interaction

  • Recursive Resolver and Authoritative Name Server Interaction

• Domain Registrars and DNS Setup for New Domains

  • What Are Domain Registrars?

  • What Happens in the DNS System When You Buy a New Domain?

• Conclusion

The DNS Resolution Process

When you type a domain name like example.com into your browser, it loads the website almost instantly. So how does it do this?

Well, DNS resolution makes it happen, acting like the internet’s GPS to turn that name into an IP address (such as 192.0.2.1) that computers use to find servers.

DNS resolution works by sending a query through a chain of DNS servers, each one helping to pinpoint the exact address. This process starts with a crucial step: your device needs to know which DNS server to contact first, either one set automatically or one chosen for speed and reliability.

Finding the First DNS Server: Defaults, DHCP, and Manual Settings

For DNS to function, a device must know the IP address of at least one DNS server. This is achieved through preconfigured settings, automatic configuration via DHCP, and manual configuration.

Devices like routers, smartphones, and computers often ship with hardcoded DNS server IPs. Common examples include Google Public DNS (8.8.8.8, 8.8.4.4) and Cloudflare DNS (1.1.1.1). These serve as default starting points for DNS queries.

Also, when a device connects to a network (for example, home Wi-Fi), a Dynamic Host Configuration Protocol (DHCP) server – typically on the router – assigns an IP address and DNS server addresses. These are often provided by the Internet Service Provider (ISP), such as Comcast’s 75.75.75.75, but can be overridden with alternatives like OpenDNS (208.67.222.222) or Quad9 (9.9.9.9).

Advanced users can manually specify DNS servers. Public DNS providers use memorable IP addresses for simplicity, such as Google’s 8.8.8.8 (repeating digits), Cloudflare’s 1.1.1.1 (short sequence), or Quad9’s 9.9.9.9 (repeating digits).

This design ensures seamless operation for most users, with DHCP and default configurations, while allowing power users to choose faster or privacy-focused DNS services.

How DNS Resolution Powers Your Application’s Network Requests

When an application, like a web browser or a backend service, wants to make a network call – such as an HTTP request to load a webpage, a gRPC call for microservice communication, or an API fetch to retrieve data – it triggers a series of checks and queries to translate a domain name into an IP address. This process is designed for efficiency, leveraging caches and a distributed network of servers to handle the internet’s massive scale.

1. Valid IP Check

The process begins by checking if the destination address is already a valid IP address, like 192.168.1.1. The system uses a regex check to confirm this. If it’s a valid IP, no DNS resolution is needed, and the network call proceeds directly.

Note that in rare cases, DNS resolution is skipped entirely if an IP address is used directly. For example, a user might manually type an IP, like 192.0.2.1, into a browser instead of a domain name, though this is unlikely since IP addresses are hard to remember compared to names like example.com.

Similarly, some applications make network calls using IP addresses directly, bypassing the need for DNS. While possible, these scenarios are uncommon due to the convenience of human-readable domain names.

2. Application Cache Lookup

If the destination address is a domain name, such as example.com, the application checks its own DNS cache, if it has one.

Modern browsers like Chrome and Firefox maintain built-in caches to speed up browsing. If the domain-to-IP mapping is found here, the process stops, and the IP is used for the network call.

3. Operating System Cache Check

If the application cache lacks the mapping or the application doesn’t have a caching mechanism at all, the request moves to the operating system’s DNS client, also known as the Local Resolver.

This varies by OS:

• Windows uses dnscache

• macOS uses mDNSResponder

• Linux uses the Name Switch Service

The DNS client checks two places: the OS-level DNS cache, which stores recent domain-to-IP mappings, and the hosts file, a local file that manually maps domains to IPs (for example, 127.0.0.1 localhost). If the mapping is found in either place, the process stops here.

4. Forwarding to Configured DNS Server

If the mapping remains unresolved, the DNS client sends the query to a configured DNS server, such as the ISP’s server or a public one like Google DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1). This server is a complex system with its own caches and a Recursive Resolver Service, like BIND or Unbound, which takes over the query.

Caching techniques

Caching, especially in recursive resolvers, stores query results to minimize redundant lookups and speed up responses for users:

• Recursive resolver cache: Stores query results from root, TLD, and authoritative name servers in recursive resolvers to speed up responses.

• Negative cache: Stores responses for non-existent domains or records to avoid repeated queries.

• Forwarded query cache: Stores responses from queries forwarded to other resolvers or DNS servers to enhance performance.

These caching mechanisms minimize external lookups (RFC 1035).

5. Recursive Resolution Across Servers

The recursive resolver, a core component of a DNS server, is responsible for performing recursive resolution to translate domain names like example.com into IP addresses.

As DNS records are distributed across multiple servers, the resolver parses the domain and executes a series of queries:

1. It contacts a root name server, which directs it to the top-level domain (TLD) server (for example, for .com).

2. The TLD server points to the authoritative name server for the specific domain.

3. The authoritative server provides the final IP address.

This distributed approach ensures scalability and reliability (RFC 1035).

Understanding the Role of the Recursive Resolver

The recursive resolver is the engine behind DNS resolution, working to convert a domain name like example.com into an IP address. Its journey begins by querying a root name server, the first step in navigating the DNS hierarchy to find the correct address.

Recursive Resolver and Root Name Server Interaction

To understand this interaction, let’s first explore what root name servers are and their role in DNS.

Exploring Root Name Servers

Root name servers form the foundation of the DNS hierarchy, responding to queries for top-level domain (TLD) records to initiate resolution. They direct recursive resolvers to TLD servers, enabling the lookup of domain IP addresses.

• There are 13 root server clusters, named a.root-servers.net to m.root-servers.net, operated by 12 organizations (VeriSign manages two). These clusters distribute global DNS query loads. As of May 10, 2025, 1,936 anycast instances ensure high availability and scalability, handling billions of daily queries (Root Server Technical Operations Association).

• Each cluster uses anycast routing, sharing a single IP address across multiple global servers. Queries are routed to the nearest or least-loaded instance, reducing latency, enhancing reliability, and providing redundancy if a server fails.

• The root hints file, provided by ICANN (IANA), lists root server IP addresses and is preloaded in resolvers. It enables initial DNS queries without needing to resolve root server domains, preventing circular dependencies and ensuring system stability.

The DNS began with just two root name servers in 1983. As the internet grew, more servers were added to meet demand. By 2002, the number reached 13, and anycast routing was proposed, allowing multiple servers to operate as a single cluster under one IP address.

Since then, the DNS has scaled by expanding these 13 clusters to handle global requirements (RFC 882, Netnod). For a detailed history, see the DNS Institute’s archive and History of ROOT-SERVERS..

How Recursive Resolvers Query Root Name Servers

The recursive resolver initiates resolution by querying a root name server for TLD records, relying on several mechanisms to ensure accuracy and efficiency.

• It uses the root hints file, ICANN’s list of root server IP addresses hardcoded in resolvers (for example, BIND), to avoid circular dependencies.

• Priming queries fetch updated root server IPs on resolver startup or cache expiry, ensuring reliability (RFC 8109).

• The root zone file, ICANN’s database of TLDs and their name servers, is used by root servers to respond with TLD details (IANA).

When querying, the resolver selects a root server and requests TLD records (for example, for .com). The response includes NS records (for example, a.gtld-servers.net for .com) and glue records, which are IP address records (A or AAAA) providing the TLD name servers’ IPs directly.

Glue records are critical when the requested name servers’ domains are within the queried domain (for example, ns1.example.com for example.com), preventing circular dependency by supplying the IP without resolving the domain.

For TLD queries, glue records are always included, speeding up resolution by avoiding additional lookups for TLD name server domains like a.gtld-servers.net, especially for busy TLDs like .com (RFC 1035).

Recursive Resolver and TLD Server Interaction

Once the recursive resolver receives the root server’s response, including glue records, it queries a TLD name server (for example, a.gtld-servers.net for .com). TLD name servers maintain zone files listing domains under their TLD (for example, example.com) and their name servers.

The TLD server responds with a referral, providing the authoritative name server records (for example, ns1.example.com for example.com). If the authoritative server’s domain is within the requested domain (for example, ns1.example.com), glue records are included to provide the IP directly, preventing circular dependency.

The resolver caches the response based on its TTL to speed up future queries. If the TLD server is unreachable, the resolver tries another TLD server from the root’s response (RFC 1035).

Recursive Resolver and Authoritative Name Server Interaction

• The recursive resolver then queries the authoritative name server (for example, ns1.example.com), which maintains zone files with DNS records like A, CNAME, or MX for its domain (for example, example.com).

• The server returns the requested record, such as an A record (for example, 192.0.2.1), AAAA, CNAME, or MX, depending on the query.

• Glue records from the TLD response provide the server’s IP if within the domain, avoiding circular dependency.

• The resolver caches the response based on TTL for efficiency. In rare cases, the server may delegate to another authoritative server (for example, for subdomains), requiring further queries. If unreachable, the resolver tries another authoritative server (RFC 1035).

Traditionally, zone files for Root, TLD, and Authoritative name servers were text files listing domains and their DNS records, guiding queries across the DNS hierarchy.

Modern DNS infrastructure has replaced these with efficient databases or in-memory databases, using optimized data structures like hash tables or tries for faster lookups and scalability. This shift supports the growing number of TLDs and high query volumes across all server types.

Similarly, the anycast routing proposal, introduced to enhance speed and reliability by distributing server instances globally, was designed for all name servers – Root, TLD, and Authoritative.

While root name servers universally adopt anycast, ensuring low latency and redundancy, not all TLD and authoritative name servers strictly follow it.

Some TLDs and smaller authoritative servers rely on unicast or limited anycast due to cost or operational constraints, leading to varied performance across the DNS hierarchy.

The following diagram illustrates the complete Domain Name Resolution process, summarizing the steps outlined above.

The following image shows the dig +trace google.com output, demonstrating the resolution process from root to authoritative name servers:

Domain Registrars and DNS Setup for New Domains

What Are Domain Registrars?

Domain registrars were originally established to manage the registration of domain names, allowing individuals and organizations to secure unique names (for example, example.com) for websites and online services. They act as intermediaries between domain owners and domain registries, which maintain the authoritative databases for top-level domains (TLDs) like .com or .org.

Registrars handle tasks such as registering domains, renewing them, and updating DNS settings, ensuring seamless integration with the global DNS system. Many registrars also offer additional services like web hosting and SSL certificates to support website operations.

GoDaddy and Hostinger are among many registrars, known for their user-friendly platforms and comprehensive service offerings.

What Happens in the DNS System When You Buy a New Domain?

When you purchase a new domain (like example.com) through a registrar like GoDaddy or Hostinger, the following steps occur in the DNS system:

• Step 1: Registration with the registry – The registrar sends your domain details to the registry for the TLD (for example, VeriSign for .com). The registry adds the domain to its database, recording the registrar as the managing entity and the authoritative name servers (for example, ns1.example.com) you specify.

• Step 2: Name server configuration – You configure the domain’s name servers at the registrar’s control panel (for example, GoDaddy’s Domain Portfolio or Hostinger’s hPanel). These name servers, often provided by the registrar or hosting provider (for example, ns1.hostinger.com), point to the DNS zone file that contains DNS records for your domain.

• Step 3: DNS zone setup – The DNS zone file, managed where the name servers point, is updated with DNS records like:

  • A record: Maps the domain (for example, example.com) to the hosting server’s IP address (for example, 192.0.2.1).

  • CNAME record: Aliases subdomains (for example, www.example.com) to another domain.

  • MX record: Directs email to mail servers.

If using the registrar’s hosting, these records may be set automatically. Otherwise, you manually configure them to point to your hosting provider’s IP.

• Step 4: DNS propagation – After updating name servers or DNS records, changes propagate across the global DNS network, which can take 24–48 hours due to caching and server updates. During this period, your website may not be immediately accessible.

• Step 5: TLD registry update – The registry updates its records to include the domain’s name servers, which are queried by recursive resolvers during DNS lookups. For domains with name servers in the same domain (for example, ns1.example.com for example.com), glue records (IP addresses of the name servers) are registered with the registry to prevent circular dependencies.

Conclusion

The Domain Name System (DNS) translates domain names into IP addresses, making the internet user-friendly. It resolves queries efficiently through a hierarchical system and caching, evolving from a few root servers in 1983 to a scalable, anycast-driven network today.

There is some work "under the hood" to ensure that, when you type in a human friendly name like Google, it takes you to the website you're expecting it to.

So, what's happening under the hood?

What are URLs?

You may be familiar with what a URL is. It's a simple link to a bit of content on the web. People use URL's daily to share videos, pictures, sites, articles – almost anything on the internet.

URL is an acronym for Uniform Resource Locator, and we can break them down into multiple smaller "pieces". Here's what makes up a standard URL:

Anatomy of a URL showing the Scheme, Domain Name, Path, and Parameters

A URL is just an address for a resource. The resources differ like we discussed, but they're just pointers all over the internet to take you to content you want to view.

As you can see in the graphic above, the breakdown of a URL is often:

• Scheme: this is the protocol a browser uses to access your content. Normally for websites it's HTTP (insecure), or HTTPS (secure).
• Domain name: the website name ("www.google.com" here)
• Port: a network port (80 in this example)
• Path: a path to a particular resource on the server
• Parameters: often key-value pairs, to serve extra data to the web server.

What are IP Addresses?

Humans and computers navigate the web very differently. Whilst most humans use URL's like we just discussed, to communicate between computers, computers use the Internet Protocol (IP).

The IP is a set of rules that route and address data packets (all the data you want to view) to make sure it arrives to your computer.

The Internet Protocol relies on devices and domains, all having their own IP address to connect and identify all the different segments (packets!) of the internet.

An IP address is a series of standardised numbers that range from 0 to 255 – separated by dots.

If you want to see IP addresses in action, and are familiar with terminals, you can type ping google.com in whichever terminal you like and you can see the IP address of Google.com.

A screenshot from a PowerShell terminal, showing a ping command to 216.58.212.206, and 0% packet loss.

You can test this further by typing 216.58.212.206 directly into your browser and seeing if it takes you to Google.

Hopefully this small example highlights why we use URL's. If both addresses (IP address and domain name) took you to the same place, would you rather be asked to remember Google.com or 216.58.212.206?

Note that some IP addresses change day to day (called dynamic IP addresses) – so the above IP address may not work, depending on if the IP address is dynamic or static.

Static IP addresses are ones that don't change – but to assign a single IP address to every machine would be impractical. It would be a logistical nightmare, too, as some people only log onto computers once a month to send an email, for example.

We could very realistically run out of IP addresses on today's current technology if we gave every device a unique IP address (if you want to read how IP addresses are allocated in greater detail, read here).

What is a DNS?

If we know computers communicate via the Internet Protocol and communicate using IP Addresses, how do we turn google.com into the website we use so regularly?

The answer is using a Domain Name System (DNS). The job of the Domain Name System is to transform human readable domain names into IP addresses.

There are four servers specifically that we'll discuss.

DNS Recursor

A DNS Recursor is like a waiter in a restaurant. It acts like a "front facing" part of the system to receive orders (normally from browsers) where the waiter then heads into the back to get what is needed.

In reality, it's just a server that receives DNS queries from browsers and returns information.

There are 3 different places the DNS recursor can generally get the information from depending on if any data has been cached:

• Root nameserver
• TLD nameserver
• Authoritative nameserver

So let's discuss them one by one.

What is a Root Nameserver?

The root nameserver's main job is to return the Top-Level Domain (TLD) server. **

This is an important step to map hostnames into IP addresses.

The root nameserver essentially acts like a catalogue that points to more specific locations.

What is a Top-Level Domain (TLD) Server?

If the root nameserver acts like a catalogue, the TLD server acts like a page in a catalogue.

The TLD server generally returns the final part of the host-name, like com for example, in "google.com".

What is an Authoritative Nameserver?

This server is like a row entry on the specific page of the catalogue.

The authoritative nameserver now can return the IP address for the requested hostname from the browser, back to the DNS recursor – which can hand it back to the browser.

DNS can be super confusing, and to understand the whole process may take a little while, so let's tie it together with a final example.

Example Request

Let's break down an example request from a user, and hopefully tie together this pretty complex process.

Each step in the flow starts to point closer and closer to the final address the user will eventually end up hitting.

Diagram showing the steps in the request process

Let's break down what's going on in this graphic:

Step 1:

A user types 'kealanparr.com' into their browser, and the query hits the DNS recursor.

Step 2:

The DNS recursor then queries a Root nameserver

Step 3:

The Root nameserver then responds to the DNS recursor with the address of a Top Level Domain server (TLD) such as .com.

Step 4:

The DNS recursor then makes a request to the .com TLD.

Step 5:

The .com TLD server then responds with the IP address of the Domain’s nameserver, kealanparr.com.

Step 6:

The DNS recursor sends a query to the domain’s nameserver.

Step 7:

The IP address for kealanparr.com is then returned to the resolver from the Domain nameserver.

Step 8:

The DNS recursor responds to the web browser request with the IP address of the domain requested.

Step 9:

At this point, the DNS lookup has returned enough data for the browser to make the request for the web page.

• The browser makes a HTTP request to the IP address.
• The server at that IP returns the webpage content to be rendered in the browser.

Conclusion

I hope this article has helped you to understand a few networking principles that affect the websites you use everyday.

IP addresses, DNS, and more are all technologies most people use daily but may not be very familiar with.

Cloudflare has an article that was helpful as I researched for this article, which you can read here.

I tweet my articles here if you would like to read more.

So being denied access to the internet when you are trying to mine nuggets of valuable information from your go-to web sites can be quite an ordeal. Especially when you are under pressure to complete a piece of urgently required work.

One particularly unwelcome cause of being denied access to the internet is the “DNS Server Not Responding” error. It’s like that old fable where a troll sits under a bridge and says “You shall not pass!”, or something about gobbling up those that wish to cross the bridge.

I’m happy to tell you that you should be able to defeat the troll and cross the bridge to internet access joy by following the simple trouble shooting steps discussed in this article.

What is the "DNS Server Not Responding" Error?

The “DNS Server Not Responding” error is a fairly common issue and is generally easy to fix. There are many reasons why this issue may occur. But fundamentally it is caused because the DNS server that is contacted during the processes of loading a web page is unable to find the site that contains the web page that you have requested.

This article explores what may have triggered this issue to occur and how you may go about fixing the issue.

Firstly, I think it is a good idea to gain at least a basic understanding of the “DNS Server Not Responding” error. To do this, let’s first understand DNS.

DNS stands for Domain Name System. A simple explanation of DNS is that it is a decentralised storage of human readable internet addresses, like the ones with which you will almost certainly be familiar (for example www.amazon.com or www.netlix.com).

The DNS maps these human readable URLs to their appropriate IP (Internet Protocol) addresses.

IP addresses are much less human readable, but are essential for the inner workings of the internet. IP addresses uniquely identify computers on the internet. The IP address associated with the URL, www.netflix.com, might for example, look like this, 69.53.224.255.

It is clearly easier for you to remember “www.netflix.com", rather than a string of numbers delimited by full stops, when you wish to access your favourite content on Netflix. So the DNS facilitates this for you, so that you don’t have to remember or manually lookup unfriendly strings of numeric data every time you wish to access a web site.

The common analogy to explain DSN is a telephone directory. Basically, as you would look up a telephone number using the name of the person you wish to call in a telephone directory, a similar look up is performed when you type in the URL (like www.amazon.com) of the web site you wish to view within your browser.

Thankfully you don’t have to manually look up the corresponding IP address for www.amazon.com, as this is performed behind the scenes for you automatically.

So the appropriate IP address is retrieved automatically every time you type in a URL into your browser. This IP address is then used to contact the appropriate server that hosts the relevant web site associated with the URL you have entered into your browser.

When the “DNS Server Not Responding” error occurs, this means that the decentralised naming systems responsible for automatically looking up the appropriate IP address based on the relevant hostname that you entered into you browser fails to respond.

There are many reasons why this error occurs, but fortunately there are also many solutions available to you to fix the issue.

An easy solution may be to simply change the web browser you are using or even simpler still, simply restart your computer. Yup, simply turning it off and then turning it on again could fix the issue.

However, if you are not so lucky and the problem still persists, don’t despair – there are many steps that you can take to find out the cause of the issue and subsequently fix it.

In this article you will learn a number of possible solutions to the “DNS Server Not Responding” error.

How to Fix "DNS Serger Not Responding"

Below, I've listed out the ways that you can try using to fix the “DNS Server Not Responding” error. The subsequent sections of this article provide details on each of these methods:

• Use a Different Web Browser
• Try Accessing a Web Site with a Different Device
• Restart your Router
• Investigate Possible Network Issues
• Manually Set your DNS Server
• Clear the DNS Cache
• Disable Internet Protocol Version 6
• Temporarily Deactivate your Firewall and Disable your Antivirus Software
• Reset your DNS Settings
• Update the Network Adapter Driver
• Disable all Network Connections Except the Connection you are Using to Access the Internet
• Restart your Computer in Safe Mode

Use a Different Web Browser

A potential solution to the “DNS Server not Responding” issue that's really simple is to try accessing the relevant website using a different browser.

If, for example, you are using Microsoft Edge or Mozilla Firefox as your browser at the time that the issue occurs, try using a different browser like Google Chrome to access the relevant website.

If using a different browser solves the problem, then make the browser that works your default browser. But if the issue still persists, then we at least know that the browser you have been using is not the source of the issue and our investigation into finding a solution to the DNS Server not Responding” issue must continue…

Try Accessing a Website With a Different Device

Try to use a different device connected to your home network to access the website you were trying to access when you received the error.

For example, use Wi-Fi from your mobile phone to access the relevant web site. If the issue persists, you know that the issue isn’t just with your primary device and the problem may have something to do with your router.

Restart Your Router

The “DNS Server not Responding” issue may occur simply due to data traffic. It may be that simply restarting your router can fix this issue.

You can restart your router by pressing the power button on your router. You can then unplug your router's power cable. Wait for about 30 seconds then plug your router into the power outlet again and press the power button to restart it.

Investigate Possible Network Issues

Running network diagnostics may point to network issues as the root cause of the issue.

Running Network Diagnostic is very simple on a Windows 10 OS. You can do this by following these steps:

• Open Control Panel. One way to do this is press the Windows Key + R to activate the “Run” box, then type “control” in the text box presented in the “Run” box and hit the enter key.

• Select the Network and Internet option presented within the Control Panel window.
• Click the Network and Sharing Center option from within the “Network and Internet” window.
• Click the Troubleshoot problems option presented under the "Change your network settings” heading within the “Network and Sharing Center” window.
• Click Additional troubleshooters -> Internet Connections -> Run the troubleshooter

The next step is to wait for the troubleshooter task to finish. If you are presented with any error messages, simply follow the steps on how to fix the relevant network issue.

Manually Set Your DNS Server

The source of your issue may be that your DNS server is down. In this case you’ll be pleased to know that you are able to manually change your DNS server.

You can change your DNS server to, for example, Googles Public DNS or CloudFlare’s public DNS. To change your DNS server, follow these steps:

• Invoke your Control Panel. One way to invoke your Control Panel is to activate your Start Menu and search for the Control Panel.
• In the Control Panel window click the Network and Internet option.
• In the Network and Internet window, click the Network and Sharing Center option.
• On the Network and Sharing Center window click on your active connection. For example, click the “ethernet” option if this is the connection currently being used or click the “Wi-Fi” option if it is clear that this is your active connection.
• In the dialog box that is presented to you, click the “Properties” button.
• In the dialog presented to you, you’ll see a list is presented under the “The connection uses the following items” heading.
• In this list, select the list item labelled “Internet protocol version 4 (TCP/IPv4)” then click the “Properties” button.

• You will be presented with another dialog box where you’ll see two fields. One will be labelled “Preferred DNS Server”, and the other which is directly under this field will be labelled “Alternate DNS Server”.
• First click the Use the following DNS server addresses radio button.
• To use Googles Public DNS server, enter 8.8.8.8 in the field labelled “Preferred DNS Server” and enter 8.8.4.4 into the field labelled “Alternate DNS Server”.

• You are also able to use CloudFlare’s DNS server for the same purpose. CloudFlare’s DNS address is simply 1.1.1.1
• Once you have entered your desired DNS server settings, ensure that the “Validate settings upon exit” checkbox is checked.
• Click the “OK” button to save your new DNS server settings.
• Restart your computer.

Clear the DNS Cache

You are able to flush the DNS cache which may resolve the “DNS Server not Responding” issue. This action will clear IP addresses and other DNS related data from your cache.

You can clear the DNS cache by running a command using your command prompt.

One way to invoke the command prompt is to press Window Key + R to invoke the “Run” box. Type “cmd” within the “Run” box and press shift+ctrl+enter to run the command prompt as an administrator.

At the command prompt, type in the following command: “ipconfig /flushdns” and them press the enter key. If the command has executed successfully, you'll see the appropriate message in the command window.

Disable Internet Protocol Version 6

At the time of writing this article, Internet Protocol Version 6 is the latest version of the internet protocol. Disabling the Internet Protocol Version 6 will not have detrimental effects on your computer’s operations, but it's been known to fix the “DNS Server not Responding” issue.

To disable the Internet Protocol version 6 on a Windows 10 operating system, just follow these steps:

• Go to Control Panel -> Network and Internet -> Network and Sharing Center
• Click on the relevant connection, for example “Wi-Fi”
• Click the “Properties” button on the dialog that is presented to you.
• In the list presented under the “This connection uses the following items” heading, uncheck the item labelled “Internet Protocol Version 6 (TCP/IPv6)”.

• Press the “OK button”

Temporarily Deactivate your Firewall and Disable Antivirus

If your firewall is Defender, you can follow these steps to disable it:

• To open control panel, press Windows Key + R to activate the “Run” box, then type “control” in the text box presented in the “Run” box and hit the enter key.
• In the top right hand text box, type in “win”

• An option labelled "Windows Defender Firewall” should appear in the search results. Click the “Windows Defender Firewall” option.
• Click the “Allow an app or feature through Windows Defender Firewall” option.

• Click the “Change settings” button.

• From the list presented to you within the dialog box that has just been invoked, find the browser that you are using, for example Google Chrome. Then make sure that both the private and public checkboxes next to the relevant item are checked.

• Once you've done this, try to access the relevant website using the relevant browser and see if the issue has been fixed.

There is a chance that your firewall was preventing you from accessing external data through your browser.

Note that it is not recommended to leave your operating system unprotected by reliable antivirus software indefinitely. Disabling your antivirus software in this instance is only recommended for testing if the relevant antivirus software is the cause of the “DNS Server not Responding” issue.

To temporarily turn off Microsoft Defender antivirus protection, follow these steps:

• Select Start and then type in "Windows Security” in order to search for the relevant application.
• Select Windows Security App from the search results.
• Go to Virus & Threat Protection.
• Under Virus & threat protection settings select Manage settings.
• Switch Real-time protection off.

Attempt to access the relevant website through the relevant browser to test if the “DNS Server not Responding” issue still occurs.

Reset DNS Settings

To reset your DNS Settings, follow these steps:

• Run the command prompt as an administrator. To do this activate the “Run” box by pressing Windows key + R.
• In the run box type “cmd” and press shift + ctrl + enter
• Type the following commands in the command prompt. After entering each command press the enter key, so that each command is run individually.

ipconfig /registerdns

ipconfig /release

Ipconfig /renew

netsh winsock reset

Once you have run these commands, close the command prompt and restart your computer.

Update the Network Adapter Driver

You can manually update your network adapter driver, but it is much easier to automate this task.

You can automate this through the use of free software like “Driver Easy” (https://www.drivereasy.com/download-free-version/). Simply download the free version of this software.

Make sure that before you run the free version of the Driver Easy software that you create a system restore point. This provides you with insurance, so in the unlikely event that you encounter a nasty surprise that adversely effects your computer, that you are able to return your Windows OS back to the state that it was in before you ran the Driver Easy software and encountered an unexpected issue.

To use the Driver Easy software, follow these steps:

• Run the software
• Click the “Scan Now” button
• Press the “Update” button next to any outdated drivers.

Disable all Network Connections Except for the Connection that you are Using

Disabling the additional network connections you may have setup on your computer (other than, for example, the Wi-Fi connection that you are using to access the internet) might fix the “DNS Server not Responding” issue.

To disable the relevant network connection, follow these steps:

• Firstly you must access your Network Connections. To access your Network Connections, press Windows Key + R to invoke the “Run” box
• In the “Run” box type in “ncpa.cpl” and press enter.
• Right click the relevant network connection and select “Disable” from the relevant context menu. Repeat this action until all connections except for the Wi-Fi connection you are using are disabled.

Restart your Computer in Safe Mode

When you start your computer in Safe Mode, this means the Windows operating system loads with a limited set of drivers and files. This can help you diagnose what is causing your “DNS Server not Responding” issue through a process of illumination (as it were).

So to start your PC in Safe Mode, follow these steps:

• Press the Windows Key + I to open Settings.
• Select Update & Security -> Recovery
• Under Advanced startup, select Restart Now
• Once your PC has startup to the “Choose an option” screen, select Troubleshoot -> Advanced options -> Startup Settings -> Restart
• Once your PC has restarted you’ll see a list of options
• Select 5 or press F5 for Safe Mode with Networking.

Try to access the web site that resulted in you getting the “DNS Server not Responding” issue. If the problem does not occur in safe mode this means that additional software may be the cause of the issue.

You can uninstall any additional software from your PC, one by one, and then test to see if the issue still occurs. If the issue does not occur after uninstalling particular software, this means that it is likely that this software was interfering with your internet access.

Conclusion

The “DNS Server not Responding” issue is relatively common and thankfully it is also relatively easy to fix.

It can be incredibly inconvenient to be denied access to the internet but hopefully the potential solutions outlined in this article will help you to once again have access to your favorite web sites.

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.

Here is what we'll discuss in this guide:

1. What is DNS cache?
   1. Why flushing DNS cache is important
2. How to flush DNS cache on MacOS
   1. How to access the terminal application on MacOS
   2. How to clear DNS Cache for your MacOS version

What is DNS Cache?

DNS acts much like an internet phonebook. Think of what a phonebook does – it maps a person's name to their respected phone number.

DNS (short for Domain Name System) maps domain names to their associated IP addresses.

A domain name, such as freecodecamp.org, is easily read, understood, and recalled by humans.

IP addresses (IP is short for Internet Protocol) is an address that is machine-readable and consists of a unique series of numbers. These numbers identify a device connected to the Internet.

Their format is not that human-friendly since it is hard to remember an exact sequence of numbers each time you want to visit a website.

DNS then maps freecodecamp.org to its associated IP address - 104.26.3.33.

Think of the DNS cache as a local storage area on your Mac.

It temporarily stores and keeps track of your computer's activity records like recent website visits.

Each time you visit a website by typing its URL (short for Uniform Resource Locator), the DNS cache will save the IP address associated with that website.

When you visit that same website for the second time, the lookup process is more efficient, and the lookup time is much shorter.

It helps save significant time.

Why Flushing DNS Cache Is Important

You should flush the DNS cache for a few reasons.

The two most important ones are:

1) Flushing DNS is a helpful step for troubleshooting Internet connectivity issues.

You may be getting DNS errors in your browser, such as the 'DNS Server Not Responding' message when trying to access a site and establish a connection.

Keep in mind that your local cache information can become outdated over time.

When DNS updates happen on a website, your Mac is still using the old, inaccurate information to load the requested page.

Flushing the DNS cache makes sure cache information is up to date.

2) Flushing the DNS cache prevents network security threats, malicious attacks, and DNS cache poisoning from happening.

Hackers can access and corrupt your saved DNS cache records.

For example, they could manipulate and change the IP address associated with a Domain Name of a website you have already visited and map it to a malicious one.

The next time you request to access that same website, there will be a redirection to a fake and corrupted URL.

Hackers can request personal and sensitive information, such as credit card numbers, and steal it.

Frequent flushing of the DNS cache will help prevent this from occurring.

How to Flush DNS Cache on MacOS

Clearing the DNS cache on your Mac is a relatively straightforward process, even if you don't have a lot of technical knowledge.

Here is what you will need:

• Access to the command line,
• Your computer password,
• To enter a text command (the command will depend on the version of macOS you are running).

How to Access The Terminal Application on MacOS

macOS has a built-in CLI (Command Line Interface) named Terminal.app, which allows you to enter text-based commands that the Operating System will carry out.

There are a few ways to open the terminal.

The easiest way is through Spotlight search.

For this, you can:

• Either navigate to the very top right corner of the screen and click on the icon that looks like a magnifying glass.
• Or, you can also use the Command Space shortcut.

Both will open up the following window:

From there, start typing terminal and click on the Terminal.app option that appears.

You should see a window open that looks similar to the following:

How to Clear DNS Cache For Your MacOS Version

In the terminal window, you will then need to enter a command.

The command is different depending on the version of macOS you are running.

Each version of macOS has a version number and a version name.

To find out the macOS version on your computer, click on the Apple icon at the very top left corner of your screen. From the dropdown menu that appears, select About This Mac.

In the Overview tab, you will first see the version name. Then, underneath that, you will see the version number.

In the table below, you will see the versions of macOS in reverse chronological order – from the most recent one to the oldest one.

Navigate to your version of Mac and copy the respective command.

After typing the command and hitting enter, there will be a prompt for entering your computer's password.

Keep in mind that when you are typing your password, you will not be able to view what you are typing – not even any asterisks.

It appears as though nothing is happening, but rest assured that something is.

Once you have entered your password and hit enter, you will not see a message indicating that the process is complete.

Instead, you will view a new terminal prompt.

Conclusion

And there you have it – your local DNS cache is now clear.

Hopefully, this has helped resolve any connectivity issues you may be experiencing.

Clearing DNS frequently is always a good idea to help fix troublesome internet connections and ensure your system is secure from potential threats.

Thanks for reading!

If you run a troubleshooter for the issue, you'll get a message like the below:

In your Chrome browser, you might also get an error like the one below:

This is because the Domain Name System (DNS) server is crucial in getting an internet connection on your computer.

As far as websites are concerned, the “DNS server not responding” error could be caused by DNS gaps and a DDoS (Distributed Denial of Service) attack. If this is the problem, you might have to wait for 72 hours for domain gaps to be fixed or the website admins to fix the security issues with the website.

On the user’s end, the “DNS server not responding” error could be caused by numerous reasons such as misconfigured DNS settings and outdated browsers.

If this is the cause, I will show you 7 ways to fix the error so you can restore your internet connection.

Table of Contents

• How Does the DNS System Work?
• 7 Ways to Fix the DNS Server Not Responding Error
  • Solution 1: Switch Browsers
  • Solution 2: Temporarily Disable Your Antivirus
  • Solution 3: Restart your Router or Modem
  • Solution 4: Flush your DNS Cache
  • Solution 5: Manually Change your DNS Server
  • Solution 6: Update Your Network Adapter Driver
  • Solution 7: Disable IPv6
• Final Thoughts

  How Does the DNS System Work?

Whenever you try to access a website, like freeCodeCamp.org, you type in the URL like “freecodecamp.org” to the address bar and hit ENTER.

Under the hood, the DNS server looks up the numerical address for freeCodeCamp.org. This numerical address is called an Internet Protocol (IP) address.

Once the browser gets this IP address, the website (freeCodeCamp.org or any other) will be shown to you. If the browser fails to find this address, then you might get the “DNS server not responding” error.

7 Ways to Fix the DNS Server Not Responding Error

Now let's go through seven ways you can use to get rid of the “DNS server not responding” error so your internet connection can be restored.

Solution 1: Switch Browsers

The “DNS server not responding” error could be showing up because of the browser you’re currently using. Some browsers have their own DNS cache and if there’s an issue with the cache, your internet experience on that browser could be negatively affected.

So, a non-complicated fix is to change to a different browser and see if the error persists.

For example, if you are using Chrome, switch to Edge if you are on Windows or Safari if you are using Mac.

If the website loads up in another browser, then you might need to update your other browser or reinstall it.

Solution 2: Temporarily Disable Your Antivirus

Antivirus programs are notorious for interfering with applications and stopping them from working properly.

If you are getting the “DNS server not responding” error, consider disabling your antivirus program to see if your internet connection works fine.

If you are able to access the internet after disabling the antivirus, then it is the reason you’re getting the error.

In this case, you may want to consider getting another antivirus program.

If you are on Windows 10, you can disable Windows Security (AKA Windows Defender) by following the steps below: Step 1: Press ALT + SHIFT + ESC on your keyboard to open the Task Manager

Step 2: Switch to the Startup tab

Step 3: Locate your Antivirus Program in the list, right-click on it and select "Disable".

Solution 3: Restart your Router or Modem

If your internet connection relies on a router or modem, restarting it could help you get rid of the “DNS server not responding” error.

This is because turning off and then turning on a router or modem clears the cache of IP addresses. This could fix the error in the long run.

To restart your router or modem, locate the power button and long press to turn it off, then turn it on again.

Solution 4: Flush your DNS Cache

If the “DNS server not responding” error is due to misconfiguration on your device, flushing your DNS is one of the most reliable ways to fix it. This is because the process would remove invalid IP configurations and outdated information in the DNS cache.

To flush your computer’s DNS on Windows, follow the steps highlighted below:

Step 1: Hit the WIN button on your keyboard and search for "cmd". Then select "Run as Administrator" on the right.

Step 2: Enter and execute the following commands one after the other:

• ipconfig /flushdns
• ipconfig /release
• ipconfig /renew

Step 3: Restart your computer

Solution 5: Manually Change your DNS Server

Using the default DNS server of your internet service provider could be the reason you are getting the “DNS server not responding” error.

You can change your DNS server to one of the free ones provided by the likes of Google and Cloudflare.

The steps below show you how to change your DNS server to Google's:

Step 1: Right-click on Start and select “Network Connections”:

Step 2: Scroll down and select “Change adapter options”:

Step 3: In the pop-up that appears, right-click on the network you are connected to and select “Properties”:

Step 4: In the next pop-up that appears, double-click on “Internet Protocol Version 4 (TCP/IPv4)”:

Step 5: In the following pop-up that appears, click the radio button that says “Use the following DNS server addresses”:

Step 6: Enter 8.8.8.8 for “Preferred DNS server” and 8.8.4.4 for “Alternate DNS server”:

This is the free DNS server provided by Google.

Step 7: Click “Ok”, and “Ok” again.

N.B.: If your computer is configured to use IPv6 instead of IPv4, then in step 4, you should choose “Internet Protocol Version 6 (TCP/IPv6)” instead of “Internet Protocol Version 4 (TCP/IPv4)”.

Solution 6: Update Your Network Adapter Driver

Updating your network adapter driver can fix a lot of technical issues – including the “DNS server not responding” error, since the new driver could include bug fixes.

To update your network adapter driver, you can do it with the steps below:

Step 1: Click on Start and select Device Manager.

Step 2: Expand Network Adapters.

Step 3: Right-click on the affected driver and select Update driver:

Step 4: Choose Search automatically for updated driver software:

Step 5: Allow your computer to search for a driver online and install it for you. When it is done installing, restart your computer.

Solution 7: Disable IPv6

If your current network is configured to use IPv4 and IPv6 is turned on on your computer, it could lead to negative interference which could make you get the “DNS server not responding” error.

To disable IPv6, the following steps can help you:

Step 1: Right-click on Start and select “Network Connections”:

Step 2: Scroll down and select “Change adapter options”:

Step 3: In the pop-up that appears, right-click on the network you are connected to and select “Properties”:

Step 4: In the next pop-up that appears, uncheck “Internet Protocol Version 6 (TCP/IPv6)”:

Step 6: Click “Ok”, and “Ok” again.

Final Thoughts

The “DNS server not responding” error can be frustrating and disturb your internet experience. But in this article you've learned how to fix it if the error is caused by misconfiguration of DNS from the user’s end.

I hope one of the solutions to the error explained in this article helps you fix the error.

This is because your operating system, or browser in the case of Google Chrome, cache IP addresses and DNS (Domain Name System) information of any website you visit. The DNS cache contains:

• the website address or hostname, technically called the resource data (rdata)
• the domain name of the website
• record type (IPv4 or IPv6)
• the validity of the cache or TTL (time to live)

When the TTL expires, the cache will be cleared, and the DNS is flushed for you automatically. But there are times when you don't want to wait hours or days for the TTL to expire, and want to flush your DNS manually.

In this article, I'll go over why you should flush your DNS, and how to do that in Windows 10 and Chrome.

So, Why Should You Flush (or Clear) Your DNS?

Flushing your DNS has several advantages, such as:

• hiding your search behavior from data collectors who might show you ads based on your search history
• requesting that an updated version of a website or web app is loaded. This can help resolve 404 issues if a website or web app was migrated to a new domain
• preventing DNS cache poisoning – a security situation in which black hat hackers gain maliciously gain access to your DNS cache and alter them so you get redirected to a website where sensitive information might be collected from you

How to Flush Your DNS on Windows

To flush your DNS records on Windows 10, follow the steps below:

Step 1: Click on Start or hit the Windows [logo] key on your keyboard

Step 2: Type "cmd", then select "Run as Administrator" on the right

Step 3: Type in "ipconfig /flushdns" and hit ENTER

You should get a response that the DNS cache has been flushed like the one below:

This means that your cache has been completely cleared, and fresh versions of any website you visit will be loaded.

How to Clear the DNS Cache on Google Chrome

Despite not being an operating system, Chrome keeps a DNS cache of its own to help personalize your browsing experience.

To flush Chrome's DNS, all you need to do is type chrome://net-internals/#dns in the address bar and hit ENTER.

Then click “Clear host cache”:

Conclusion

As you’ve learned in this article, flushing your DNS gives you a lot of advantages that can make your internet experience safer.

Even though the cache gets cleared after the TTL expires, you should flush your DNS as often as possible so you can get these advantages.

Thank you for reading!

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.

As the creator of Foo, a platform for website quality monitoring, I recently endeavored in a migration to Kubernetes and EKS (an AWS service).

Kubernetes provides a robust level of DNS support. Luckily for us, within a cluster, we can reference pods by host name as defined in a spec.

But what if we want to expose an app to the outside world as a website under a static domain? I thought this would be a common, well documented case, but boy was I wrong.

Assume a Service named foo in the Kubernetes namespace bar. A Pod running in namespace bar can look up this service by simply doing a DNS query for foo. A Pod running in namespace quux can look up this service by doing a DNS query for foo.bar ~ DNS for Services and Pods - Kubernetes

Yes, that's great ❤️ But this still leads to many unsolved mysteries. Let's take this one step at a time shall we?! This post will address the following items.

1. How to define services
2. How to expose multiple services under one NGINX server. No fancy schmancy "Ingress" needed ?
3. How to create an external DNS and connect to a domain you've acquired through any qualified registry like GoDaddy or Google Domains, for example. We'll use Route 53 and ExternalDNS to do the heavy lifting.

This post assumes a setup with EKS and eksctl as documented in "Getting started with eksctl", but many of the concepts and examples in this post could be applicable in a variety of configurations.

Step 1: Define Services

Connecting Applications with Services explains how to expose an NGINX application by defining a Deployment and Service. Let's go ahead and create 3 applications in the same manner: a user facing web app, an API and a reverse proxy NGINX server to expose the two apps under one host.

web-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        # etc, etc

web-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: web
  labels:
    app: web
spec:
  ports:
  - name: "3000"
    port: 3000
    targetPort: 3000
  selector:
    app: web

api-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        # etc, etc

api-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: api
  labels:
    app: api
spec:
  ports:
  - name: "3000"
    port: 3000
    targetPort: 3000
  selector:
    app: api

Fair enough, let's move on!

Step 2: Expose Multiple Services Under One NGINX Server

NGINX is a reverse proxy in that it proxies a request by sending it to a specified origin, fetches the response, and sends it back to the client.

Going back to the bit about service names being accessible to other pods in a cluster, we can setup an NGINX configuration to look something like this.

sites-enabled/www.example.com.conf

upstream api {
  server api:3000;
}

upstream web {
  server web:3000;
}

server {
  listen 80;

  server_name www.example.com;

  location / {
    proxy_pass http://web;
  }

  location /api {
    proxy_pass http://api;
  }
}

Note how we can reference origin hosts like web:3000 and api:300. Niiiice!

nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
  annotations:
    # this part will make more sense later
    external-dns.alpha.kubernetes.io/hostname: www.example.com
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - name: "80"
    port: 80
    targetPort: 80
  selector:
    app: nginx

...and, we're done! Right? In my experience, initially I thought so. The [LoadBalancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) provides an externally-accessible IP. You can confirm by running kubectl get svc and sure enough you'll find a host name listed in the EXTERNAL-IP column.

Assuming you've acquired a domain from a provider that offers an interface to manage DNS settings, you could simply add this URL as a CNAME and you're good, right? Well, kinda... but not so much.

Kubernetes Pods are considered to be relatively ephemeral (rather than durable) entities. Find more on this in "Pod Lifecycle - Kubernetes".

With that said, anytime a significant change has been made in the lifecycle of a service, in our case the NGINX app, we will have a different IP address which will in turn cause significant downtime in our app which defeats a main purpose of Kubernetes - to help establish a "highly available" application.

Okay, don't panic - we'll get through this ?

Step 3: Create an External DNS Service to Dynamically Point NGINX

In the previous step, with our LoadBalancer spec coupled with EKS we actually created an Elastic Load Balancer (for better or worse).

In this section we'll create a DNS service that points our load balancer via "ALIAS record". This ALIAS record is essentially dynamic in that a new one is created whenever our service changes. The stability is established in the name server records.

The tl;dr for the remaining portion is simply follow the documentation for using ExternalDNS with Route 53. Route 53 is "cloud Domain Name System (DNS) web service".

Below were things I had to do that weren't obvious from the documentation. Hold on to your horses, this gets a little scrappy.

• eksctl utils associate-iam-oidc-provider --cluster=your-cluster-name per eksctl service accounts documentation.
• When creating the IAM policy document per the ExternalDNS documentation, I actually had to do it via CLI vs online in my account. I kept getting this error: WebIdentityErr: failed to retrieve credentials\ncaused by: AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n\tstatus code: 403. When I created the policy via CLI the issue went away. Below is the full command you should be able to literally copy and execute if you have the AWS CLI installed.

aws iam create-policy \
  --policy-name AllowExternalDNSUpdates \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["route53:ChangeResourceRecordSets"],"Resource":["arn:aws:route53:::hostedzone/*"]},{"Effect":"Allow","Action":["route53:ListHostedZones","route53:ListResourceRecordSets"],"Resource":["*"]}]}'

• Use the policy ARN output above to create an IAM role bound to the ExternalDNS service account with a command that will look something like eksctl create iamserviceaccount --cluster=your-cluster-name --name=external-dns --namespace=default --attach-policy-arn=arn:aws:iam::123456789:policy/AllowExternalDNSUpdates.
• We should now have a new role from the above that we can see in the IAM console which will have a name of something like eksctl-foo-addon-iamserviceaccount-Role1-abcdefg. Click on the role from the list and at the top of the next screen make note of the "Role ARN" as something like arn:aws:iam::123456789:role/eksctl-foo-addon-iamserviceaccount-Role1-abcdefg.
• Follow these steps to create a "hosted zone" in Route 53.
• You can confirm things in the Route 53 console.
• If your domain provider allows you to manage DNS settings, add the 4 name server records from the output of the command you ran to create a "hosted zone".
• Deploy ExternalDNS by following the instructions. Afterwards, you can tail the logs with kubectl logs -f name-of-external-dns-pod. You should see a line like this at the end: time="2020-05-05T02:57:31Z" level=info msg="All records are already up to date"

Easy, right?! Okay, maybe not... but at least you didn't have to figure all of that out alone ? There could be some gaps above, but hopefully it helps guide you through your process.

Conclusion

Although this post may have some grey areas, if it helps you establish dynamic DNS resolution as part of a highly available application, you've got something really special ?

Please add comments if I can help clear up anything or correct my terminology!

If you're hosting a static website in an S3 bucket and it's your first time buying a domain name, this simple guide is for you.

Summary - What You Need

Amazon S3

• Have an S3 bucket with the same name as your domain name
• Upload your website's code
• Allow public access
• Add a policy to enable S3 GetObject
• Enable static website hosting

Domain Name provider

• In your domain name's DNS Zone settings, delete all A records
• In DNS Zone settings, add www to subdomain and the S3 endpoint in hostname for CNAME records

Let's go through these steps one by one.

Step 1: Create an S3 bucket

Create an S3 bucket to host your files for your website

First you need to create a bucket for your website. The name for your bucket must be the same as your domain name. Let's say we bought the domain name www.clarkngo.net. Then my S3 bucket's name should be www.clarkngo.net as well.

After configuration, my endpoint should look similar to this:

http://www.clarkngo.net.s3-website-us-west-2.amazonaws.com

Go to your AWS console and login. Choose S3.

1. Click Buckets
2. Click Create bucket

3. Add your domain name in the bucket name

4. You may choose any Region

Creating the S3 bucket and general configuration

Follow the checkboxes below and click Create Bucket.

Only tick the following:

• Block public access to bucket and objects granted through new access control lists (ACLs)
• Block public access to bucket and objects granted through any access control lists (ACLs)

Uploading files to the S3 Bucket

1. Click Overview and Upload.

2. Upload your website files in Select Files

3. For Set permissions, hit Next.

4. For Set properties, hit Next. (The default is Standard S3.)

5. For Review, hit Upload.

Editing the Bucket Policy

1. Click Permissions, then Bucket Policy.

2. Add the policy. (Note: For your website you'll change arn:aws::s3:::www.clarkngo.net/*)

{
    "Version": "2012-10-17",
    "Id": "Policy1548223592786",
    "Statement": [
        {
            "Sid": "Stmt1548223591553",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.clarkngo.net/*"
        }
    ]
}

3. Hit Save.

Static website hosting

1. Click Properties, then Static website hosting.

2. Choose Use this bucket to host a website.

3. For Index document, type index.html.

4. For Error document, type index.html.

5. Hit Save.

Step 2: Add the S3 Endpoint to your Domain

Editing your DNS Zone

1. Login to your domain provider.
2. In this example, choose Name Servers/DNS, then Modify DNS Zone (or the equivalent).

3. Remove all A records in your domain. Usually it will have a default IP address for a 404 Not Found page.

4. Add a CNAME to point to the S3 Bucket:

5. add www for the Subdomain.

6. add www.clarkngo.net.s3-website-us-west-2.amazonaws.com (the S3 Endpoint) to the Hostname.

And you're done! Note that it might take a while for your new settings take effect.

Connect with me in LinkedIn here.

At that point, I had only viewed my portfolio on localhost by viewing the files on my local computer. I didn’t know anything about how to host a website online.

Learning how to host my first website wasn’t easy but it was a great learning experience. If you're an aspiring web developer or just interested in launching your own static website, then I hope you will find this guide useful.

Who is this guide for?

This guide is aimed at complete beginners who want to host a static website (a site with fixed content). I will provide a how-to-guide for the following:

1. How to buy a domain.

2. How to configure your domain for an external hosting provider.

3. How to host your website with Amazon Web Services (AWS).

4. How to make your website secure (SSL certification) using Amazon Certification Manager.

There might be some terminology that’s new to you. Please go ahead and look up terms that are not familiar. I’ve put in useful links and explanations where I thought appropriate.

What is a domain name and DNS (Domain Name System)?

A domain name is your website address. For example thecodinghamster.com. But for a computer, a domain name is actually a series of numbers (an IP address). An IP address looks like this: 123.321.0.1

It’s not easy for us to remember a long string of numbers. So your computer refers to a DNS to translate a text based website address into an IP address which it can then understand. A DNS is like a directory.

I watched this great video which explains domain name, DNS and how this works in under five minutes. Please watch the first five minutes of the video if you're interested:

Where can you buy your domain name?

You can buy a domain name from a domain name registrar. Prices start from a few dollars. Your domain name is unique. Each domain name registrar offers different levels of services/support. But you can register your domain with any registrar.

What is a hosting provider?

“An Internet hosting service is a service that runs Internet servers, allowing organizations and individuals to serve content to the Internet. There are various levels of service and various kinds of services offered.”

When I was looking for a hosting provider for my website, I explored different options. The prices ranged from £2.00 — £5.00 per month with various storage options from 0.5GB to 10GB. The prices seemed reasonable but all I wanted to do was host a static website. It had a few images, HTML, CSS and JavaScript files. No dynamic content.

Why AWS?

After some further research, I found AWS. AWS offers a free tier option. Essentially, you get lots of free products. Some of them expire after 12 months and others are free in perpetuity. The only cost that you will incur for hosting a static website is the cost of setting up a hosted zone. This cost $0.50 per month. So I went with AWS and set up my account.

The great thing about AWS is the price and it’s a reliable hosting provider. But one thing to bear in mind is that you’re reliant on their documentation. As I started reading about what services AWS offered, it quickly became confusing! I used the official AWS guide provided for setting up static websites. But I found myself getting lost with clicking on a link to another link and so forth. I started researching other guides to make up for knowledge gaps.

I found this this excellent guide by Victoria Drake.

I followed Victoria Drake’s guide alongside the AWS one and managed to muddle through. But there were still a few things that were not explained which I hope to flesh out.

Before we proceed, here is your to do list:

• Do some research on domain registrars and buy your domain name.

• Sign up for a free account with AWS.

• Have both the documentation from AWS and Victoria Drake’s guide open. Use my guide to guide you through the documentation (hope that makes sense!).

Here we go!

AWS: Create a Hosted Zone on Route 53.

Route 53 is where all your DNS requests are handled.

The first thing you must set up is your hosted zone with Route 53. This is really easy if you bought your domain through AWS. A hosted zone is created automatically once you’ve purchase it. If you’ve done this then just skip to the next section (Set up your S3 Buckets).

However, if you were like me and bought your domain name via another registrar then please do the following.

This next part is how to create a Hosted Zone on Route 53 if you haven’t bought your domain name from AWS:

1. Go to Route 53 in your console and click on “Create Hosted Zone”. Fill in your domain address, comment is optional and choose a “Public Hosted Zone”. Click on “Create”.

2. Once your hosted zone is created, you need your NS (Name Servers) records:

3. Go to your domain name registrar and login. Depending on your registrar, you should find a section in your settings called "Nameservers" which you can edit. You need to copy across the AWS NS records and change the existing NS records in your domain settings.

Please note, don't copy the full stop/period at the end of the NS record. For example, is should be “ns-63.awsdns-07.com”, not “ns-63.awsdns-07.com.”

It will take up to 24 hours to propagate.

Set up your S3 Buckets

In the meantime you can set up your S3 Buckets. The S3 Bucket is the storage for your files such as your index.html.

You must configure two buckets for your website: 1) yourdomainname.com and 2) www.yourdomainname.com.

The first bucket is your main bucket where you will upload all your documents, such as your index.html. The second bucket redirects to the first bucket. To set up your S3 Buckets, please follow the AWS documentation on how to set up your S3 bucket ( 2: Create and Configure Buckets and Upload Data).

In addition to the documentation, there are a few things to note:

• In section 2.1 (part 2): click on the link How Do I Create an S3 Bucket? This is a step by step guide and explain all the settings you need to choose.

• In section 2.1 (part 3): you don’t have to upload your website files yet. You can add a test index.html in the meantime.

Take note of your endpoint. You can find this in your S3 bucket > “Properties” tab > “Static Web Hosting” box. It should look something like this: http://yourdomainname.com.s3-website.eu-west-2.amazonaws.com

Add the Alias/“A” records in Route 53

Finally go back to Route 53 and open your hosted zone to set up your Alias records. You can follow the documentation on “Step 3: Add Alias Records for example.com and www.example.com”. It is quite straightforward.

Once the NS settings have propagated, your site is live! You’ll be able to visit your site at the domain address e.g. yourdomainname.com

However, please note that it won’t be secure and you’ll see a http:// prefix in the address bar. I’ll get to that in the next section.

How to make your website secure and what is a SSL certificate?

It’s very important to make your website secure and to do this you’ll need to get an SSL certificate. SSL stands for Secure Sockets Layer and it uses encryption to securely transfer data between a user and site. Google will also give a rankings boost for websites with HTTPS.

If you secure the website with an SSL certificate, you’ll see https:// and a padlock symbol in your address bar.

There are different types of SSL certificates: Extended Validation Certificate and a Domain validated certificate. For a personal website or blog, only a domain validated certificate is required. You also won’t see the name of your company on the left of the bar like the example above. You only get this if you have an Extended Validation Certificate which is more for large companies/enterprises.

How much does it cost for an SSL certificate?

I’ve seen a range of ways of getting an SSL certificate. You can pay a premium for a service that will do this on your behalf or you can do it for free with Let’s Encrypt. Let’s Encrypt is an official Certificate Authority (CA). But you have to renew your certificate every three months and the process is quite complicated.

I didn’t want to pay a premium or want the hassle of renewing every three months. Conveniently, AWS can issue SSL certificates for a very small fee. You pay $0.75 for each certificate issued and it lasts for one year.

If you choose not to go with AWS, make sure you do your research and choose a trusted CA!

How do you get an SSL certificate with AWS?

Log into your AWS console and navigate to the AWS Certificate Manager (ACM).

Make sure you change the region from the default (Ohio) to N. Virginia. This is not explicit in the guides and only the N. Virginia region can issue certificates. I learned the hard way and wasted a lot of time!

Then click on “Get Started” under “Provision Certificates”.

Follow the documentation with AWS (“Requesting a public certificate using the console”) and use Victoria Drake’s guide (under “SSL certificate”).

In addition to the guides there are few things that weren’t fully explained:

• You’ll need to validate your domain ownership by email or directly with DNS. I would suggest to always verify ownership by DNS validation.

• Once you’ve requested your certificate you’ll get something like this (except the status will be pending). Click on the “Export DNS Configuration file”:

It’s an Excel spreadsheet which will contain something like this:

• You’ll need to add these records to your DNS settings with your registrar. Log in and go to DNS settings. The interface varies with different registrars but you’re looking for your Host records under your DNS settings.

• Click on “Add Record” > record type is CNAME:

You need to add two records: 1) Hostname should be “@” and Target Name should be the Record value from the DNS configuration file.

2. Hostname should be * (asterisk) and Target Name should be the Record value from the DNS configuration file.

If you want more information about the CNAME and record types, I found this helpful article.

It's quite long, but I've pulled out the useful part:

“Note: Hostname refers to the prefix before the domain name. To create a Blank record, use an @ in the Hostname field. This represents an empty prefix (so the name exactly matches the domain name; for example divapirate.com). The @ hostname is also referred to as the the root of the domain. An * (asterisk) in the Hostname is a wildcard, and represents any prefix. For example, creating a record for *.divapirate.com will point .divapirate.com at the IP address provided.”

You just need to wait for the verification. For me, this took about an hour.

How do you add your SSL certificate?

With AWS you can add SSL certificate to your website through setting up CloudFront. CloudFront is great for speeding up your website. I used the AWS documentation and Victoria Drake’s guide (look out for her useful tips).

Please note, when you create your CloudFront distribution, there’s a drop down menu to add your SSL certificate. If you have been issued with an SSL certificate already, it will be pre-populated in the drop down menu.

Your state in your CloudFront dashboard should changed to “Enabled”. This isn’t instant and takes a little time.

Almost there…

Finally, you need to get your Domain Name from the CloudFront distribution. It should be something like this dsfdser83543.cloudfront.net.

Go back to Route 53 > hosted zone > change both Alias records (Alias Target) to the CloudFront Domain Name.

Voila! You have hosted your first secure static website with AWS.

Hope you found this useful. If you have any questions or just want to say hello, find me on Twitter @PhoebeVF

A big thank you to Victoria Drake for her guide. For a more advanced tutorial on this topic, please check out Victoria's article: "Hosting your static site with AWS S3, Route 53, and CloudFront".

Illustrations courtesy of https://undraw.co

In this article, I want my readers to get a picture of a very basic concept of the web world. Previously, I've written articles on the fancy stuff of today’s market, i.e. Angular journey, basics of react, etc. But, today, I want my readers to get into the journey which they encounter at first when they hit any URL.

As the topic is self explanatory - when we hit any URL then what happens? - let’s start!

Before discussing what happens after hitting the URL, we must go through what a URL actually is, and what different parts of the URL mean - right? Without wasting any time, let’s understand more about URLs.

URL – Uniform Resource Locator

If you look into its full form, then it is self explanatory: it has the location of the resources which we want to access. It is an address of the place where we want to go to interact with or find information.

Let's look into your daily life. If you want to visit your friend’s house for some work or to get information, you need their address. The same thing goes here in this big web world: we have to give an address of the website which we want to access. The web site is like the house and the URL is the address.

Anatomy of a URL

Now, we know what a URL is but we still don’t know about the parts of a URL. Let’s go!

Let’s take an example:

https://www.example.com/page1

Here, the first part is ‘https’. This basically tells the browser which protocol it should use. It can be http, https, ftp, etc. A protocol is a set of rules that browser use for communication over the network. 'https' is basically a secure version, i.e. information is exchanged in a secure way.

The second part www.example.com is a domain name. You can relate it to your friend’s house. It is an address of website. We use it to reach to the server (trained computer) that is responsible for serving the information for that website. Wait! You might think, a seconds before I mentioned URL is the address whereas I also mentioned domain name is also address. You may have been confused. Don’t be confused!

Difference between URL and Domain Name

The major difference between both is that the URL is a complete address. URL tells about the method through which information should exchange, the path after reaching that website. Whereas the domain name is part of a URL.

Let’s take our previous example to better understand. You can say that your friend’s house address is a domain name, whereas the URL not only tells the friend’s house address (domain name) but also how you are going to communicate like talking in a separate room (secure) or in front of everyone (info can get leak). It also tells the path, i.e. at which part of the house you will go after entering into the house. Hence, the domain name is part of the URL. A domain name with more information is a URL.

I hope now you are clear with the URL. Let’s get into the next part.

Domain Name

In the previous part, I explained about domain names, but not in depth. I want you to go into it more. As I told you, the Domain name is the address of the website. It gives a unique identity to your website in such a huge web world. No two domain names can be the same BUT - Yes! There is ‘but’. This is not the only definition of a domain name. There is another story behind it. Let’s get into that story.

As we know, when we hit any URL or you can say domain name, then that website gets opened with its content. A server (a trained computer) serves it. We also know that every computer has an IP address which is used for communication over the internet. It is an address as its self explaining ‘IP address’. When we hit any URL, then we are actually hitting the IP address of the computer which is responsible for serving the website content (hosting).

But, now, you might think what the hell...is everything an address? Why does this domain name exist if the IP address is there? Why can’t we use IP address to get content of the website?

Yes! You can use IP addresses to get content of the website but really!.. Would you be able to remember each website’s associated IP address? Obviously not! It’s hard to remember the IP address of every website. That’s why domain names came into the market.

You can relate it to your contact list. You can’t remember every person’s number, but you can remember their name. Same concept applies here as well. You can’t remember those scary IP addresses, but you can easily remember domain names.

This huge amount of data is maintained in a database where the domain name with its IP address is stored. A system that stores domain names with its corresponding IP address is known as DNS (Domain name system) (I believe you must have heard about it).

I think I have discussed enough basics. Now, get a deep dive into the process of when we hit any URL.

DNS lookup to find IP address

After hitting the URL, the first thing that needs to happen is to resolve IP address associated with the domain name. DNS helps in resolving this. DNS is like a phone book and helps us to provide the IP address that is associated with the domain name just like our phone book gives a mobile number which is associated with the person’s name.

This is the overview, but there are four layers through which this domain name query goes through. Let’s understand the steps:

1. After hitting the URL, the browser cache is checked. As browser maintains its DNS records for some amount of time for the websites you have visited earlier. Hence, firstly, DNS query runs here to find the IP address associated with the domain name.

2. The second place where DNS query runs in OS cache followed by router cache.

3. If in the above steps, a DNS query does not get resolved, then it takes the help of resolver server. Resolver server is nothing but your ISP (Internet service provider). The query is sent to ISP where DNS query runs in ISP cache.

   4. If in 3rd steps as well, no results found, then request sends to top or root server of the DNS hierarchy. There it never happens that it says no results found, but actually it tells, from where this information you can get. If you are searching IP address of the top level domain (.com,.net,.Gov,. org). It tells the resolver server to search TLD server (Top level domain).

4. Now, resolver asks TLD server to give IP address of our domain name. TLD stores address information of domain name. It tells the resolver to ask it to Authoritative Name server.

5. The authoritative name server is responsible for knowing everything about the domain name. Finally, resolver (ISP) gets the IP address associated with the domain name and sends it back to the browser.

After getting an IP address, resolver stores it in its cache so that next time, if the same query comes then it does not have to go to all these steps again. It can now provide IP address from their cache.

This is all about the steps that is followed to resolve IP address that is associated with the domain name. Have a look below to better understand:

TCP connection initiates with the server by Browser

Once the IP address of the computer (where your website information is there) is found, it initiates connection with it. To communicate over the network, internet protocol is followed. TCP/IP is most common protocol. A connection is built between two using a process called ‘TCP 3-way handshake’. Let’s understand the process in brief:

1. A client computer sends a SYN message means, whether second computer is open for new connection or not.

2. Then another computer, if open for new connection, it sends acknowledge message with SYN message as well.

3. After this, first computer receives its message and acknowledge by sending an ACK message.

To better understand, look below diagram.

Communication Starts (Request Response Process)

Finally, the connection is built between client and server. Now, they both can communicate with each other and share information. After successful connection, browser (client) sends a request to a server that I want this content. The server knows everything of what response it should send for every request. Hence, the server responds back. This response contains every information that you requested like web page, status-code, cache-control, etc. Now, the browser renders the content that has been requested.

That’s it! All the above process happens when we hit any URL. Although this lengthy process takes less than seconds to complete. This is the answer to your question ‘what happens when we hit any URL in a browser?’

Thanks for reading!

You all might have heard about or know about the Domain Name System (DNS) if you understand how the internet works or how computer networks work. If you aren’t familiar with DNS, I would recommend that you go and check out my previous blog post which is focused on computer networks here.

Hostnames alone cannot tell us where the particular machine/hardware that we are trying to communicate with is located in the world. Hence, all communication is done with IP addresses.

Domain Name Servers are the devices that map the hostname to the IP addresses of the machine/hardware on which your services are running.

In this post, I will be explaining in detail the types of DNS queries, types of DNS servers, and types of DNS records.

DNS Resolver

DNS Resolvers are the computers used by Internet Service Providers (ISPs) to perform lookups in their database for the particular hostname requested by the user. They then redirect that user to the mapped IP address. They play a vital role in DNS Resolution.

DNS Resolvers also cache the data. So for example, my websiteexample.com is currently hosted on a machine with the IP address 35.195.226.230 . So, the caches of the DNS Resolvers all over the world have mapped the following:

example.com -&gt; 35.195.226.230

Consider, in the future, if I want to host my website on any another server across the world with an IP of, say, 35.192.247.235. The DNS caches of all the DNS Resolvers across the world will still have the old IP address for some time. This may lead to unavailability through conventional means of the website until the DNS propagation happens completely.

The record in the DNS Resolver cache remains there for some time, which is called time to live (TTL for short).

This is the time a record is cached in the DNS Resolver. This can be set in the registrar’s dashboard from where you have purchased the domain.

Note: from now on, I will refer to the DNS Resolver as Resolver only in this blog post.

Types of DNS servers

Root DNS server

The Root DNS servers are the ones who have the addresses of all the TLD domain servers. A request first encounters the Root DNS servers while on its journey to obtain the IP address from the hostname.

There are 13 root domain name servers across the world as of 2016. This does not mean that there are only 13 machines handling the load of the requests coming from all over the world — there are multiple servers at ground level handling the load.

Different organizations manage the Root DNS servers:

Credits: https://iana.org

TLD domain server

These are the ones classified according to the Top-Level Domain. They are usually the next ones which the iterative query hits after the Root DNS server. They store the TLD specific records for the hostname.

Let’s say if we are requesting an IP address of medium.com , then the TLD domain servers for “.com” TLD are queried. The TLD domain servers return the address of the Authoritative DNS servers to the Resolver.

Fig. TLD Name servers pointing to the Authoritative Name servers

Now, the question arises: how does the TLD name server know the address of the Authoritative Name server? The answer is simple: when you purchase any domain with the registrars like Godaddy or Namecheap, the registrars also communicate the domains to the TLD name server. So it is able to contact the Authoritative Name servers.

Nowadays, some of the registrars provide the ability to use third party Authoritative Name servers. As shown in the above figure, you can set up the Authoritative Nameservers in the registrar’s dashboard.

Authoritative DNS server

These are queried iteratively in the end by the Resolver. They store the actual records for type A, NS, CNAME, TXT, etc.

Thus, they return the IP address of the hostname if available. If it is not available even in the Authoritative DNS server, then they throw an error with the particular message and the process of searching IP addresses across the Nameserver ends.

Types of DNS queries

There are three types of DNS queries:

Recursive: Recursive queries are made by users to the Resolver. It is actually the first query made while doing any DNS lookup.

The Resolvers can be your ISP or your network admin, but usually, it is the ISP in almost all cases.

Non-recursive: in non-recursive queries, the Resolver knows the answer and responds immediately without making any further queries to any other name servers. This happens because the local DNS server has the IP address stored in its local cache or it just queries the Authoritative name servers directly. They happen to definitely hold the record and this eventually avoids the recursive queries.

Iterative: Iterative queries happen when the Resolver cannot return the results since they may not have cached it. So, it makes a request to the Root DNS server. And the Root DNS servers know where to find the particular TLD domain server.

So, for example, if we are trying to obtain the IP address for say medium.com , then the Root domain server will have the address of the .com TLD server stored in it and will then send it back to the Resolver. The Resolver then asks the TLD server for the IP address. The TLD domain server may not know it, but it knows the address of the Authoritative DNS server for medium.com .

Okay, enough of the theory. Let’s understand it by a flow diagram:

Fig. DNS Resolution

Let’s break down the above diagram in steps:

1. The user makes a request to the Resolver with the hostname for which it wants the IP address. This is a recursive query.
2. The Resolver does a lookup in its cache to see if it is present in it.
3. If it is, it returns it back to the user.
4. If it does not have it cached, it makes an iterative request to the Root DNS servers that are present globally. As of 2016, there are 13 Root DNS servers named from A — M. Now, the Root DNS server looks up for the TLD of the requested domain. For example, if the hostname is medium.com , then the TLD becomes “.com” and the Root DNS server has the entry for “.com” domain servers and it returns the results back to the Resolver. The Resolver must have the addresses of all the Root domain name servers. If it doesn’t, the DNS lookup may fail in the first place.
5. Now, the Resolver again makes an iterative request to the TLD domain server asking for the IP address of the domain. The TLD domain server then returns back the address of the Authoritative server for the requested domain.
6. As of now, I believe, you may understand what are Authoritative DNS servers. They contain the actual records where the hostname is mapped to the IP address and hence the IP address is returned back to the Resolver (which in turn returns it back to the user).
7. If no matching record is found in the Authoritative Name servers, then an error with a message saying “DNS_PROBE_FINISHED_NXDOMAIN” is thrown indicating there is no record for the requested hostname.
8. In all the Nameservers the request passes through, the results for the requested hostname are cached so that when any other user requests the same domain, the record will already be present in the DNS cache.
9. All in all, it takes at the max four queries to perform the DNS lookup. But, it hardly takes a few milliseconds to perform the lookup.

The concept of DNS Propagation

Consider, you have your website hosted with some provider like Digital Ocean on any machine with IP “x”, and you want to shift the website hosting to any other machine with different IP address say “y”. You will have to change the IP address in the Authoritative records so that traffic navigates to the new IP address.

Even if you update the records in your registrar’s/ name server’s dashboard, it takes some time to reflect in all the Resolvers’ caches in the world. DNS propagation can take 24–72 hours, but usually it happens sooner than that since most ISPs keep the TTL low.

And that’s it!

Thanks for reading the article. If you have any questions, please feel free to ask them in the comments below and share this post with whomever you want.

See you in the next one. Have a great time. Thank you.

You can check out my other article on Computer Networks which explains them in detail:

What computer networks are and how to actually understand them
_Whether you are new to the world of development, or have been building things for a long time — or even if you’re a…_medium.freecodecamp.org

If you like my work, you can buy me a coffee at:

Buy Sumedh Nimkarde a Coffee - BuyMeACoffee.com
_Hello, I am Sumedh and my work is to build, break and rebuild things._buymeacoffee.com

Feel free to reach out to me on Twitter.

How does the DNS work, and why is it important?

Overview

Throughout this series, we will be tackling the basics such as:

• How does DNS work? [You are here!]
• Network Stack, OSI Model
• HTTP Methods and Formats
• Client Identification
• Basic/Digest Authentication
• HTTPS working with SSL/TLS

What is HTTP?

HyperText Transfer Protocol (HTTP) is a protocol devised by Sir Tim Berners Lee in 1989. It forms the basis for how web pages communicate from the web server to the client’s browser.

_Sir Tim Berners Lee, the Father of World Wide Web. Photo courtesy of [CNET](https://www.cnet.com/pictures/images-berners-lee-and-the-dawn-of-the-web/" rel="noopener" target="blank" title=")

DNS Servers

Is the connection to the webpage established immediately after typing in the Domain Name, such as medium.com? Definitely not!

Machines, unlike us, recognize the location of webpages by IP Addresses. These string of numbers, such as 104.16.121.127, are more machine friendly especially since there are millions of domain names on the Web.

The Domain Name System (DNS) plays a crucial role in the whole HTTP request process, as it allows us to call a webpage by typing a simple domain name, www.medium.com instead of 104.16.121.127 every time you want to access the site.

Without DNS, your brain would be filled with numbers just trying to remember the IP Addresses for every single website you use!

Flow of DNS Resolution, maintained by a distributed database system

Now that we know that an IP Address is requested every time we type in the domain name, let’s find out where this request searches for the correct IP Address.

Local Cache

A cache is a block of memory for temporary storage of data that has a high probability of being used again. The first thing that happens is the DNS Resolver (residing in your computer) will check the browser’s cache, followed by the computer’s DNS cache. If you accessed the website recently, it would have the IP address cached in the system.

In that case, the browser can immediately call the IP Address to retrieve the webpage!

One thing to note here is that every cache has an expiry date, called the “Time to Live” setting. This setting determines how long the cache may be stored when the website is accessed. We will address how that works later on.

DNS Recursor

If the IP Address can’t be found in the local cache, it will then request from the DNS Recursor. The DNS Recursor is often the DNS Server of your Internet Service Provider (ISP).

These Internal DNS Servers have caches from websites that their clients have visited recently. Again, if the IP Address can’t be found here, it will be passed on to the next Domain Server.

Root-Level Domain Server

The Root-Level Domain Server (RLDS), or sometimes called the ‘ . ’ Name Server, is simply a gatekeeper for requests. It reads the request and locates the appropriate domain server to redirect to.

As such, it plays an important role in redirection to the next layer of Domain Servers. They are dispersed all around the world to prevent malicious attacks from bringing down the World Wide Web by targeting the RLDS.

Top-Level Domain Server

The Top-Level Domain Server (TLDS) is the name server for domains that end with their specific domain suffixes such as .com, .org or .io. After being passed down by RLDS, this layer works in the same way as the second gatekeeper. It takes the requests and runs through its DNS Server to redirect the request to the last and final stop, the Second-Level Domain Server.

The number of domain names are increasing exponentially. It is impossible for the RLDS to be able to store or redirect such a sheer amount of IP Addresses. As such, it is redirected to the TLDS to diversify the processing power and memory required.

Second-Level Domain Server

This layer is where all the information is stored about the domain is accessible. This DNS Server is usually owned by the institute that is responsible for hosting your website.

As such, a request for the record of the domain is sent to this DNS Server. It returns the IP Address, along with other important information such as the server it is on, and the alias it has.

Success!

The browser now receives the IP Address. It uses it to establish a connection with the host server using TCP/IP and retrieve the webpage via HTTP. We will discuss this in Part 2.

“Time to Live” Setting

DNS Records have a Time to Live (TTL) Setting. This determines the amount of time that any of the domain servers can cache the record.

Caching is important. It reduces the loading time for the page, since the DNS information will have to be reacquired every time the domain name is requested. Hence, a high TTL would allow the DNS records to stay alive for a longer period of time. This allow webpages to load faster.

Why don’t all DNS Records have a high TTL then?

By having a high TTL, it would mean that visitors would not see changes to the DNS immediately. Visitors only see the change after the DNS Record has expired.

For example, if we were to change the host for this webpage, and have a high TTL, the changes would not appear on the visitors browser immediately. This might result in broken links and users not being able to access the webpage.

Hostname — IP Address Relationship

So a single domain name is attached to one IP Address?

The answer is yes… and no. It can be, but doesn’t have to be a one-to-one relationship.

Single Hostname, Multiple IP Addresses

A single hostname such as www.google.com can correspond to multiple IP Addresses, to balance the load on the server since there is a significant amount of users calling on the same webpage at any one given point in time.

DNS Servers use a “Round Robin” method, such that all IP Addresses are equally utilized.

Multiple Hostname, Single IP Address

The purpose for this might be for referral links. For example, searching amazon.com/products/pc will show the product screen for PCs. Although amazon.com/products/pc?user=cherdon will also show the same webpage, any purchase would tell Amazon that I was the referrer, allowing me to gain commission from it.

Companies often buy multiple domains that link to the same webpage as well. For example, google.com and google.net would link you to the same search engine webpage.

Conclusion

The DNS Server is very important as it stores a database for machine-friendly IP Addresses under user-friendly Domain Names. Now that we have learnt how DNS Servers work together in a distributed database, let us explore how the connection with the host server is established with the IP Address in Part 2!

Hi! I’m Cher Don, currently pursuing a Major in Data Science. I’m the CTO of Paralegal Bot, and you can find my website below. Thanks for reading!

Piqued;
_Quality Content We offer the best content for difficult to grasp concepts. We've been there, and felt the same you do…_www.piqued.co

This post will use the above question to explore DNS, dig, A records, CNAME records, and ALIAS/ANAME records from a beginner’s perspective. So let’s get started.

First, some definitions

• Domain Name System (DNS): the overall system for converting a human memorable domain name (example.com) to an IP address (93.184.216.34). The IP address is of a server, commonly a web server, where the files needed to display a webpage are stored.
• DNS Server (also known as a name server or nameserver): Uses DNS software to store information about domain addresses. There are several levels — those belonging to each ISP, Root (13 total worldwide), Top Level Domain (TLD, e.g. ‘.com’), and Domain level DNS Servers.
• Domain name: the domain (example) combined with the TLD (.com). The term ‘domain’ is often used synonymously with the domain name, though they are different. When you buy a ‘domain’ from a a registrar or reseller, you buy the rights to a specific domain name (example.com), and any subdomains you want to create (my-site.example.com, mail.example.com, etc).

High level query flow

The high-level flow of what happens when you type “example.com” into your browser can be simplified to remove the hops to the ISP, Root, and TLD DNS Servers as below:

_Simplified DNS request flow, more can be seen in a [more detailed flow](http://www.uxworld.com/?p=384" rel="noopener" target="blank" title=")

A domain typically has two or more name servers, containing records relating to the domain name (example.com).

Many types of records can be stored, most of which can have multiple entries per type:

• A: Address records that map the domain name to an IP address
• CNAME: Canonical Name Record. Used to alias one domain name (or subdomain name) to another. We’ll look at this in more detail later.
• MX: Mail eXchange records that tell email delivery agents where they should deliver your email
• TXT: flexible Text records, for storing strings for a variety of uses
• SOA: singular Start of Authority record kept at the top level of the domain. Contains specific required information about the domain, for example its primary name server
• NS: The name servers associated with the domain

When your device sends a query that reaches a name server, the server looks in the domain’s record node for an A record, and the associated stored IP address (example.com: 93.184.216.34). This is then returned to the device, to be used to send a request to the correct web server to retrieve the requested webpage or resource.

Using ‘dig’

dig (domain information groper) is a command-line tool for querying DNS servers. This command is generally used for troubleshooting, or as now to understand more about the setup of a system.

$ dig example.com results in a long response printed to the terminal, the default output detailed here, of which we are interested in the ANSWER SECTION.

;; ANSWER SECTION:
example.com.       72703      IN     A       93.184.216.34

And there we go, we can see that example.com returns an A record of 93.184.216.34. Sometimes domains will have more than one A record, if more than one web server can provide the information needed.

There’s more! If we try out some other examples, we can soon see that another common record appears: CNAME.

$ dig www.skyscanner.net:

;; ANSWER SECTION:
www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net.
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.

e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

Using the +short flag allows us to clearly see the path formed:

$ dig [www.skyscanner.net](http://www.skyscanner.net) +short

www.skyscanner.net.edgekey.net.
e11316.a.akamaiedge.net.
23.217.6.192

CNAME

A CNAME record allows a domain name to be used as an alias for another canonical (true) domain.

When the DNS server returns a CNAME record, it will not return that to the client. Rather it will again look up the returned domain name, and in turn return the A record’s IP address. This chain can continue many CNAME levels deep, but then suffers minor performance hits from multiple lookups before caching takes place.

A simple example of this could be if you have a server where you keep all your photos. You may normally access it through photos.example.com. However, you might also want it to allow access via photographs.example.com. One way to make this possible is to add a CNAME record that points photographs to photos. This means that when someone visits photographs.example.com they would be given the same content as photos.example.com.

Using the query $ dig photographs.example.com we would see:

photographs.example.com    IN   CNAME photos.example.com
photos.example.com         IN   A     xx.xxx.x.xxx

It’s important to note that the CNAME is that piece to the right hand side. The left hand side is the alias name, or label.

Another common use is for the www subdomain. Having purchased example.com you likely also want users who type in www.example.com to see the same content.

It is worth noting here that example.com can be called the apex, root, or naked domain name.

One option would be to set up another A record, pointing to the same IP address as for example.com. This is completely valid, and is what the real example.com does, but it does not scale well. What happens if you need to update the IP address that example.com points to? You would also need to update it for the www subdomain, and any others you may use.

If a CNAME record was used to alias www.example.com to point to example.com then only the root domain would have to be updated, as all other nodes point to it.

CNAME limitations

At the time when the DNS standards were written, some rules were set out to govern their use. RFC 1912 and RFC 2181 set out that:

• SOA and NS records are mandatory to be present at the root domain
• CNAME records can only exist as single records and can not be combined with any other resource record ( DNSSEC SIG, NXT, and KEY RR records excepted)

This excludes a CNAME being used on the root domain, as the two rules would contradict each other.

What’s important here is that this is a contractual limitation, not a technical one. It is possible to use a CNAME at the root, but it can result in unexpected errors, as it is breaking the expected contract of behavior.

An example of this is told by Cloudflare, describing problems they encountered with Microsoft Exchange mail servers after having used a CNAME on their root domain:

Domains generally designate the servers that handle their email through what’s known as a MX Record. The problem was that Exchange servers … could pick up the CNAME at the root record and then not properly respect the CNAME set at the MX record. You can’t really blame Exchange. They were operating under the assumptions laid out by the DNS specification.

Here you see the downside that can appear in several server softwares or libraries. Because a standard is in place for a CNAME to be the only record at a node, no other records are looked for. All other records will be silently ignored, without warning or error messages. Even if an MX record was set to receive email, the MX will be ignored as if it doesn’t exist because the CNAME is evaluated first. The same is true if there were an A record: the CNAME would take precedence and the A record would not be read.

The modern internet

So why is this a problem? Why would you ever want to use a CNAME for your root domain anyway? Surely that is the end of the path when looking for the IP address of the web server hosting your content?

In the modern internet landscape, that is no longer the case. The world is very different from when the DNS standards were written.

You may choose to use a Platform as a Service (PaaS) provider like Heroku and store content on their web servers. You control the content, but not the infrastructure, and the PaaS provider does the heavy lifting of the network maintenance. They typically provide you with a URL (my-app.herokuapp.com) that is a subdomain of their root domain, and you can view the IP addresses for the web server(s) your content is on. But these are entirely under the PaaS provider’s control, and will change without warning.

The scale and frequency of backend changes made by the PaaS provider can make it hard to maintain your root domain A record pointing at a single IP address. Ideally you would wish to do this:

example.com      IN   CNAME    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.example.com      IN   CNAME    my-app.herokuapp.com.
www.example.com  IN   CNAME    my-app.herokuapp.com.

to allow Heroku (or your chosen host provider) to manage updating the A record that the CNAME points to without any changes made on your side. However, as we now know, this breaks the DNS specification, so is a very bad idea.

It is possible to simply implement a 301/302 redirect from example.com to www.example.com. However, that instruction takes place either on the web server (so still having the problem of needing to use a fixed A record in DNS to point to that web server), or a custom DNS provider redirect (that suffers complications with HTTPS).

This also has the side effect of changing the domain that you see in the URL bar, which you may not want. This method is intended for when your website has permanently moved, or when you’re trying to preserve SEO rankings, rather than solving our problem of pointing to a complex changing backend in a scaleable way.

The solution

Several DNS providers have now developed custom solutions to work around this problem, including:

• ALIAS at DNSimple
• ANAME at DNS Made Easy
• ANAME at easyDNS
• CNAME (virtual) at CloudFlare

These are all virtual record types that provide CNAME like behaviour, with none of the downsides. The exact implementation can differ, but at a high level when the DNS server sees one of these virtual record types, it acts as a DNS resolver. It follows the chain created by the alias until it resolves at an A record (or records) and returns these A records to the DNS server. This ‘flattens’ the CNAME chain into the A record(s) returned, and is indistinguishable to the sent query. The query sees only a pure A record, which doesn’t break the DNS specification, and doesn’t have any of the disadvantages of a CNAME.

These virtual records can sit alongside other records at the root without any fear of unintended behaviours. Depending on the provider’s method of DNS resolution when following the CNAME chain, they may also have performance benefits from caching previous lookups.

For a DNSimple setup, we would then configure as below. This solution has all the advantages of domain name aliasing, and none of the risks of using it at root level.

example.com      IN   ALIAS    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.

Thanks for reading! ?

As always, open to any corrections or additional points.

Resources

• What is a DNS Server
• Set Up a DNS Name Server
• DNSimple support pages and ALIAS blog
• Cloudflare support and CNAME blog
• [dig](https://www.madboa.com/geek/dig/) HowTo
• Several great Stack Overflow or StackExchange posts
• Well written Wikipedia entries
• Netlify blog ‘To www or not www’