DNS - Load balancing

● For some sites, e.g. google, facebook, zing, no single hardware (server) can handle such big traffic
– Multiple server for one domain
– Fault tolerance
● Question
– Choose this or that?
– or keep them equal (load balancing)

Reliability

● DNS servers are replicated
– Name service available if ≥ one replica is up
– Queries can be load balanced between replicas
● UDP used for queries
– Need reliability → must implement this on top of UDP!
– Why not just use TCP?
● Try alternate servers on timeout
– Exponential backoff when retrying same server
● Same identifier for all queries

– Don’t care which server responds

Prefetching
● Name servers can add additional data to response
● Typically used for prefetching
– CNAME/MX/NS typically point to another host name
– Responses include address of host referred to in “additional section”

Email Address
● MX records point to mail exchanger for a name– E.g. mail.acm.org is MX for acm.org
● Addition of MX record type proved to be a challenge
– How to get mail programs to lookup MX record formail delivery?

– Needed critical mass of such mailers
Root zone
● Generic Top Level Domains (gTLD)
= .com, .net, .org, etc...
● Country Code Top Level Domain (ccTLD)
= .vi, .us, .ca, .fi, .uk, etc...
● Root server ({a-m}.root-servers.net) also used to
cover gTLD domains
– Load on root servers was growing quickly!
– Moving .com, .net, .org off root servers was clearly

necessary to reduce load → done Aug 2000

gTLDs
● Unsponsored
– .com, .edu, .gov, .mil, .net,
.org
– .biz → businesses
– .info →  general info
– .name → individuals
● Sponsored (controlled by a particular association)
– .aero → air-transport industry
– .cat → catalan related
– .coop → business
cooperatives
– .jobs → job announcements
– .museum → museums
– .pro → accountants, lawyers,
and physicians
– .travel → travel industry
● Starting up
– .mobi →  mobile phone
targeted domains
– .post →  postal
– .tel →  telephone related
– .asia, .cym, .geo, .kid,

.mail, .sco, .web, .xxx

Tracing hierarchy

● Dig Program
– Allows querying of DNS system
– Use flags to find name server (NS)

– Disable recursion so that operates one step at a time

dig +norecurse @a.root-servers.net NS fit.hui.edu.vn
;; AUTHORITY SECTION:
vn. 172800 IN NS f.dns-servers.vn.
vn. 172800 IN NS b.dns-servers.vn.
vn. 172800 IN NS vn.cctld.authdns.ripe.net.
vn. 172800 IN NS e.dns-servers.vn.
vn. 172800 IN NS d.dns-servers.vn.
vn. 172800 IN NS a.dns-servers.vn.
vn. 172800 IN NS c.dns-servers.vn.

All .edu names handled by set of servers

$dig +norecurse @b.dns-servers.vn NS fit.hui.edu.vn
;; AUTHORITY SECTION:
hui.edu.vn. 43200 IN NS hcm-server1.vnn.vn.
hui.edu.vn. 43200 IN NS vdc-hn01.vnn.vn.

vdc-hn01 is the master NS for this zone

$ dig +norecurse @vdc-hn01.vnn.vn NS fit.hui.edu.vn
;; AUTHORITY SECTION:
hui.edu.vn. 86400 IN SOA  vdc-hn01.vnn.vn.
postmaster.vnn.vn. 2012072701 10800 3600 604800 86400

DNS (Summary)

● Motivations → large distributed database
– Scalability
– Independent update
– Robustness
● Hierarchical database structure
– Zones
– How is a lookup done
● Caching/prefetching and TTLs
● Reverse name lookup

● What are the steps to creating your own domain?

Read More

The Domain Name System

● The DNS is an Internet-wide distributed database that translate between domain names and IP addresses
● Times before DNS (1985)
– Using HOSTS.txt file under, e.g., /etc/hosts

– Download from server through FTP regularly
– Many more downloads
– Many more update

Hence, DNS
But, why not centralize DNS?
– Single point failure
– Traffic volume
– Distant centralized database
– Single point of update
→ Doesn't scale

DNS goals
● Basically a wide-area distributed database
● Scalability
● Decentralized maintenance
● Robustness
● Global scope

– Names mean the same thing everywhere
Programmer's view of DNS
● Conceptually, programmers can view the DNS
database as a collection of millions of host entry
structures:
/* DNS host entry structure */
struct addrinfo {
  int ai_family;    /* host address type (AF_INET) */
  size_t ai_addrlen;  /* length of an address, in bytes */
  struct sockaddr *ai_addr; /* address! */
  char *ai_canonname;   /* official domain name of host */
  struct addrinfo *ai_next; /* other entries for host */
};

 
● Functions for retrieving host entries from DNS:
– getaddrinfo: query key is a DNS host name.
– getnameinfo: query key is an IP address.

DNS message format

DNS header field

● Identification

– Used to match up request/response
● Flags
– 1-bit to mark query or response
– 1-bit to mark authoritative or not
– 1-bit to request recursive resolution
– 1-bit to indicate support for recursive resolution


DNS Resource Record
RR format: (class, name, value, type, ttl)
● DB contains tuples called resource records (RRs)
● Classes = Internet (IN), Chaosnet (CH), etc.
● Each class defines value associated with type

Hierarchy of name server
The resolution of the hierarchical name space is done by a hierarchy of name servers
● Each server is responsible (authoritative) for a contiguous portion of the DNS namespace, called a zone.
DNS server answers queries about hosts in its zone

DNS server

● For each zone, there must be a primary name server and a secondary name server
– The primary server (master server) maintains a zone file which has information about the zone. Updates are made to the primary server manually
– The secondary server copies data stored at the primary server.
● Adding a host:
– abc.com.vn created by abc.com.vn administrator

– Who created abc.com.vn?

Root name server

   
● The root name servers know how to find the authoritative name
servers for all top-level zones. See http://www.root-servers.org/
● Ten servers were originally in the United States. Three servers were
originally located in Stockholm (I), Amsterdam (K), and Tokyo (M).

http://en.wikipedia.org/wiki/Root_nameserver

Server/Resolver

● Each host has a resolver
– Typically a library that applications can link to
– Local name servers hand-configured (e.g.
/etc/resolv.conf)
● Name servers
– Either responsible for some zone or...
– Local servers
● Do lookup of distant host names for local hosts

● Typically answer queries about local zone

Recursive and Iterative Queries

● There are 2 type of queries (determined by a
bit in the query)
– Recursive query: When the name server of a host
cannot resolve a query, the server issues a query
to resolve the query
– Iterative query: When the name server of a host
cannot resolve a query, it sends a referral to

another server to the resolver

Recursive query
● If the server cannot supply the answer, it will  send the query to the “closest known”  authoritative name server.
● Only returns final answer or “not found”
● Puts burden of name resolution on contacted name server

Iterative query
● “I don’t know this name, but ask this server”
● This involves more work for the local DNS server

Workload Impact & Choice
● Local server typically does recursive
● Root/distant server does iterative

Workload and Caching
● Are all servers/names likely to be equally popular?
● DNS responses are cached
– Quick response for repeated translations
– Other queries may reuse some parts of lookup (ftp from www)
– NS records for domains
● DNS negative queries are cached
– Don’t have to repeat past mistakes
– E.g. misspellings, search strings in resolv.conf
● Cached data periodically times out
– Lifetime (TTL) of data controlled by owner of data

– TTL passed with every record

Read More