Skip to main content

How DHCP and DNS are managed in AWS VPC - Part 1

In our day-to-day life, we take a lot of things for granted: our body, food, friends, family, internet, domain name (URL) of facebook, IP address of instagram, etc. In our ignorance, we forget to consider how much their absence would affect us, the hardship and inconvenience we'd face, if, one day, any of these just vanishes. Let’s leave the leisure of friends, food, etc to be discussed sometime later. For now, we’ll limit our thoughts to how DHCP and DNS are managed in AWS. These are responsible for domain names and IP addresses. Combined, they are the backbone to connections among hosts and servers over a network.

Both of these services work a little differently in AWS than in a physical infrastructure. In a physical set-up, DHCP can either be managed by a router or by dedicated DHCP servers depending on the size of our infrastructure whereas in AWS, through option sets. Similarly, DNS can either be managed by Internet Service Provider (ISP) or by dedicated DNS servers, whereas AWS, apart from having reserved DNS servers (AmazonProvidedDNS), has a few other tricks up its sleeve as well. To understand this better, we'll go through both of them one by one.

Dynamic Host Configuration Protocol (DHCP)

Helps our hosts/systems obtain a unique identity over a network. We call this identity IP address but it’s not just IP address, DHCP provides much more information than that like subnet mask, default gateway, DNS server addresses. All of these together form network configuration information. DHCP is client-server based protocol which uses 4-way handshake to establish connection. Below is a visual representation:

Fig. 1: 4 - way handshake connection

In case of AWS VPC, this configuration information is contained in DHCP option sets. Option sets contain only those DHCP options that are customizable. They do not contain IP address since IP addresses are provided by default when an instance is launched. There are five options currently supported in DHCP option sets. When an instance is launched in a VPC and requests Dynamic Configuration, AWS DHCP server provides that configuration with the below details, i.e., entries of option set:
  1. domain-name-server: This implies which DNS server the host will query. We can specify IP addresses of up to four custom domain name servers (DNS) separated by comma or we can leave it to AmazonProvidedDNS which is there by default.
  2. domain-name: This specifies our domain name. Example:,, etc. When using AmazonProvidedDNS, depending upon our region, 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.
  3. ntp-servers: NTP servers synchornize clock across servers in our network. They are precise to upto tens of millisecond even on the internet and even more accurate on a local network. We can specify IP addresses of up to four NTP servers.
  4. netbios-name-servers: They are similar to DNS servers, in that, they both provide identification to hosts in a network. DNS provides host identification over the internet but NetBIOS identifies hosts that use a local network. They do not need internet and are always available to the hosts connected directly to them. No need to register name in hosts. They allow applications on different connected hosts to communicate with each other. We can specify IP addresses of up to four NetBIOS name servers.
  5. netbios-node-type: There are four NetBIOS node types using which a windows machine resolves NetBIOS names: 1, 2, 4, and 8. AWS recommends specifying 2 (point-to-point node) mostly because 1 (broadcast)  and 4 (multicast) nodes are not yet supported.

Fig. 2: DHCP option set

These option sets are immutable. So, if we need to make changes, add or remove an option, we must create new option sets. A VPC can have several option sets but only one can be associated to it at a time. If we replace an option of VPC, we do not need to restart our running instances. Changes will reflect automatically depending on lease time of the DHCP configuration to an instance. We could always connect to instance and explicitly renew the lease, if need be. When a VPC is deleted, DHCP options set associated with it is also deleted.

Domain name service (DNS)

Maps names over the internet to their corresponding IP addresses. DNS hostname of a host is unique and indisputable. It consists of a host name and a domain name. A DNS server resolves DNS hostnames to their corresponding IP addresses. They are 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. The image below gives a far better idea of how it works, it really is amazing:
Fig. 3: Working of DNS

