In our day-to-day lives, we take a lot of things for granted. Our body, our friends, water, the food we eat, clothes we wear, IP address of our host, FQDN of our favorite websites, etc. In our ignorance, we forget to consider how our lives would be without them. Let’s discuss the leisure of friends, food, etc sometime later. For now, we’ll limit our thoughts to how DHCP and DNS are managed in AWS, both of which are the backbone to connections among hosts and servers over a network.
Dynamic Host Configuration Protocol (DHCP)
DHCP helps our hosts/systems obtain a unique identity over a network. We call this identity as IP address, but it’s not just an IP address. DHCP provides much more information than those like subnet mask, default gateway, DNS addresses, etc. Below is a high-level diagram of how a client interacts with the DHCP server. Something we call a DORA handshake.
In case of AWS VPC, this information is contained in DHCP option sets. Option sets only contain those DHCP options that are customizable. They do not contain IP addresses since IP addresses are provided by AWS.
Currently, there are five options that are supported in DHCP option sets:
- domain-name-server: We can specify IP addresses of up to four custom domain name servers (DNS) separated by a comma or we can leave it to AmazonProvidedDNS which is there by default.
- domain-name: When using AmazonProvidedDNS, depending upon our availability zone, the domain name could vary for public and private instances. When using custom DNS, we provide our own domain name and DNS servers which we will discuss in detail later.
- NTP-servers: We can specify IP addresses of up to four NTP servers.
- NetBIOS-name-servers: We can specify IP addresses of up to four NetBIOS name servers. Read more about NetBIOS here.
- NetBIOS-node-type: There are four NetBIOS node types: 1, 2, 4, and 8. AWS recommends specifying 2 (point-to-point node) mostly because broadcast (1) and multicast (4) nodes are not currently supported.
Domain Name Server (DNS)
Maps names over the internet to their corresponding IP addresses. DNS hostname of a host is unique and indisputable. It consists of a hostname and a domain name. A DNS server resolves DNS hostnames to their corresponding IP addresses. This is how we can reach our intended website by just typing its name in the browser while not needing to remember its IP address at all. How is it all works is quite interesting. Due to the limited scope of this post, I can’t get into details but here is a diagram for reference:
All requests, if not found privately, go to the root servers and from there follow the hierarchy above to reach the intended destination. Staring from ROOT, levels are known as root level, top level, second level, and subdomains respectively.
AWS provides us a default DNS which is called AmazonProvidedDNS. Requests from our AWS resources will got root level servers only if records are not found in here. We can also configure our VPC to use custom DNS servers through DHCP option sets as we saw above. There are two attributes we need to keep in mind if we need DNS support in our VPC: enableDNSHostnames and enableDnsSupport
enableDnsHostnames, if set true ensures that the instances in the VPC get public DNS hostnames but only if enableDnsSupport is also set to true. This is because the true value for enableDnsSupport ensures that the Amazon-provided DNS server in VPC resolves public DNS hostnames to IP addresses.
This means AWS DNS service for instances in a VPC works if both are true and does not work if either of them is false. Having said that, we should keep in mind custom DNS service will work even when both are false if we associate the respective DHCP option set with the VPC. Let’s dive deeper to understand this.
AmazonProvidedDNS (both enableDnsHostname and enableDnsSupport are true)
As mentioned earlier, when we create a VPC, it is provided a DHCP option set that has a default DNS called AmazonProvidedDNS and a default domain name as per naming convention. Any instance launched in this VPC will get a private DNS hostname.
Public instances will get a public DNS hostname if both the attributes mentioned earlier (enableDnsHostname and enableDnsSupport) are set to true. Private DNS hostname resolves to the private IP address of the instance and public DNS hostname resolves to the public IP address.
There is a reserved IP address provided to Amazon provided DNS in our VPC CIDR block. It is the base of block plus two, i.e. if CIDR block is 10.0.0.0/16, DNS IP address is 10.0.0.2. Apart from this, queries to DNS can also hit 169.254.169.253 server which is an Amazon provided DNS server.
Custom DNS servers (either of enableDnsHostname and enableDnsSupport is false)
Using our own DNS servers is an option too. Amazon supports this, and it can be configured rather easily. All we have to do is create a new DHCP option set and fill the required options with specific details. In the Domain name servers option, we can specify comma separated IP addresses of our DNS servers, and in Domain name, we can specify respective domain names. Once the DHCP option set is created, we can associate it with VPC and we’re done! DNS servers can be of any vendor or our own.
Note: Both the attributes, enableDnsHostname and enableDnsSupport are true by default in default VPC of a region or VPC created through the wizard. In VPC’s created any other way, CLI, API, or manually through the console, enableDnsSupport is true by default. Other needs to be set true.
With this thought, I end the post. It should be enough to get oneself started and explore a little on their own. Please do explore, there are always new things we learn by doing. Kindly share your feedback and comments. Thank you for reading!
Blog Pundit: Sanjeev Pandey
Opstree is an End to End DevOps solution provider
Hi Adeel, can I check with you 1 thing. If I use configure VPC to use custom DNS (i.e. own’s company DNS). Does it mean the AmazonProvidedDNS cannot work? And if I were to create VPCE to AWS Services, it cannot be resolve unless we add host records into the custom DNS?
Thanks a lot , I was struggling to understand the concept but you made it very easy.
Thanks again.