cmpt 471 networking ii n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CMPT 471 Networking II PowerPoint Presentation
Download Presentation
CMPT 471 Networking II

Loading in 2 Seconds...

  share
play fullscreen
1 / 31
peyton

CMPT 471 Networking II - PowerPoint PPT Presentation

174 Views
Download Presentation
CMPT 471 Networking II
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. CMPT 471Networking II DNS

  2. DNS • The primary use of DNS is to answer queries requesting the IP address that corresponds to a given host name.

  3. Operation of a DNS server • A DNS name server is initialized, knowing the addresses of the root servers, knowing the addresses of some other servers, or with the zone data files for one or more zones. • As queries are made the information received from the queries is added to a cache. • Entries generally have a long (hours to days) lifetime. • Lifetime (TTL) is set by administrator when configuring the server, or reset by the administrator at a later time • Shorter lifetime keeps information up to date but causes increased load of queries to the DNS server • When further queries are made the cache is checked before queries are transmitted

  4. Caching • Each time a DNS query is made by the DNS server, the information in the response is cached • This cached information can be used to improve the efficiency of later queries to the DNS server • See the example at the end of the notes for this lecture

  5. DNS • There are two approaches to answering a query • Iterative: the name server receiving the query responds with either the IP address of the host or the name of the next server it would consult (next higher server in the tree) • Recursive: the name server will, if necessary, directly query the next name server, and will return the final answer

  6. Submitting a query from a host • A host Drab, in domain cs.sfu.ca requests IP address for ftp.isc.org • Drab expects to receive the IP address of ftp.isc.org without making additional queries. • The resolver (resolving software such as dig) on Drab it is making a recursive request that requires the local DNS server (seymour) to • Make an additional request or requests. • Analyze the reply or replies to the request/s • Supply the resulting IP address and potentially other related information to DRAB.

  7. Query from the local DNS server • The DNS server must then determine the desired IP address. It will make a series of iterative requests for information on the address of ftp.isc.org. (This example assumes the DNS server has not recently resolved a .org address and does not have cached information on these addresses) • The DNS server, seymour, will send a request to one of the root servers. The longest match the root server can make will be to the TLD .org (because .org has been delegated) • The root server will send back a response with the IP address and name of an authoritative server for the .org domain (plus other information)

  8. Query from the local DNS server: 2 • The DNS server’s resolving software will process the returned data, add the DNS server for the .org domain to the cache, and formulate a request to the DNS server for the .org domain • The local DNS server will send a request to one of the DNS servers for the domain .org • The DNS server for the domain .org will send back a response with the IP address and name (plus other information) of an authoritative server for the isc.org domain. The isc.org domain has been delegated by the .org DNS server to the ISC, so no longer domain name match can be made.

  9. Query from the local DNS server: 3 • The local DNS server’s resolver will process the returned data, add the DNS server for the isc.org domain to the cache, and formulate a request to the DNS server for the isc.org domain • The local DNS server’s resolver will send a request to one of the DNS servers for the domain isc.org • The DNS server for the domain isc.org will send back a response with the IP address and name (plus other information) of ftp.isc.org. • The local DNS server’s resolver will process the returned data, • add an entry for the ftp.isc.org to the cache • formulate a reply to the original request from host Drab

  10. Seymour Root DNS server Referred to .org DNS server for .org Referred to isc.org DNS server for isc.org IP Address of ftp.isc.org Recursive query Recursive reply Iterative query Drab DNS Query all queries/replies are for the address of ftp.isc.org

  11. Recursive Requests • In the example above the resolver on the host made a recursive request, and the DNS server made only iterative requests. • DNS servers can also make recursive requests. However, busy DNS servers are often configured to accept only iterative requests. (this way they do not need to process the returning results as well, this reduces load on the busy server). Therefore, the iterative approach is more commonly used by DNS servers

  12. DNS Server Root DNS server . Queries .gov. Replies to . DNS server for .gov. Queries nasa.gov. Replies to .gov. DNS server for nasa.gov. IP Address of jpl.nasa.gov. Recursive query Recursive reply Recursive query Querying host All queries/replies are for the address of jpl.nasa.gov. Recursive queries

  13. Using the Cache: subsequent queries • A later query to ftp.isc.org will find the IP address available in the local DNS servers cache. The DNS server will send back the results without making further queries • A later query to ftp2.isc.org will find the entry for isc.org DNS server in the cache of the local DNS server. A single query to the isc.org DNS server will provide the needed information

  14. Using the Cache: subsequent queries • A later query to qu.openoffice.org will find the entry for .org DNS server in the cache of the local DNS server. Two queries to the .org and the openoffice.org DNS servers respectively will provide the required information. There is no need to contact the root server

  15. Making direct queries • Use dig or host (or nslookup) • nslookup has been superceded. It may be removed from further releases so it is best to become familiar with dig and host • Please become familiar with using dig and host. You should understand usage for both basic lookup of IP address or name and for obtaining more complete information

  16. A number of applications can generate DNS requests. These include telnet, email applications and any client application that identifies the server by name rather than IP address Any client or server that calls gethostbyname() or gethostbyaddr() will use the DNS name resolver to determine the IP address of the host Other DNS queries generated

  17. Domain Server Message • Messages exchanged between clients and servers Comer 2000: fig 24.5

  18. Contents of message fields • The identification field contains an identifier assigned by the program generating the query. It is used to match response to query • See next slide. A query type of 2 is now used for a server status request, recursion requested bit used in request, recursion available bit used in response. Response type of 5 server refused to perform requested operation (operation not permitted due to security settings of server) • The counts give the number of records in the corresponding section. But what do each of the records contain?

  19. The Parameter Field Comer 2000: fig 24.6

  20. Authoritative Responses • An authoritative response is an answer that comes from the DNS server responsible for the zone containing the domain name being queried. • The local DNS server will cache results from each external query • If an additional query for the same address is made soon after the first, the results will be found in the cache of the DNS server. No contact will have been made with the authoritative server. • The received response is not from the authoritative server and may be labelled as an non-authoritative response

  21. Example using nslookup jregan3: nslookup jpl.nasa.gov. Server: 199.60.1.1 Address: 199.60.1.1#53 Name: jpl.nasa.gov Address: 137.78.160.180 jregan4: nslookup jpl.nasa.gov. Server: 199.60.1.1 Address: 199.60.1.1#53 Non-authoritative answer: Name: jpl.nasa.gov Address: 137.78.160.180

  22. Query class, usually IN to indicate internet, or 255 to indicate any class Query type, there are many types, see RFC 1035 for a complete list, Query types are a superset of types used for all resource records such as A an address, NS an authoritative name server, SOA (start of authority), MX mail exchange, CNAME canonical name Query type also includes additional types like AXFR to transfer all data for a zone Question section record Comer 2000: fig 24.7

  23. Query / resource domain name • “Domain names in messages are of variable length and are expressed in terms of a sequence of labels. • Each label is one segment of the domain name (characters between two .’s ) • Each label is represented as a one octet length field followed by that number of octets of name. • Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. • The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less” From RFC 1035 • Compressed name format: can replace a label with a pointer to an earlier occurrence of that label

  24. Records in other sections Comer 2000: fig 23.8

  25. Records in other sectionsAnswer, Authority, Additional • The resource domain name has the same format as the query domain name discussed above • Type contains a code indicating the type of resource record, a complete list is given in RFC 1035. The type will determine the amount and format of data in the resource data area (see Query Type for examples) • Class (same definition as query, 255 not used) • TTL (time to live) the time interval in seconds for which the resource record may be cached. 0 means use only for the current transaction. • Resource data length: number of octets of resource data

  26. Example using dig: 1 jregan15: dig ftp.isc.org ; <<>> DiG 9.2.1 <<>> ftp.isc.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33180 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5 ;; QUESTION SECTION: ;ftp.isc.org. IN A ;; ANSWER SECTION: ftp.isc.org. 2898 IN A 204.152.184.110 ;; AUTHORITY SECTION: isc.org. 2898 IN NS ns-ext.lga1.isc.org. isc.org. 2898 IN NS ns-ext.nrt1.isc.org. isc.org. 2898 IN NS ns-ext.sth1.isc.org. isc.org. 2898 IN NS ns-ext.isc.org.

  27. Example using dig: 2 ;; ADDITIONAL SECTION: ns-ext.lga1.isc.org. 75012 IN A 192.228.91.19 ns-ext.nrt1.isc.org. 75012 IN A 192.228.90.19 ns-ext.sth1.isc.org. 75012 IN A 192.228.89.19 ns-ext.isc.org. 29497 IN A 204.152.184.64 ns-ext.isc.org. 155246 IN AAAA 2001:4f8:0:2::13 ;; Query time: 1 msec ;; SERVER: 199.60.1.1#53(199.60.1.1) ;; WHEN: Fri Nov 5 06:21:09 2004 ;; MSG SIZE rcvd: 236

  28. Knowing where to look • Dig and other applications that need to look up DNS information must know where to go to find or ask for the information • The list of locations to look (on a linux system) can be found in /etc/resolv.conf. The locations will be queried in the order given • /etc/resolv.conf Will look something like search cs.sfu.ca css.sfu.ca ensc.sfu.ca math.sfu.ca nameserver 199.60.1.1 nameserver 142.58.103.1 nameserver 142.58.103.2

  29. resolv.conf: search • search followed by a series of domain names (defaults are generated, in addition you can set the list yourself in versions 4.9 and later) • If a query for the address of draconis is made, since draconis is not fully qualified it will not be found • Then the resolver will append the first domain name in the search list (usually the domain of the host making the request.) to the requested name, and then make a request for then if the query for draconis.cs.sfu.ca. That request will produce a result • If that request did not produce a result the resolver would make requests for draconis with each of the domain names in the search list (in the same order as the list is given) and would stop if and when one of those requests produced a match

  30. nameserver followed by the IP address of a DNS server Up to three nameservers can be specified. If the first cannot be contacted the second will be tried. If the first two are unavailable the third will be tried Options followed by a list of options Can turn on debug option debug Can set the maximum number of attempts to make before you assume a nameserver is unavailable option attempts:4 Numerous other options are available Other content: resolv.conf

  31. Database / authoritative servers • When a authoritative master or slave DNS server is initialized it loads a configuration file which associates domain names with data files containing DNS resource records for that domain • For linux systems that file is usually /etc/named.conf, configuration for the DNS daemon named. This file will be present only on hosts running DNS servers • Next we need to look at what is in the files referred to in the configuration file. There will be one file for each domain this DNS server serves.