AWS provides us a default DNS which is called AmazonProvidedDNS. 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: enableDNSHostname and enableDnsSupport-
enableDnsHostname, 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 true value of 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 custom 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 which 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 public DNS hostname if both the attributes mentioned earlier (enableDnsHostname and enableDnsSupport) are set to true. Private DNS hostname resolves to private IP address of the instance and public DNS hostname resolves to public IP address. 

Both the attributes, enableDnsHostname and enableDnsSupport are true by default in default VPC of a region or VPC created through wizard. In VPC's created any other way, CLI, API, or manually through console, enableDnsSupport is true by default. Other needs to be set true.
There is a reserved IP address provided to Amazon provided DNS in our VPC CIDR block. It is the base of CIDR block plus two, i.e. if CIDR block is, DNS IP address is Apart from this, queries to DNS can also hit server which is also an Amazon provided DNS server.

Fig. 4: This is a default DHCP option set. In options field, we can see that domain-name is provided by default and name-sever is AmazonProvidedDNS

Custom DNS servers (either of enableDnsHostname and enableDnsSupport is false)

We can use our own DNS servers as well. Amazon allows this, and it can be configured rather easily. All we have to do is create a new DHCP option set and fill required options with specific details. In 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 voila, it is done! DNS servers can be of any vendor or our own.

Fig. 5: This is a custom DHCP option set that I created. I have put my own domain name and IP address of DNS name servers.


Both DHCP and DNS are paramount to internet connectivity. If not for these services, we'd still be writing with pen and paper and using post offices. AWS leaves no stone unturned in making these services available and customizable. In the next blog, i.e., "How DHCP and DNS are managed in AWS VPC - Part 2" , I will show how we can host our own website on EC2 instances and make it accessible to the world using these AWS services.


Popular posts from this blog

jgit-flow maven plugin to Release Java Application

Introduction As a DevOps I need a smooth way to release the java application, so I compared two maven plugin that are used to release the java application and in the end I found that Jgit-flow plugin is far better than maven-release plugin on the basis of following points: Maven-release plugin creates .backup and files to your working directory which can be committed mistakenly, when they should not be. jgit-flow maven plugin doesn't create these files or any other file in your working directory.Maven-release plugin create two tags.Maven-release plugin does a build in the prepare goal and a build in the perform goal causing tests to run 2 times but jgit-flow maven plugin builds project once so tests run only once.If something goes wrong during the maven plugin execution, It become very tough to roll it back, on the other hand jgit-flow maven plugin makes all changes into the branch and if you want to roll back just delete that branch.jgit-flow maven plugin doesn…

EC2 Ssh Connection Refused

When ssh: connect to host ip_address port 22 Connection refused

Unable to access server???
Exactly when you see the error - “ssh: connect to host ip_address port 22: Connection refused” while connecting your AWS EC2 Instance. In order to find solution of the problem, you will go to AWS forum and other channels where you need to answers several questions first. But it's very difficult to find the actual problem. In order to get clues what the problem is, we should provide as many details as possible about what we have tried and the results we are getting. Because there are hundreds of reason why a server or service might not be accessible, also connectivity is one of the toughest issue to diagnose, especially when you are hosting something critical on your box. I've seen several topics on this problem, but none offers a solution to it.  I was not aware for what should I look at first. So I walk through from the very basics and investigated the following thing Use of verbose while ss…

VPC per envrionvment versus Single VPC for all environments

This blog talks about the two possible ways of hosting your infrastructure in Cloud, though it will be more close to hosting on AWS as it is a real life example but this problem can be applied to any cloud infrastructure set-up. I'm just sharing my thoughts and pros & cons of both approaches but I would love to hear from the people reading this blog about their take as well what do they think.

Before jumping right away into the real talk I would like to give a bit of background on how I come up with this blog, I was working with a client in managing his cloud infrastructure where we had 4 environments dev, QA, Pre Production and Production and each environment had close to 20 instances, apart from applications instances there were some admin instances as well such as Icinga for monitoring, logstash for consolidating logs, Graphite Server to view the logs, VPN server to manage access of people.

At this point we got into a discussion that whether the current infrastructure set-u…