How To Perform DNS Delegation

infrastructure networking technology

Use Case

While building infrastructure, especially in The Cloud, you often come across the need to manage a subdomain. Perhaps you have something like staging.example.com that will be wholly managed within Route53 (Amazon Web Services' DNS service). However, your company's DNS zone (example.com) is hosted in another place, say, Namecheap (a domain registrar) or Dyn (a DNS management service). What can you do?

The Answer

The answer is that you need to delegate your DNS subdomain to Route53. This sounds a lot more difficult than it actually is. DNS delegation involves taking a subdomain and pointing it to another set of DNS records. You need permissions to modify both a Route53 hosted zone and your DNS zone in the other DNS service.

Let's use a historical analogy to better understand this process.

A Bit of History

If you're old enough, the world's communication used to be ruled by phone books (yellow pages for businesses, and white pages for people 1). You look up someone's name and you get a phone number. DNS is the exact analogue for the Internet; your web browser looks up a website's name (www.microsoft.com) and DNS returns the IP address. Once a computer knows an IP address, it can communicate with the website. Delegating a DNS subdomain is, in phone book terms, akin to looking up someone's name in the white pages and being told that it exists in the yellow pages. So then you go to the yellow pages and look up the name there, and are told the phone number. So how does this work in DNS land?

The way a computer (or its Web browser) knows to look anything up is through the use of name servers. Name servers are the phone books of the Internet. The name servers your computer knows are very limited, so much that they often point computers to other name servers for help answering questions. Each "hop" through these name servers will take your computer closer to its answer for an IP address match a website's name.

The Solution

Say someone's computer wants to find out how to connect to staging.example.com. It first asks the name servers attached to your ISP, which then contain the records for .com. Then the next set of name servers are requested for answers to example.com. These name servers are owned by your DNS service, like Namecheap or Dyn and others. Then these name servers are asked for staging.example.com, to which they reply with another redirect to Route53. Once your computer hits Route53's name servers, it receives an answer back with the IP address of the website 2.

Thus, DNS delegation is simply redirecting requests for a subdomain to another set of name servers. When a Route53 hosted zone is created for staging.example.com, by default it will contain a minimum set of DNS records (SOA and NS). The NS record type stands for Name Server. There will be 3 to 4 entries there, to help distribute itself around the world and prevent DNS service failures. Remember each NS record entry for the next step. For the purposes of this article, let's assume you have 4 NS records available for this hosted zone.

Now go into your DNS management service (Namecheap, Dyn, etc) and create four new subdomain records for "staging". You will choose the DNS record type NS for each of them. The value for each of them will correspond to the value for each of the NS records in the Route53 hosted zone. Save or publish the new DNS records and, within 0-48 hours 3, your subdomain is now delegated to Route53.

If your DNS service offers a raw view of the DNS entries you saved, it will correspond to this:

staging.example.com.   NS    <ROUTE53 HOSTED ZONE NS RECORD 1>
staging.example.com.   NS    <ROUTE53 HOSTED ZONE NS RECORD 2>
staging.example.com.   NS    <ROUTE53 HOSTED ZONE NS RECORD 3>
staging.example.com.   NS    <ROUTE53 HOSTED ZONE NS RECORD 4>

Your work can be verified in two steps. First, type host -t NS staging.example.com in your terminal. The response will match the 4 NS records that you received from Route53. Second, type host -t SOA staging.example.com in your terminal. The response will match the SOA record in Route53 for the hosted zone.

Recap and TL;DR

To recap the process of performing DNS delegation of a subdomain:

  1. Create a Route53 hosted zone for the subdomain.
  2. Remember the NS records and how many there are
  3. Create new subdomain DNS records in your DNS server.
  4. Choose the NS DNS record type.
  5. Use the DNS values memorized in step 2 for each new DNS record.
  6. Save the records.
  7. Wait 0-48 hours. 3

Footnotes

  1. And blue pages for government phone numbers. But now I'm just showing off. ↩

  2. It is good to stop here and think about all the hops in this process. While it seems like a lot is going on here, and it is, this process takes milliseconds to occur. Once the answer is known, your computer will remember (cache) the answer to prevent it from having to hop around again (this brings up another host of problems, but that is out of scope for this article). ↩

  3. Yes, some things in life still take a long time. This is what is known as DNS propagation and while it usually takes about 15 minutes for your computer to notice the change, in reality it takes up to 48 hours for every name server around the world (!) to reflect all those changes. Until then, you may get a different answer for each request your computer or your customers make. Best advice here is to plan these events ahead of time. ↩ ↩2

« Previous: Basic Human Psychological Needs
Next: Determining Your Current EC2 Region in Go »