Your SlideShare is downloading. ×
Katz, Stoica F04 EE122: DNS and the Web
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Katz, Stoica F04 EE122: DNS and the Web


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. EE122: DNS and the Web (after a little more multicast) October 27, 2003
  • 2. EECS 122: Introduction to Computer Networks DNS and WWW Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA 94720-1776
  • 3. Barriers to Multicast
    • Hard to change IP
      • multicast means change to IP
      • details of multicast were very hard to get right
    • Not always consistent with ISP economic model
      • charging done at edge, but single packet from edge can explode into millions of packets within network
    • Troublesome security model
      • Anyone can send to a group
      • Denial-of-service attacks on known groups
  • 4. Application Layer Multicast (ALM)
    • Let the hosts do all the “special” work
      • only require unicast from infrastructure
    • Basic idea:
      • hosts do the copying of packets
      • set up tree between hosts
    • Example: Narada [Yang-hua et al, 2000]
      • Small group sizes <= hundreds of nodes
      • Typical application: chat
  • 5. Narada: End System Multicast Stanford CMU Stan1 Stan2 Berk2 “Overlay” Tree Gatech Berk1 Berkeley Gatech Stan1 Stan2 CMU Berk1 Berk2
  • 6. Algorithmic Challenge
    • Choosing replication/forwarding points among hosts
      • how do the hosts know about each other
      • and know which hosts should forward to other hosts
  • 7. Advantages of ALM
    • No need for changes to IP or routers
    • No need for ISP cooperation
    • End hosts can prevent other hosts from sending
    • Easy to implement reliability
      • use hop-by-hop retransmissions
  • 8. Performance Concerns
    • Stretch
      • ratio of latency in the overlay to latency in the underlying network
    • Stress
      • number of duplicate packets sent over the same physical link
  • 9. Performance Concerns Duplicate Packets: Bandwidth Wastage CMU Stan1 Stan2 Berk2 Gatech Berk1 Delay from CMU to Berk1 increases Stanford Berkeley Gatech Stan1 Stan2 CMU Berk1 Berk2
  • 10. Single Sender Multicast
    • Many problems with IP multicast disappear if each group is associated with a single source
    • Hosts joining multicast group can send join messages to source
      • this sets up delivery tree
      • no worry about “root” being in wrong place
    • This solves several problems:
      • better security and charging model
      • simple algorithm
  • 11. Example
    • Group members: M1, M2, M3
    source M1 M2 M3 control (join) messages data
  • 12. What’s Wrong with SSM?
    • Multiple sources?
      • can set up group per source, or...
      • source can serve as relay for other senders
    • Algorithm?
      • trivial
    • So, why isn’t SSM the answer?
      • multicast no longer serves as “rendezvous”
      • ok for “broadcast” apps, not good for “meeting” apps
  • 13. What Do You Need to Know?
    • DVRMP
    • CBT
    • SSM
    • How they compare
  • 14. Today’s Lecture: 17 Network (IP) Application Transport Link Physical 2 7, 8, 9 10,11 17 , 18, 19 14, 15, 16 21, 22, 23 25 6
  • 15. Internet Names & Addresses
    • Names: e.g.
      • human-usable labels for machines
      • conforms to “organizational” structure
    • Addresses: e.g.
      • router-usable labels for machines
      • conforms to “network” structure
    • How do you map from one to another?
      • Domain Name System (DNS)
  • 16. DNS: History
    • Initially all host-addess mappings were in a file called hosts.txt (in /etc/hosts)
      • Changes were submitted to SRI by email
      • New versions of hosts.txt ftp’d periodically from SRI
      • An administrator could pick names at their discretion
    • As the internet grew this system broke down because:
      • SRI couldn’t handled the load
      • Names were not unique
      • Many hosts had inaccurate copies of hosts.txt
    • Internet growth was threatened!
      • Domain Name System (DNS) was born
  • 17. Basic DNS Features
    • Hierarchical namespace
      • as opposed to original flat namespace
    • Distributed storage architecture
      • as opposed to centralized storage (plus replication)
    • Client--server interaction on UDP Port 53
      • but can use TCP if desired
  • 18. Naming Hierarchy
    • “ Top Level Domains” are at the top
    • Depth of tree is arbitrary (limit 128)
    • Domains are subtrees
      • E.g: .edu,,
    • Name collisions avoided
      • E.g. and can coexist, but uniqueness is job of domain
    root edu com gov mil org net uk fr berkeley mit eecs sims argus etc.
  • 19. Host names are administered hierarchically
    • A zone corresponds to an administrative authority that is responsible for that portion of the hierarchy
    • eecs controls names:
    • berkeley controls names: and
    root edu com gov mil org net uk fr berkeley mit eecs sims argus root edu com gov mil org net uk fr berkeley eecs sims
  • 20. Server Hierarchy
    • Each server has authority over a portion of the hierarchy
      • A server maintains only a subset of all names
    • Each server contains all the records for the hosts in its zone
      • might be replicated for robustness
    • Each server needs to know other servers that are responsible for the other portions of the hierarchy
      • Every server knows the root
      • Root server knows about all top-level domains
  • 21. DNS Name Servers
    • Local name servers:
      • Each ISP (company) has local default name server
      • Host DNS query first goes to local name server
    • Authoritative name servers:
      • For a host: stores that host’s (name, IP address)
      • Can perform name/address translation for that host’s name
    • Can also do IP to name translation, but won’t discuss
  • 22. DNS: Root Name Servers
    • Contacted by local name server that can not resolve name
    • Root name server:
      • Contacts authoritative name server if name mapping not known
      • Gets mapping
      • Returns mapping to local name server
    • ~ Dozen root name servers worldwide
  • 23. Simple DNS Example
    • Host wants IP address of
    • 1. Contacts its local DNS server,
    • 2. contacts root name server, if necessary
    • 3. Root name server contacts authoritative name server,, if necessary
    requesting host root name server authorititive name server 1 2 3 4 5 6 local name server
  • 24. Example of Recursive DNS Query
    • Root name server:
    • May not know authoritative name server
    • May know intermediate name server : who to contact to find authoritative name server?
    • Recursive query:
    • Puts burden of name resolution on contacted name server
    • Heavy load?
    requesting host root name server 1 2 3 4 5 6 authoritative name server 7 8 local name server intermediate name server (edu server)
  • 25. Example of Iterated DNS Query
    • Iterated query:
    • Contacted server replies with name of server to contact
    • “ I don’t know this name, but ask this server”
    requesting host root name server 1 2 3 4 6 7 authoritative name server 5 8 iterated query local name server intermediate name server (edu server)
  • 26. DNS Records
    • Four fields: (name, value, type, TTL)
    • Type = A:
      • name = hostname
      • value = IP address
    • Type = NS:
      • name = domain
      • value = name of dns server for domain
  • 27. DNS Records (cont’d)
    • Type = CNAME:
      • name = hostname
      • value = canonical name
    • Type = MX:
      • name = domain in email address
      • value = canonical name of mail server
  • 28. DNS as Indirection Service
    • Can refer to machines by name, not address
      • not only easier for humans
      • also allows machines to change IP addresses without having to change way you refer to machine
    • Can refer to machines by alias
      • can be generic web server
      • but DNS can point this to particular machine that can change over time
    • But, this flexibility applies only within domain!
  • 29. Special Topics
    • DNS caching
      • improve performance by saving results of previous lookups
    • DNS “hacks”
      • return records based on requesting IP address
    • dynamic DNS
      • allows remote updating of IP address for mobile hosts
    • DNS politics (ICANN) and branding battles
  • 30. Important Properties of DNS
    • Administrative delegation and distributed server architecture results in:
    • Easy unique naming
    • Fate sharing for network failures
    • Reasonable trust model
  • 31. The Web
    • A distributed database of “pages”
    • Core components:
      • Servers: store files and execute remote commands
      • Browsers: retrieve and display “pages”
      • URLs: way to refer to pages
    • Need a protocol to transfer information between clients and servers
      • HTTP
  • 32. Uniform Record Locator
    • protocol://host-name:port/directory-path/resource
    • Extend the idea of hierarchical namespaces to include anything in a file system
    • Extend to program executions as well…
      • Server side processing can be incorporated in the name
  • 33. Web and DNS
    • URLs use hostnames
    • Thus, content names are tied to specific hosts
    • This is bad!
    • URNs are one proposal to achieve persistence
  • 34. Hyper Text Transfer Protocol
    • Client-server architecture
    • Synchronous request/reply protocol
      • Runs over TCP, Port 80
    • Stateless
    • Uses unicast
  • 35. Big Picture Client Server TCP Syn TCP syn + ack TCP ack + HTTP GET Establish connection Request response Client request Close connection . . .
  • 36. Hyper Text Transfer Protocol Commands
    • GET – transfer resource from given URL
    • HEAD – GET resource metadata (headers) only
    • PUT – store/modify resource under given URL
    • DELETE – remove resource
    • POST – provide input for a process identified by the given URL (usually used to post CGI parameters)
  • 37. Response Codes
    • 1x informational
    • 2x success
    • 3x redirection
    • 4x client error in request
    • 5x server error; can’t satisfy the request
  • 38. Client Request
    • Steps to get the resource:
      • Use DNS to obtain the IP address of www. eecs . berkeley . edu
      • Send to an HTTP request:
    GET /index.html HTTP/1.0
  • 39. Server Response HTTP/1.0 200 OK Content-Type: text/html Content-Length: 1234 Last-Modified: Mon, 19 Nov 2001 15:31:20 GMT <HTML> <HEAD> <TITLE>EECS Home Page</TITLE> </HEAD> … </BODY> </HTML>
  • 40. Example (from Kurose and Ross)
    • After finding out the IP address of the host…
    • http client initiates a TCP connection on :80
    • Client sends the get request via socket established in 1
    • Server sends the html file, which is encapsulated in its response
    • http server tells tcp to terminate connection
    • http client receives the file and the browser parses it…contains ten jpeg images
    • Client repeats steps 1-4
  • 41. HTTP/1.0 Example Client Server Request image 1 Transfer image 1 Request image 2 Transfer image 2 Request text Transfer text Finish display page
  • 42. HHTP/1.0 Performance
    • Create a new TCP connection for each resource
      • Large number of embedded objects in a web page
      • Many short lived connections
    • TCP transfer
      • Too slow for small object
      • May never exit slow-start phase
    • Connections may be set up in parallel (5 is default in most browsers)
  • 43. HTTP/1.0 Caching
    • Exploit locality of reference
    • A modifier to the GET request:
      • If-modified-since – return a “not modified” response if resource was not modified since specified time
    • A response header:
      • Expires – specify to the client for how long it is safe to cache the resource
    • A request directive:
      • No-cache – ignore all caches and get resource directly from server
    • These features can be best taken advantage of with HTTP proxies
      • Locality of reference increases if many clients share a proxy
  • 44. Web Proxies
    • Intermediaries between client and server
    Client 1 Proxy Proxy Server Client 2 Client N . . .
  • 45. HTTP/1.1 (1996)
    • Performance:
      • Persistent connections
      • Pipelined requests/responses
    • Support for virtual hosting
    • Efficient caching support
      • Network Cache assumed more explicitly in the design
      • Gives more control to the server on how it wants data cached
  • 46. Persistent Connections
    • Allow multiple transfers over one connection
    • Avoid multiple TCP connection setups
    • Avoid multiple TCP slow starts
  • 47. Pipelined Requests/Responses
    • Buffer requests and responses to reduce the number of packets
    • Multiple requests can be contained in one TCP segment
    • Note: order of responses has to be maintained
    Client Server Request 1 Request 2 Request 3 Transfer 1 Transfer 2 Transfer 3
  • 48. What You Need to Know
    • DNS: record types, and how they are used
    • HTTP basics (and essential differences between 1.0 and 1.1)
  • 49. What’s the Moral of this Story?
    • QoS and IP Multicast:
      • interesting algorithmic and architectural issues
      • thousands of academic papers
      • ubiquitous in routers, but not deployed by ISPs
      • little or no impact on end users
    • DNS and the Web:
      • no research papers on topic before deployment
      • really boring designs
      • they changed the world....