BAI513 - PROTOCOLS DNS BAIST – Network Management

BAI513 - PROTOCOLS

DNS

BAIST – Network Management

Objectives Understand the types of services that

DNS provides

Explain the structure and layout of the domain name hierarchy and the DNS namespace

Understand how DNS servers handle name resolution requests, including the role of nearby and root servers in the resolution process, and the difference between recursive and iterative name resolutions requests

Objectives

Explain how DNS queries and responses work, and how they handle name resolution, and reverse DNS queries

DNS History and Background

Early methods for resolving symbolic names, such as microsoft.com and course.com, to numeric IP addresses relied completely on static text files, called HOSTS

Paul Mockapetris created the original RFCs for DNS in response to this situation—namely RFCs 882 and 883—and in 1984, built the first reference implementations of DNS, which he named JEEVES

DNS History and Background Kevin Dunlap wrote another implementation of

DNS, called BIND (Berkeley Internet Name Domain), for BSD UNIX version 4.3 in 1988

DNS was designed as a distributed database of information about domain names and addresses

Individual portions of such databases are sometimes called database segments, meaning they include only a portion of the overall namespace that DNS can access for its clients

DNS History and Background DNS combines the following virtues:

– It allows local control over domain name database segments

– Data from all database segments is available everywhere

– Database information is robust and highly available.

DNS History and Background

By caching DNS data from one or more database segments on one or more DNS servers, DNS also provides a mechanism whereby it can attempt to satisfy name resolution requests locally before attempting them remotely, thereby greatly improving the speed of such name resolution

Although DNS was designed over 15 years ago, and has been subject to various enhancements and improvements, it still represents one of the most effective uses of distributed database technology in the world today

DNS Database Structure The structure of the DNS database mirrors the

structure of the domain namespace itself Beneath the root, you find the top-level or

primary domains In the United States, these top-level domains

usually take the form of the following three-letter code:– .com– .edu– .gov– .mil– .net– .org

Tree Diagram of the IBM Domain Name

houns54.clearlake.ibm.com

DNS Database Structure This can best be understood as a tree structure

(actually, it’s an inverted tree because the root is usually drawn at the top of such a figure)

When you examine record data in DNS database files, you should understand that this final period is important when constructing fully qualified domain names (FQDNs)

In fact, an FQDN consists of all elements of a domain name, in which each is followed by a period, and the final period stands for the root of the DNS hierarchy itself

A DNS Overview Domains can be broken into subdomains as

needed

This permits local control over database segments; in essence, it’s a form of delegations of authority

By pushing custodianship of database segments far enough down into the domain hierarchy, local administrative groups can take responsibility for all the names and addresses that they must manage

Delegating DNS Authority Some domains are simply too big and too

complex to reside in a single database container

That’s the primary reason why DNS permits the database record for the primary DNS server for ibm.com to delegate authority for various subdomains to DNS servers lower in the domain namespace

Actually, such delegations of authority translates into assignment of authority for subdomains to different domain name server, usually at various locations within an organization’s overall scope and geographical layout

The Client Side of DNS Ultimately, requests for address translations and

other DNS services originate from a network client The piece of software that accesses DNS name

servers is called a name resolver, or just a resolver Resolvers issue requests for service, called name

queries or address requests, to domain name servers

A name query seeks to resolve an address to a domain name, also known as an inverse DNS query or reverse DNS lookup, and an address request seeks to resolve a domain name to a corresponding numeric IP address

The Client Side of DNS Resolvers also interpret responses from the

name servers that they query, regardless of whether those responses contain resource record data or error messages

Such errors may stem from any of the following causes, among others:

– Invalid domain name / IP address

– Inability to locate an IP address that corresponds to the requested domain name

– Inability to reach an authoritative name server for the requested domain

How DNS Servers Work

The process by which the queried domain name server replies works as follows:

– DNS servers retrieve name data from the general domain namespace

– Any given DNS server can always provide data about zones for which that server is authoritative

– Any given DNS server can search its cached domain name data and answer queries for which that server is not authoritative

How DNS Servers Work– When a local server does not have the information

available in its database or its name cache, it may turn to a caching-only server or to other known name servers in the “neighborhood”

– If none of these searches produces a result, the name server sends a request for name resolution to a root server, which directs the query to the authoritative server for the database segment in question by contacting the root server for the domain

This process is known as domain name resolution, or name resolution

DNS Root-Level Servers The real process is actually a bit more complex,

so first we will explain some related terminology:– Recursive query: Most DNS resolvers issue what is

