Presentation is loading. Please wait.

Presentation is loading. Please wait.

COMS/CSEE 4140 Networking Laboratory Lecture 09 Salman Abdul Baset Spring 2008.

Similar presentations


Presentation on theme: "COMS/CSEE 4140 Networking Laboratory Lecture 09 Salman Abdul Baset Spring 2008."— Presentation transcript:

1 COMS/CSEE 4140 Networking Laboratory Lecture 09 Salman Abdul Baset Spring 2008

2 2 Announcements  Prelab 8 and Lab report 7 due next week before your lab slot  Weekly project reports due before Friday 5pm

3 3 Agenda  DNS history  DNS concepts  Recursive and iterative queries  Caching  Resource records  mDNS  King tool

4 4 DNS History  hosts.txt file (<1983) Download a single file (hosts.txt) from a central server with FTP Names in hosts.txt are not structured. The hosts.txt file still works on most operating systems. It can be used to define local names.  Paul Mockapetris DNS RFC 882, 883 – updated by RFC 1032, 1033  DNS implementation Written by four Berkeley students (client/server) Renamed BIND in 1985 (Berkeley Internet Name Daemon)

5 5 Domain Names and IP addresses  People prefer to use easy-to-remember names instead of IP addresses  Domain names are alphanumeric names for IP addresses e.g., neon.ece.utoronto.ca, www.google.com, ietf.org  The domain name system (DNS) is an Internet-wide distributed database that translates between domain names and IP addresses  How important is DNS? Imagine what happens when the local DNS server is down.

6 6 Design Principles of DNS  Name space (domain namespace) Hierarchical and logical tree  Distributed (Delegation) Be maintained in a distributed manner Size of DNS database and frequency of updates Per organization – can additional layers of hierarchy  Names for hosts, email servers, and others  Name space and protocols Notion of address in various protocols Names of hosts can be assigned without regard of location on a link layer network, IP network or autonomous system  In practice, allocation of the domain names generally follows the allocation of IP address, e.g., All hosts with network prefix 128.143/16 have domain name suffix virginia.edu

7 7 DNS Usage Assumptions  Size of the total database Proportional to number of hosts in the Internet ~110 million gTLDs (as of April 7, 2008)  Slow (days) and fast (min/sec) changing data  Access is critical than update guarantees!  Each organization is responsible for providing redundant DNS servers for its hosts.

8 8 Elements of DNS  Domain Name Space Specification for tree structured name space Resource Records (RR)  Name Servers Hold information about part of domain’s tree structure called Zone  Resolvers Programs that extract information from name servers in response to client requests

9 9 Resolver and Name Server 1. An application program on a host accesses the domain system through a DNS client, called the resolver 2. Resolver contacts DNS server, called name server 3. DNS server returns IP address to resolver which passes the IP address to application  Reverse lookups are also possible, i.e., find the hostname given an IP address

10 10 Managed by UofT DNS Name Hierarchy  DNS hierarchy can be represented by a tree  Root and top-level domains are administered by an Internet central name registration authority (ICANN)  Below top-level domain, administration of name space is delegated to organizations  Each organization can delegate further Managed by ECE Dept. Siblings should have different names

11 11 Domain Name System  Each node in the DNS tree represents a DNS name  Each branch below a node is a DNS domain. DNS domain can contain hosts or other domains (subdomains)  Example: DNS domains are., edu, virginia.edu, cs.virginia.edu

12 12 Domain Names  Hosts and DNS domains are named based on their position in the domain tree  Every node in the DNS domain tree can be identified by a unique Fully Qualified Domain Name (FQDN). The FQDN gives the position in the DNS tree.  A FQDN consists of labels (“cs”,“virginia”,”edu”) separated by a period (“.”)  There can be a period (“.”) at the end.  Each label can be up to 63 characters long  FQDN contains characters, numerals, and dash character (“-”)  FQDNs are not case-sensitive Note the dot

13 13 Top-level domains (TLDs)  IANA classifies TLD into three types gTLD (generic): 3-character code indicates the function of the organization  Used primarily within the US .com,.net etc.–.mil and.gov reserved for use by US ccTLD (country code): 2-character country or region code  Examples: us, va, jp, de iTLD (infrastructure): A special domain (in-addr.arpa) used for IP address-to-name mapping  Pseudo domains.local for the Zeroconf protocol  Reserved TLD.example,.invalid,.localhost,.test

