DNS
Last updated
Last updated
The purpose of the domain name system (DNS) is to map human-readable names - such as www.gatech.edu - to IP addresses - such as 130.207.160.173.
While the human-readable name is much easier for us to read and interpret, the IP address is needed to send traffic to the intended destination.
A client might want to lookup a domain name, like www.gatech.edu. A networked application's source code may invoke this lookup with the gethostbyname function.
The client typically has a stub resolver. This resolver takes the domain name and issues a query to a local DNS resolver. The local DNS resolver is typically configured automatically when a host is assigned an IP address, through a protocol called the Domain Host Configuration Protocol (DHCP) .
The client query is typically sent recursively. This means that the client doesn't want to receive intermediate referrals from DNS servers trying to resolve the query. The client only cares about the final answer.
The local resolver, on the other hand, will perform iterative queries.
Each fully qualified domain name is expected to end with a "dot" (.), indicating the root of the DNS hierarchy.
The IP addresses for the root servers - those that are authoritative for the root - may already be configured in the local DNS resolver.
In the case of www.gatech.edu, the local DNS resolver may issue a query for an A record to the root server - say, a.root-servers.net - which may respond with an NS (referral) record with a value of c.edu-servers.net.
Now the local resolver will issue the same A record query to the edu servers. This query may give another referral to the authoritative servers for the GATech domain space.
Finally, the local resolver will issue the same query to the authoritative server for the GATech hierarchy, at which point it may receive the actual IP address that corresponds to the domain name in question.
This process of referrals can be pretty slow. A typical DNS query may require round trips to multiple servers that are authoritative for different parts of the hierarchy.
We can reduce the number of round trips we must take to respond to any query by introducing a cache at the local resolver.
This cache would store the NS records for each level of the hierarchy as well as the A records.
Each of the records would be cached for a particular amount of time. Each reply from a DNS server has a time to live (TTL) attribute that indicates how long each requested record can be saved before they need to be looked up again.
Caching allows for quick responses from the local DNS resolver, especially for repeated mappings. For example, if multiple hosts are connected to the same resolver, and one of them requests a popular site - like facebook.com - the DNS server can then cache that record, which will speed up the (inevitable) lookup requests for all of the other hosts.
Some queries can reuse parts of the lookup. For example, it is unlikely that the authoritative name server for the root is going to change very often. That record might be cached for hours, days or even weeks.
The mapping for a local name - like www.gatech.edu - might change more frequently, so those TTLs might be smaller.
A records map names to IP addresses.
NS records, or name server records, map domain names to the authoritative name server for that domain. This can be helpful when a particular DNS server doesn't know the answer to a query, but can refer the caller to the authoritative server for that space of the domain system.
MX records show the mail server for a domain.
Occasionally, one name is just an alias for another. For example, www.gatech.edu has a slightly different "real" name. The CNAME record is basically just a pointer from an alias to another domain name that needs to be looked up.
The PTR record maps IPs address to domain names. This is sometimes referred to as a reverse lookup.
Finally, a AAAA record maps a domain name to an IPv6 address.
We can issue DNS queries and see responses with a command line utility called dig.
From the man pages:
dig (domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried.
Here is an example of a lookup for an A record for www.gatech.edu.
In the "QUESTION SECTION", you can see our query. We are looking for an A record for www.gatech.edu.
In the "ANSWER SECTION", you can see the response to our query. Our initial query response is a CNAME record, which maps www.gatech.edu to tlweb.gtm.gatech.edu. We then issue an A record query for tlweb.gtm.gatech.edu, the response to which is 130.207.160.173.
The numbers "60" and "30" for the CNAME and A record entries, respectively, indicate the TTL in seconds that the entry can be stored in the cache.
Here is an example of an A record query for nytimes.com.
The interesting thing to note here is that in the response to our A record query, we see four IP addresses. This is typically performed when a service wants to perform load balancing.
The client can use any one of these. It might prefer the first one, but if we issue the query again, the IP addresses may come back in a different order.
Here is an example of an NS record query for gatech.edu.
In the "QUESTION SECTION", we can see that we have an NS record query instead of an A record query. In the "ANSWER SECTION", we can see that we have received the names of three name servers, any of which can answer authoritatively for subdomains of gatech.edu
Here is an example of an MX record query for gatech.edu.
In the "QUESTION SECTION", we can see that we have an MX record query. In the "ANSWER SECTION", we have two MX records corresponding the mail servers for gatech.edu.
In addition to the TTL, we also have a notion of priority: 10 for each of the mail servers. This priority value allows administrators to define a primary mail server and a backup.
Here is an example of an A record query for gatech.edu with a trace.
The local resolver issues a query to to the root server, which responds with an NS record for the edu server. The query is issued again to the edu server, which responds with an NS record for the GATech server. The final query is issued to the GATech DNS server, which responds with the A record for gatech.edu
Here is an example of how to map an IP address back to a name; that is, given an IP address, find the PTR record that points to the domain name.
When we ask the root server about this particular IP address, we are referred to a special top level domain in-addr.arpa which maintains referrals to authoritative servers that are maintained by the respective internet routing registries, such as ARIN, RIPE, or APNIC.
After our initial referral to in-addr.arpa, we see another referral to 130.in-addr.arpa where the "130" corresponds to the first octet of the IP address in question: 130.207.7.36.
Next, we ask ARIN about 130.in-addr.arpa, and we receive a referral to 207.130.in-addr.arpa. Because 130.207 is allocated gatech.edu, ARIN knows to point us to dns{1,2,3}.gatech.edu.
Next, we issue the request to dns2.gatech.edu and we can finally get the PTR record because this server knows the reverse mapping for 130.207.7.36 and the name - granite.cc.gatech.edu - that points to this IP address.