Domain Name System

Created

Internet Names and Addresses

Machine addresses are router-usable labels for machine.

  • Conforms to network structure, or the "where"
  • E.g., 141.212.113.143

Machine names are human-usable labels for machines

  • Conforms to organizational structure, or the "who"
  • E.g., cs.jhu.edu

The Domain Name System (DNS) is how we map from one to another. It's a directory service.

Why do we have both machine addresses and name?

  • For convenience: it's easier to remember the name than the number
  • It provides a level of indirection: this decouples the name from the address. Therefore, you can change IP address while keeping machine name.

Alternative Directory Design

These are three extreme methods, to demonstrate the possibilities when designing a directory.

Flood the query

  • the correctly named node will responds with its address
  • the request is sent out to everyone (hence the name "flooding the network" with queries)
  • con: high overhead in large network
  • e.g., ARP

Push data to all the clients

  • all nodes store a full copy of the directory
  • con: high overhead for many names and updates
    • imagine the mechanism needed to take care of the update procedures if something is updated.
  • e.g., /etc/hosts

Central directory server

  • all data and queries handled by one machine
  • con: poor performance, scalability, and reliability
    • imagine routing something all the way across the world

History

Initially all host-addresses were in a hosts.txt files in /etc/hosts. It was maintained by the Stanford Research Institute (SRI).

  • changes were submitted to SRI by email, and new versions of hosts.txt were periodically FTP'd from SRI

However, as the internet grew the system broke down due to the following reasons:

  • too much load for SRI
  • names were not unique
  • hosts had inaccurate copies of hosts.txt

The DNS was invented to fix this.

Goals