14 14 Top-level domains (TLDs)  http://www.iana.org/domains/root/db/ http://www.iana.org/domains/root/db/  iTLD.arpa,.root  gTLD.aero,.asia,.biz,.cat,.com,.coop,.edu,.gov,.info,.int,.jobs,.mil,.mobi,.museum,.name,.net,.org,.pro,.tel,.travel  ccTLD >200 countries  Non-conventional usage del.icio.us, inter.net

15 15 TLD Distribution  Total 110 million records  Source: http://icannwiki.org/Domain_Statistics http://icannwiki.org/Domain_Statistics

16 16 Hierarchy of Name Servers  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.  Zone is a part of the subtree  DNS server answers queries about hosts in its zone

17 17 Authority and Delegation  Authority for the root domain is with the Internet Corporation for Assigned Numbers and Names (ICANN)  ICANN delegates to accredited registrars (for gTLDs) and countries for country code top level domains (ccTLDs)  Authority can be delegated further  Chain of delegation can be obtained by reading domain name from right to left.  Unit of delegation is a “zone”.

18 18 DNS Domain and Zones  Domain.edu conceptually contains all data for columbia.edu, www.columbia.edu, cs.columbia.edu, yale.edu, etc. www.columbia.edu  Zone for.edu contains nameserver reference for yale.edu and columbia.edu and all data for harvard.edu.edu domain.edu zone

19 19 DNS Domain and Zones  Each zone is anchored at a specific domain node, but zones are not domains.  A DNS domain is a branch of the namespace  A zone is a portion of the DNS namespace generally stored in a file (It could consists of multiple nodes)  A server can divide part of its zone and delegate it to other servers

20 20 Primary & Secondary Name Servers  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 The secondary server copies data stored at the primary server. Adding a host:  When a new host is added (“gold.cs.virginia.edu”) to a zone, the administrator adds the IP information on the host (IP address and name) to a configuration file on the primary server

21 21 Root Name Servers  The root name servers know how to find the authoritative name servers for all top- level zones.  There are only 13 root name servers  Root servers are critical for the proper functioning of name resolution A.ROOT-SERVERS.NET. 198.41.0.4 B.ROOT-SERVERS.NET. 192.228.79.201 C.ROOT-SERVERS.NET. 192.33.4.12 D.ROOT-SERVERS.NET. 128.8.10.90 E.ROOT-SERVERS.NET. 192.203.230.10 F.ROOT-SERVERS.NET. 192.5.5.241 G.ROOT-SERVERS.NET. 192.112.36.4 H.ROOT-SERVERS.NET. 128.63.2.53 I.ROOT-SERVERS.NET. 192.36.148.17 J.ROOT-SERVERS.NET. 192.58.128.30 K.ROOT-SERVERS.NET. 193.0.14.129 L.ROOT-SERVERS.NET. 197.7.83.42 M.ROOT-SERVERS.NET. 202.12.27.33

22 22 Agenda  DNS history  DNS concepts  Recursive and iterative queries  Caching  Resource records  mDNS  King tool

23 23 Domain Name Resolution 1. User program issues a request for the IP address of a hostname 2. Local resolver formulates a DNS query to the name server of the host 3. Name server checks if it is authorized to answer the query. a) If yes, it responds. b) Otherwise, it will query other name servers, starting at the root tree 4. When the name server has the answer it sends it to the resolver.

24 24 Recursive and Iterative Queries  There are two types of queries: Recursive queries Iterative (non-recursive) queries  The type of query is determined by a bit in the DNS query  Recursive query: When the name server of a host cannot resolve a query, the server issues a query to resolve the query  Iterative queries: When the name server of a host cannot resolve a query, it sends a referral to another server to the resolver.

25 25 Recursive Queries  In a recursive query, the resolver expects the response from the name server  If the server cannot supply the answer, it will send the query to the “closest known” authoritative name server (here: In the worst case, the closest known server is the root server)  The root sever sends a referral to the “edu” server. Querying this server yields a referral to the server of “virginia.edu”  … and so on

26 26 Iterative Queries  In an iterative query, the name server sends a closest known authoritative name server a referral to the root server.  This involves more work for the resolver

27 27 Recursive vs. Iterative Queries  Recursive [Con] resource intensive – DNS server maintains state [Pro] Cache namespace – helpful for other queries  Iterative [Pro] DNS server never maintains state [Con] Caching is local to a machine – others cannot benefit from it

28 28 Caching  To reduce DNS traffic, name servers caches information on domain name/IP address mappings  When an entry for a query is in the cache, the server does not contact other servers  Note: If an entry is sent from a cache, the reply from the server is marked as “unauthoritative”