called a recursive query from the client side. This means that they delegate the first DNS server that they contact to go out and find the necessary address translation on their behalf

– Iterative or non-recursive queries: When one DNS server receives a recursive request, that DNS server issues what are called iterative queries, or non-recursive queries, to the name servers in its hierarchy, or to servers provided as pointers in reply to earlier iterative requests, until an answer is received

Standard DNS Query Format

DNS Query/Response Packet Formats

DNS response packets include the original question as well as the reply

There are four sections in the DNS response packets:

– Question section

– Answer section

– Authority section

– Additional section

DNS Responses Include the Question in the Reply


ID Number Field

The 2-byte ID Number field is used to associate DNS queries with their responses

QR (Query/Response) Field

This 1-bit field indicates whether this is a DNS query (set to zero) or a DNS response (set to one)

Opcode (Operation Code) Field

This 4-bit field defines the type of query that is contained in this message


AA (Authoritative Answer) Field This bit is only valid in responses

TC (Truncation) Field This is typically seen only in responses This bit indicates that the response was truncated because

it was too large to fit in the data portion of the packet


RD (Recursion Desired) Field This bit indicates that the client requests a recursive

query if the target name server does not contain the information requested

RA (Recursion Available) Field This bit is valid in the response, and indicates whether

the responding name server supports recursive queries

Z (Reserved) Field Although RFC 1035 defines this field as “reserved” and

states that the field should be set to all zeroes, some DNS advancements extended the Rcode field into the Reserved field area


Rcode (Response Code) Field This 4-bit field is used in DNS responses

to indicate if any errors occurred

Question Count Field This field indicates the number of entries

contained in the question section

Answer Count Field This field indicates the number of RRs

contained in the answer section

Response Code Field Values


Name Server Count Field This field indicates the number of name

server RRs in the authority records section

Additional Records Field This field indicates the number of other RRs

contained in the additional records section

Question Name Field This variable-length field consists of a series

of length fields followed by some octets of data


Question Type Field This 2-byte field indicates the type of the

query The values possible are defined in the

table on the following slide

Question Type Values


Question Class Field This 2-byte field indicates the class for the

query The value one indicates Internet class

Name Field This field contains the domain name to

which this RR belongs When compression is used, the leading

bits in this field must be 11 (binary)

Redundancy in a DNS Reply


Type Field This 2-byte type field is the RR type code for data

contained in the Resource Data field of the response

Class Field This 2-byte field specifies the class of the data

contained in the Resource Data field

Time to Live Field This 4-byte field indicates how long the data

contained in the Resource Data field should be cached before it is discarded


Resource Data Length Field

This 2-byte field indicates the length of the Resource Data field

Resource Data Field

This variable-length field contains the resource information itself, and in some ways may be said to contain the real “payload” of the RR

DNS Implementation

DNS implementations in the real world have two major purposes

One is providing name resolution to your users so they can reach the services provided by the rest of the world, and the other is providing the authoritative hostname-to-IP mapping so that the rest of the world can reach any services you choose to provide, such as a Web server, e-mail server, and perhaps an FTP server

The Trouble with DNS

Despite DNS’ stout capabilities and its many advantages, it does suffer from some short-comings

Chief among these is that DNS database updates normally require that a qualified administrator—one with the proper knowledge and necessary access rights to the zone files—operate directly on the DNS database files, or use special-purpose tools (such as NSUPDATE in the UNIX environment) to make changes

The Trouble with DNS

Another problem to which DNS falls

prey might be called “propagation

delay,” which relates to the amount of

time it takes for cached values to

catch up with changes to authoritative

databases once changes are made to

those “master copies” of DNS records

Summary Because it provides the essential way to get

from a symbolic, human-readable domain name for an Internet location to a corresponding numeric, machine-readable IP address, the Domain Name System provides the key address resolution service that makes today’s Internet possible

The impetus for DNS arose from the difficulty of maintaining static HOSTS files for computers on the ARPANET after the number of hosts climbed into the thousands

Summary

DNS maintains its data on a large collection of name servers around the Internet by carving the domain namespace into a disjoined collection of domain or subdomain databases, also known as database segments, or database zones, each of which belongs to a single authoritative name server for that zone

Summary

DNS clients rely on a software component called a resolver to interact with an available DNS server for name resolution services

DNS packet structures incorporate type information that identifies the kind of RR being carried, and that otherwise describes the record’s contents and validity

Documents

BAI513 - PROTOCOLS DNS BAIST – Network Management