The goals of the DNS were:

  • uniqueness: no naming conflicts
  • scalable: many names and frequent updates
  • distributed, autonomous administration: ability to update my own (machines') names and no one has to track everybody's updates
  • highly available: any service you want to get from the internet is based on DNS so it needs to always be live
  • fast lookup: users shouldn't need to wait long

On the other hand, perfect consistency is not a goal.

To accomplish this, there are a few ideas:

  • partition the namespace:
  • distribute administration to each partition, which have the following benefits:
    • this enabled autonomy for updating your own (machines') names
    • don't have to track everybody's update
  • distribute name resolution for each partition

Partitioning

The DNS accomplishes its goals by using hierarchy. There are three intertwined hierarchies:

  • hierarchical namespace as opposed to original flat namespace (helps with uniqueness in naming)
  • hierarchically administered as opposed to centralized (which had a single point of failures)
  • (distributed) hierarchy of servers as opposed to centralized storage

Hierarchical namespace

Hierarchical namespace refers to how naming is kept unique by making it so that you only need to find unique names within a sub-namespace.

"Top Level Domains" are all the children of root, like edu, com, etc. Domains are subtrees like .edu or jhu.edu The name is leaf-to-root path, so the leaf is at the very beginning Depth of the tree is arbitrary (limit 128) Name collisions are trivially avoided since each domain is responsible for its own children.

Example hierarchical namespace:

- root
	- edu
		- jhu
			- cs
		- princeton
	- com
	- gov
	- org
	- uk
	- fr

Hierarchically Administration

A zone corresponds to an administrative authority that is responsible for that portion. For example, root and its leaves are managed by ICANN/IANA, Johns Hopkins University is responsible for jhu, and JHU's CS department is responsible for cs under jhu

Server Hierarchy

At the top of the hierarchy are root servers, whose location is hardwired into other servers.

  • When a user types in a domain name, the request first goes to a recursive resolver which then queries the root servers to find the name servers from the appropriate TLD.
  • 13 root servers in different parts of the world.

Top-level domain (TLD) servers are managed professionally

  • Directs the resolver to the name servers for the second-level domain.

Bottom level have authoritative DNS servers maintained by the corresponding administrative authority

  • they actually store the name-to-address mapping
  • stores the "resource records" for all DNS names in the domain that it has authority for.

In general, each server stores a (small) subset of the total DNS database.

Each server needs to know other servers that are responsible for the other portion of the hierarchy

  • every server knows its root
  • root server knows about all the top-level domain

DNS servers are often replicated (primary/secondary), so that name service is available if at least one of the replica is up. Queries can also be load-balanced between replicas.

  • Usually, UDP is required for queries, so if we want reliability, it must be implemented on UDP.

Alternate servers should be tried on time out and we use the same identifier for all queries so it doesn't matter which server responds.

DNS Root

Initially, the DNS root was in VA, USA.

Now, there are 13 DNS roots globally, labeled from A-M. See the root servers here.

The servers are replicated via anycast, a networking and routing technique used to improve the availability and performance of services like DNS.

How does anycast work:

  • Routing finds the shortest path to destination. If there are several locations are given the same address, then the network will deliver the packet to the closest location with that address.
  • Characteristics: robust and requires no modification to routing algoirthms.

DNS Records

DNS servers store resource records (RRs) which is a tuple of (name, value, type, TTL)

The type can be

  • A: (-> Address)
    • name = hostaddress
    • value = IP address
  • NS: (-> Name Server)
    • name = domain
    • value = name of DNS server for domain
  • CNAME: (-> Canonical Name)
    • name = alias name for some "canonical" (real) name, like documents.example.com is really docs.example.com
    • value = canonical name
  • MX: (-> Mail eXchanger)
    • name = domain in email address
    • value == name(s) of mail server(s)

How do you insert resource records into DNS?

  • register foobar.com at registrar like GoDaddy by providing with the names and IP addresses of your authoritative name server(s) where the registrar inserts RR pairs into the .com TLD server like (foobar.com, dns1.foobar.com, NS) or (dns1.foobar.com, 212.44.9.129, A).
  • store RR in your server dns1.foobar.com like type A for www.foobar.com or type MX record for foobar.com

Note: authoritative name servers are a specific type of DNS server that holds authoritative information about a domain and responds to queries for that domain's DNS records. DNS is the overarching system that facilitates the translation between domain names to IP addresses.

Using DNS

Using DNS for client/app view. There's two components: local DNS servers or resolver software on hosts.

Local DNS servers ("default name server")

  • Clients configured with default server’s address OR learn it via a host configuration protocol (e.g., DHCP)

Client application ´- Resolver software obtains DNS name (e.g., from URL) by initiating and handling DNS queries.

  • Do gethostbyname() to trigger DNS request to its local DNS server.

How do you resolve a name:

  • recursive name resolution: leave the work to server which will return you the address. You do not know any of the intermediary responses
  • iterative name resolution: you ask the server who to ask next, so you are involved in the intermediary responses.

Name resolution example: say you want to go to www.princeton.edu, what are the steps that the DNS server takes? This is the iterative method:

  • first the DNS clients goes to your DNS server (suppose it doesn't know the address), then it asks the root server for the .edu server which it returns.
  • You ask the .edu servers for the princeton.edu server.
  • You ask the princeton.edu server for www.princeton.edu, where it responds with the IP address.
  • Now the local DNS server returns the DNS client the IP address

In reality, we don't want to use recursive, because then the root has to do all the work, which will be overloaded. It also takes some time for it to retrieve everything.

DNS Protocol

Query and Reply messages; both has the same format

  • Header: identifier, flags, etc.
  • Resource records
  • See textbook for details

Client-server interaction is on UDP Port 53. The specs support TCP as well, but its not always implemented.

Availability

Replicated DNS servers (primary/secondary) increases availability because it will function as long as at least one replica is up. The queries can also be load-balanced between replicas.

  • Usually UDP is used for queries. Reliability, if needed, must be implemented on UDP.
  • Try alternative servers on timeout
  • same identifier for all queries, so the client doesn't care which server responds

DNS Caching

We need fast lookup!

  • Queries take time, up to 1-second before starting download.

Caching greatly reduces overhead, since the top-level servers very rarely change. Popular sites are visited often. Local DNS server often has this information cached.

How DNS caching works is that the DNS servers cache the response to queries, and in the response, it has a "time to live" (TTL) field. When the TTL expires, the server deletes the cached entry.

Negative caching:

  • it also remembers the names that don't work (like misspellings).
  • failing can take a long time so it's good to remember that these names don't work.
  • negative caching is optional and not widely implemented.

Indirection

Addresses can change underneath.

  • E.g., cnn.com can change to new IP.

Names could also map to multiple IP addresses for load-balancing (CDN) or for reducing latency by picking nearby servers (CDN).

Multiple names could also be used for the same address.

  • E.g., many services (mail, www) on the same machine
  • E.g., aliases like www.cnn.com and cnn.com map to the same place.

Linked from Computer Networks