29 29 Resource Records  The database records of the distributed data base are called resource records (RR)  Resource records are stored in configuration files (zone files) at name servers.

30 30 Resource Record Types  (Name, Value, Type, TTL)  Type=A, name=hostname, value=IPv4 address  Type=AAAA, name=hostname, value=IPv6 address  Type=NS, name=domain value=hostname of authoritative DNS server nslookup –query=ns google.com  Type=CNAME, name=hostname, value=canonical host name (columbia.edu, ns1.columbia.edu, CNAME)  Type=MX, name=mail server hostname, value=canonical name of mail server  Type=PTR, name=address (IP), value=hostname  Type=SRV, name=service name, value=canonical hostname

31 31 Resource Records Max. age of cached data in seconds * Start of authority (SOA) record. Means: “This name server is authoritative for the zone Mylab.com” * PC4.mylab.com is the name server * hostmaster@mylab.com is the email address of the person in charge Name server (NS) record. One entry for each authoritative name server Address (A) records. One entry for each hostaddress Slave refresh time Slave retry time Slave expiration time Cache time for RR

32 32 DNS Summary  Domain name space  Domain and zone  Zone and resource record

33 33 DNS Example  nslookup google.com

34 34 DNS Example

35 35 DNS Example

36 36 DNS Example  Query 1  >nslookup google.com ns.google.com  Server: ns1.google.com  Address: 216.239.32.10  Name: google.com  Addresses: 64.233.167.99, 72.14.207.99, 64.233.187.99  Query 2  >nslookup google.com  Server: disco.cs.columbia.edu  Address: 128.59.16.7  Non-authoritative answer:  Name: google.com  Addresses: 64.233.187.99, 64.233.167.99, 72.14.207.99

37 37 Agenda  DNS history  DNS concepts  Recursive and iterative queries  Caching  Resource records  mDNS  King tool

38 38 mDNS  Multicast DNS (mDNS) name-to-address translation on a local network Multicast address: 224.0.0.251  Self-assigned local name It only has significance on the local network..local. Subdomain Name conflict resolution Default name:.local, SALMAN_PDA.local MDNS: Standard query ANY SALMAN_PDA.local MDNS: Standard query response A 169.254.18.87 PTR SALMAN_PDA.local SALMAN_PDA.local

39 39 King Tool How to estimate latency between two arbitrary hosts accurately? A B C C can measure latency between A and B Source: King tool slides by Krishna Gummadi

40 40 King: A Latency Measurement Tool  Estimate latency between arbitrary end hosts  Requires no additional infrastructure leverages existing DNS infrastructure enabling a large fraction of Internet hosts to be measured  Provides highly accurate latency estimates  Fast and light-weight requires only a few DNS queries per estimate We hope that King will be used in many unanticipated ways like in the case of Ping and Traceroute

41 41 Name Server near Host A Name Server near Host B Host BHost A Actual Latency Between End Hosts Latency Estimated By King How King Works: The Basic Idea  Challenge 1: How to find name servers that are close to end hosts  Challenge 2: How to estimate latency between two name servers

42 42 Challenge 2: How do we estimate the latency between name servers? Our Client C (King) Name Server B foo.bar Name Server A 1. Request Q: Resolve xyz.foo.bar 4. Reply Q (Forwarded) 2. Request Q (Forwarded) 3. Reply Q: IP addr of xyz.foo.bar

43 43 Success of Recursive DNS  For King to work, name servers must support recursive queries in a large random sample, > 75% of name servers supported recursion translates to > 90% success rate given a pair  as we can measure from A->B, or B->A

44 44 Example  Estimating latency between MIT and google.com  salman@irtcluster05:~$ time nslookup mit.edu bitsy.mit.edu  Server: bitsy.mit.edu  Address: 18.72.0.3#53  Name: mit.edu  Address: 18.7.22.69  real 0m0.013s  user 0m0.000s  sys 0m0.008s  salman@irtcluster05:~$  salman@irtcluster05:~$ time nslookup x.google.com bitsy.mit.edu  Server: bitsy.mit.edu  Address: 18.72.0.3#53  ** server can't find x.google.com.columbia.edu: NXDOMAIN  real 0m0.061s  user 0m0.000s  sys 0m0.008s


Download ppt "COMS/CSEE 4140 Networking Laboratory Lecture 09 Salman Abdul Baset Spring 2008."

Similar presentations


Ads by Google