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

Cookies: Keeping “State”

Many major Web sites use cookies                                  
Four components:
1) Cookie header line in the
HTTP response message
2) Cookie header line in HTTP
request message
3) Cookie file kept on user’s host
and managed by user’s
browser
4) Back-end database at Web
site

Example:
- Susan accesses Internet always
from same PC
- She visits a specific e-commerce
site for the first time
- When initial HTTP requests arrives
at site, site creates a unique ID
and creates an entry in backend
database for ID

HTTP 0.9/1.0

● One request/response per TCP connection
– Simple to implement
● Disadvantages
– Multiple connection setups → three-way
handshake each time
● Several extra round trips added to transfer

– Multiple slow starts

Single Transfer Example

Performance Issues

● Short transfers are hard on TCP
– Stuck in slow start
● Lots of extra connections
– Increases server state/processing
● Servers also hang on to connection state after
the connection is closed
– Why must server keep these?
– Tends to be an order of magnitude greater than #

of active connections, why?

Netscape Solution
● Mosaic (original popular Web browser) fetched
one object at a time!
● Netscape uses multiple concurrent
connections to improve response time
– Different parts of Web page arrive independently
– Can grab more of the network bandwidth than
other users
● Doesn’t necessarily improve response time
– TCP loss recovery ends up being timeout

dominated because windows are small

Persistent Connection Solution
● Multiplex multiple transfers onto one TCP connection  (Fewer RTTs and less slow start)

HTTP 1.1 New Features

Newer versions of HTTP (1.1) add several  new features (persistent connections, pipelined transfers) to speed things up.

Read More

HTTP Basic

HTTP layered over bidirectional byte stream
– Almost always TCP
● Interaction
– Client sends request to server, followed by
response from server to client
– Requests/responses are encoded in text
● Stateless
– Server maintains no information about past client requests

 HTTP Request

 Request line
– Method
● GET – return URI
● HEAD – return headers only of GET response
● POST – send data to the server (forms, etc.)

– URI
● E.g. http://www.intel-iris.net/index.html with a proxy
● E.g. /index.html if no proxy
– HTTP version

● Request headers
– Authorization – authentication info
– Acceptable document types/encodings
– From – user email
– If-Modified-Since
– Referrer – what caused this page to be requested
– User-Agent – client software

Blank-line
Body

HTTP Request Example

GET /site/nqdinhddt/ HTTP/1.1
Host: sites.google.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:15.0)
Gecko/20100101 Firefox/15.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: [...]
If-Modified-Since: Mon, 24 Sep 2012 22:31:22 GMT

If-None-Match: "1348525882000|#public|0|en|||0"

HTTP Response
● Status-line
– HTTP version
– 3 digit response code
● 1XX – informational
● 2XX – success
– 200 OK
● 3XX – redirection
– 301 Moved Permanently
– 303 Moved Temporarily

304 Not Modified
● 4XX – client error
– 404 Not Found
● 5XX – server error
– 505 HTTP Version Not Supported
Reason phrase
● Headers
– Location – for redirection
– Server – server software
– WWW-Authenticate – request for authentication
– Allow – list of methods supported (get, head, etc)
– Content-Encoding – E.g x-gzip
– Content-Length
– Content-Type
– Expires
– Last-Modified
Blank-line
Body

HTTP/1.1 200 OK
Date: Tue, 27 Mar 2001 03:49:38 GMT
Server: Apache/1.3.14 (Unix)  (Red­Hat/Linux)
mod_ssl/2.7.1 OpenSSL/0.9.5a DAV/1.0.2 PHP/4.0.1pl2
mod_perl/1.24
Last­Modified: Mon, 29 Jan 2001 17:54:18 GMT
ETag: "7a11f­10ed­3a75ae4a"
Accept­Ranges: bytes
Content­Length: 4333
Keep­Alive: timeout=15, max=100
Connection: Keep­Alive
Content­Type: text/html
…..

Read More

Applications (Example with HTTP and FTP)

Some parts of this presentation are copied from
● Roger Dannenberg, Srinivasan Seshan, lecture notes in Computer Network,
CMU http://www.cs.cmu.edu/~srini/15-441/F11/
● Jorg Liebeherr, lecture notes in Internet Engineering, Virginia Uni.,
http://www.cs.virginia.edu/~cs458/
● TCP/IP Protocol Suite lecture notes, The McGraw-Hill Companies, Inc., 2000

Client-Server Paradigm                                                

  
Client:
• Initiates contact with server
(“speaks first”)
• Typically requests service from
server,
• For Web, client is implemented in
browser; for e-mail, in mail reader
Server:
• Provides requested service to
client
• e.g., Web server sends requested
Web page, mail server delivers e-mail




Client-Server with Socket API

What Service Does an Application Need?

Data loss
Some apps (e.g., audio) can
tolerate some loss
● Other apps (e.g., file transfer,

telnet) require 100% reliable data transfer

Timing
Some apps (e.g., Internet
telephony, interactive games)
require low delay to be
“effective”

Bandwidth
Some apps (e.g., multimedia) require minimum amount of bandwidth to
be “effective”

• Other apps (“elastic apps”) make use of whatever bandwidth they get

Transport Service Reqs of Common Apps.

Other Requirements
Network reliability
– Network service must always be available
Security: privacy, denial of service,
authentication, …
Scalability.
– Scale to large numbers of users, traffic flows, …

Manageability: monitoring, control, …

FTP: The File Transfer Protocol

Transfer file to/from remote host
● Client/server model
– Client: side that initiates transfer (either to/from remote)
– Server: remote host
● FTP: RFC 959

● FTP server: port 21

FTP: Separate Control, Data Connection
FTP client contacts FTP server                                            

at port 21, specifying TCP as
transport protocol
● Two parallel TCP connections
opened:
– Control: exchange
commands, responses
between client, server. “out
of band control”
– Data: file data to/from server
● FTP server maintains “state”:
current directory, earlier

authentication




FTP: Commands, Response

Trivial File Transfer Protocol (TFTP)

Use UDP instead of TCP
Serve at port 69

Read More