Domain Name System (DNS)

Human beings use names to refer to hosts, such as connecting to a mail server or a web site. Computers use numbers to identify and to address hosts and other devices on the network. The numbers that the computers use may have varying representation styles per protocol. For example, MAC addresses in the link layer are represented as a colon-separated hexadecimal number and IP addresses in the network layer are represented as a dot-separated quad decimal number. In essence, these addresses are numbers and that is how they are transmitted on the wire within packets. Computers pass these numbers through their logical function for each layer to perform match and lookup when forwarding data.

DNS stands for the Domain Name System that enables computers find the destination IP address for a given name. Some known name examples are: www.uh.edu, cnn.com, mail.uh.edu, etc.

How does a computer find the destionation IP address for a given name?

DNS service responds to queries coming from hosts. It returns the record type that is requested in the query. The format of the query looks like query string + record type and the response includes the resource record if it exist in the DNS service. Name to IP address resolution takes place for the cases where a user has a name for an entity they want to reach. The host asks a nameserver for the IP address associated with that name. Nameserver responds with the IP address. Then in turn, host sends packets to the IP address.

How does the host know who (i.e., what nameserver) to ask?

Hosts are configured with a nameserver address either manually or via DHCP.

Example: Check the /etc/resolv.conf file in your linux OS hosts for the nameserver IP address. There will be a line in the file for the hosts illustrated in the figure:

nameserver 192.168.1.100

The example topology shows one DNS server keeping records of all names in the network.

The topology is composed of two hosts, host1.lan1.example.net and host0.lan1.example.net, one bridge, and a nameserver, ns.example.net. Each of the hosts and the nameserver are in the same IP subnet, 192.168.1.0/24. All names in the domain example.net are served by this nameserver in the network. From here on, we will refer to this representative small network to illustrate DNS queries and resource records that may be present in this network. Here are some of the typical resource records types:

A record: name to IP address

PTR record: IP address to name

NS record: name to a nameserver name (i.e., I, nameserver A, don’t know the IP address but nameserver B knows)

MX record: mail server name

TXT record: any text associated with the name

AAAA record: IPv6 address for a name

CNAME record: canonical name for a name

More types are listed on this page online.

A nameserver in a topology has records for each host.

Example: In the topology above, host1.lan1.example.net name has an A record with a value of its IP address as 192.168.1.67.

DNS Lookup Examples

The nameserver data tree is looked up to generate the DNS responses to the DNS queries. The data tree for the nameserver in the topology would like the figure below. The query names would be traced down from the root label, ., then top level domain of net. and then the name of the domain example.. The nameserver name for the domain is ns.example.net and hence the record type NS for that key in the data tree has that value. An NS record query to the nameserver for the domain example.net would result in the response as ns.example.net. The nameserver would in this particular case also return the IP address for that name since it exists in its records as an A record: ns.example.net also has an A record and here is its IP address, 192.168.1.100. The rest of the tree has the domain names for all hosts in the network along with their A records. In addition, the data tree includes PTR records that map IP addresses to names. The PTR records start from the same root label . and branch to arpa.in-addr. and then the IP address for the name. One PTR IP address key exists for a particular name value whereas many IP address values and other record types may exist for a name key in the data tree. There is no one-to-one correspondance between A and PTR records.

A lookup of the A record for the IP address of the host, host1.lan1.example.net would trace the name in the data tree to point to the A record and return the IP address value, 192.168.1.67. The lookup in the table is pointing to the key and the corresponding A record value in the figure.

Other record types may also be included such as mail and text for this network. For example, if a mail server is running in the domain, the record type is MX and the value of the record is the name mail.lan1.example.net which is listed inside the subdomain lan1.example.net. The data tree also has an A record for this mailserver, which is the IP address, 192.168.1.200 for the name mail.lan1.example.net. This record has also a TXT record to provide an email address for issues with the mail server, as contact a@example.net.

Other example lookup scenarios are illustrated as follows:

A canonical name for a name that is generally used for a service is what is looked up when a query is received at the DNS server. The lookup for an A record for www.example.net will trace the data tree and result in the record type CNAME with a value of the name host1.lan1.example.net. This value will be looked up in the decision tree to find the A record that the query was asking for, which is the IP address 192.168.1.67.

The IP address may be used to this time query for the name that it belongs to using a PTR record query. The IP address 192.168.1.15 is used to send a PTR record query to retrieve the name host0.lan1.example.net. The PTR records are traced in the data tree starting with the root branch arpa.in-addr. and continuing with the IP address.

As it is noted before, there is only one record for a given IP address’s PTR query. For example, the IP address 192.168.1.15 has a name host0.lan1.example.net and it also hosts the web service www.example.net. The PTR records are maintained and entered through a separate mechanism and administration than the A records and how domain names are assigned. Since IP addresses of actual hardware hosts may be owned and maintained by entities separate from the owners of the services that are actually running on the hosts, the PTR records are there to make sure there is a way to make a reverse lookup for maintenance and troubleshooting purposes but not in a reliable manner where one may require a match between an A record and its PTR record.

This small topology does not have any references to or a mechanism for looking up for names that are outside of the domain name example.net. A host in this topology would not attempt to send a query for the A record of www.google.com. But, if the host to send such a query to the nameserver here, the response would say NXDomain which indicates that the domain is not known at this server. The host does a tracing of the data tree from the root down and notices that the domain after the root label . is com. in this case. And, this com. is not in this domain. The nameserver in this domain is the authoritative server for the example.net domain. It would have to query the root domain for the com. and then consecutively, query the com. server for the google.com. domain services. The goal would be to find the servers that are the authoritative servers for those domain names.

DNS Subdomains

Here is a larger topology where there is an example.net domain and its associated nameserver. There are two subdomains, lan1.example.net and lan2.example.net. All hosts in the subdomains have records in the nameserver, ns.example.net that is connected to the router that connects these two subnets. There are two subnets where hosts are connected to: lan1 is 192.168.1.0/24 and lan2 is 10.10.75.0/24. The nameserver itself is in another subnet, 10.50.50.0/24. The router is providing the forwarding between these subnets.

The data tree in this nameserver is shown in the figure below. All hosts in this domain have records in this nameserver. For example, host1 tries to send a packet to host2. It would send a DNS query to the ns.example.net for the A record for the host2.lan2.example.net name. The nameserver will reply with that record, IP address, 10.10.75.42. The host will be able to then send this packet to host2.

The same subdomain structure in naming of the hosts could have also been implemented in the following fashion. Each subdomain gets its own nameserver: lan1’s nameserver is ns.lan1.example.net and lan2’s nameserver is ns.lan2.example.net. The nameserver that is connected to the router is serving the domain example.net. In this fashion, if host1 is sending a packet to host2, it would ask for the nameserver IP address for the ns.example.net to its nameserver, ns.lan1.example.net. The reply from ns.example.net would be the A record for the ns.lan2.example.net which is the IP address, 10.10.75.253 so that the host1 can query that nameserver for the IP address of the host2. Then, host1 sends an A record query to ns.lan2.example.net for the host2.lan2.example.net. The reply from ns.lan2.example.net is the IP address for host2, 10.10.75.42.

The corresponding data tree at ns.example.net is shown in the figure below. The nameserver includes an NS record for its name, an A record for itself along with A and NS records for the subdomain nameservers.

The data tree key for lan1 and lan2 nameservers are represented with a plain text string lan1.ns and lan2.ns inside the example.net. In this respect, the nameserver, ns.example.net is not the authoritative server for the subdomains, lan1 and lan2.