1. EE 122: Lecture 20 (Domain Name Server - DNS) Ion Stoica Nov 15, 2001 (* based on the some on-line slides of J. Kurose & K. Rose and of Raj Jain)

2. istoica@cs.berkeley.edu2 Names & Addresses  What is a name?  What is an address?  What is an identifier?  What is the difference between name, addresses, and identifiers?

3. istoica@cs.berkeley.edu3 Internet Centric View  Addresse: -Says how to reach an object  it has location semantics associated to it -It’s in a format easy to process by computers  Name: -Does not have any location semantics associated to it -It’s in a format easier to understand/read/remember by people  Examples: -IP address: 128.32.27.22 -Name: amber.berkeley.edu

4. istoica@cs.berkeley.edu4 General View  Differentiating between names and addresses introduces several consistency problems: -What is a multicast IP address? -What is the IP address of a mobile host? -What is cnri.reston.va.us?  Solution: interpret an address as just another name (that may happen to have location semantics)

5. istoica@cs.berkeley.edu5 Name Service  Name space: define the set of possible names -Hierarchical (e.g., Unix and Windows file names) -Flat  Bindings: the mapping between names and values (e.g., bindings can be implemented by using tables)  Resolution: procedure that, when invoked with a name, returns the corresponding value  Name server: specific implementation of a resolution mechanism that is available on the network and that can be queried by sending messages

6. istoica@cs.berkeley.edu6 General View  In general there are multiple mappings Host name: amber.berkeley.edu IP address: 128.32.27.22 Ethernet MAC address: 12.34.56.78.90.12 DNS resolution ARP (Address Resolution Protocol)

7. istoica@cs.berkeley.edu7 Mapping  Multiple names can map onto the same name at the underlying level -Example: www.berkeley.edu and amber.berkeley.edu can map to the same machine (I.e., the same IP address)  One name can map onto multiple names at the underlying level -Example: www.yahoo.com can be mapped to multiple machines

8. istoica@cs.berkeley.edu8 Name Hierarchy root edu com govmil org netukfr berkeley cmu eecs sims divine

9. istoica@cs.berkeley.edu9 Name Hierarchy  Unique domain suffix is assigned by the Internet Authority  The domain administrators have complete control over the domain  No limit on the number of subdomains or number of levels  Name space is not related with the physical interconnection  Geographical hierarchy is allowed (e.g., cnri.reston.va.us)  A name could be a domain or an individual objects

10. istoica@cs.berkeley.edu10 Top Level Domains Domain NameAssignment comCommercial eduEducational govGovernment milMilitary netNetwork OrgOther organizations ArpaAdvances research project agency country codeau, uk, ca

11. istoica@cs.berkeley.edu11 DNS Name Servers  Why not centralize DNS? -Single point of failure -Traffic volume -Distant centralized database -Maintenance  Doesn’t scale!

12. istoica@cs.berkeley.edu12 Server Hierarchy: Zones  A zone corresponds to an administrative authority that is responsible for that portion of the hierarchy root edu com govmil org netukfr berkeley cmu eecs sims divine

13. istoica@cs.berkeley.edu13 Server Hierarchy  Server are organized in hierarchies  Each server has authority over a portion of the hierarchy -A single node in the name hierarchy cannot be split -A server maintains only a subset of all names -It needs to know other servers that are responsible for the other portions of the hierarchy

14. istoica@cs.berkeley.edu14 Server Hierarchy  Authority: each server has the name to address translation table for all names in the name space it controls  Every server knows the root  Root server knows about all top-level domains

15. istoica@cs.berkeley.edu15 DNS Name Servers  No server has all name-to-IP address mappings  Local name servers: -Each ISP (company) has local (default) name server -Host DNS query first go to local name server  Authoritative name servers: -For a host: stores that host’s IP address, name -Can perform name/address translation for that host’s name

16. istoica@cs.berkeley.edu16 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

17. istoica@cs.berkeley.edu17 Simple DNS Example Host whsitler.cs.cmu.edu wants IP address of www.berkeley.edu 1. Contacts its local DNS server, mango.srv.cs.cmu.edu 2. mango.srv.cs.cmu.edu contacts root name server, if necessary 3. Root name server contacts authoritative name server, ns1.berkeley.edu, if necessary requesting host whistler.cs.cmu.edu www.berkeley.edu root name server authorititive name server ns1.berkeley.edu local name server mango.srv.cs.cmu.edu 1 2 3 4 5 6

18. istoica@cs.berkeley.edu18 DNS Example Root name server:  May not know authoritative name server  May know intermediate name server: who to contact to find authoritative name server? requesting host whistler.cs.cmu.edu www.berkeley.edu root name server local name server mango.srv.cs.cmu.edu 1 2 3 4 5 6 authoritative name server ns1.berkeley.edu intermediate name server (edu server) 7 8

19. istoica@cs.berkeley.edu19 DNS: Iterated Queries Recursive query:  Puts burden of name resolution on contacted name server  Heavy load? Iterated query:  Contacted server replies with name of server to contact  “I don’t know this name, but ask this server” requesting host whistler.cs.cmu.edu www.berkeley.edu root name server local name server mango.srv.cs.cmu.edu 1 2 3 4 6 7 authoritative name server ns1.berkeley.edu intermediate name server (edu server) 5 8 iterated query

20. istoica@cs.berkeley.edu20 DNS Records DNS: distributed database storing resource records (RR)  Type=NS -name is domain (e.g. foo.com) -value is IP address of authoritative name server for this domain RR format: (name, value, type,ttl)  Type=A -name is hostname -value is IP address  Type=CNAME -name is an alias name for some “cannonical” (the real) name -value is cannonical name  Type=MX -value is hostname of mailserver associated with name

21. istoica@cs.berkeley.edu21 DNS protocol, messages DNS protocol : query and reply messages, both with same message format msg header  identification: 16 bit # for query, reply to query uses same #  flags: -query or reply -recursion desired -recursion available -reply is authoritative

22. istoica@cs.berkeley.edu22 DNS protocol, messages Name, type fields for a query RRs in reponse to query Records for authoritative servers Additional “helpful” info that may be used

23. istoica@cs.berkeley.edu23 Discussion  Robustness -Use multiple replicas, but… -…what if someone mounts a denial of service attack to all root servers?  Performance: -Use caching to speed-up subsequent queries to the same name  What about update/notify? -Mechanisms under design by IETF (RFC 2136; http://www.ietf.org/html.charters/dnsind-charter.html)

24. istoica@cs.berkeley.edu24 Summary  Address: just another form of name that may have location semantics  DNS: maps names onto IP address  Name space and the administration are both hierarchical  Replication: used to increase robustness  Caching: used to increase the performance