1. Resolution which is having three types
a.Forward
b.Reverse (in-addr.arpa)
c.Round Robin
2.Delegation
3.Caching
4.Zone Transfers
Resolution
Resolution is the process of turning a name into an IP address or an IP address back into a name. The process begins with asking the root servers which nameserver to ask about the domain name that is being resolved. The root nameservers will refer you to another name server which will refer you to another name server and so on. Finally you will be refered to the nameserver which is authoritative for the domain name. The authoritative server will look in its zone files and respond with an answer.
DELEGATION
Delegation is the process of distributing the responsibility for resolving names or IP addresses across multiple DNS servers maintained by different organizations. The delegation process is how DNS names, domain names, are resolved.
FORWARD vs. REVERSE
When the process turns a name into an IP address, it is referred to as forward resolution. When an IP address is resolved back into a name the process is called reverse resolution.
RESOLUTION
The Domain Name System (DNS) is designed to resolve host names into IP addresses. The process of resolving names into IP addresses is called 'forward resolution'. The DNS tree is organized into an upside down tree structure with the least specific portions of the address at the top, and the most specific part of the address at the bottom.
Step by step, here is how this address is resolved (refer to the diagram above when needed):
1. A user on another network types in eos.cs.berkeley.edu on his local machine.
2. The Resolver built into the application he is using sends out a 'recursive resolution request' to the local DNS server.
3. The Local DNS server checks it's own database. If it finds an answer, it responds with the IP address.
4. If it does not find an answer in it's own database, it queries the Root DNS servers (currently at InterNIC).
5. The Root DNS server checks it's database and finds the names and addresses of the nameservers at Berkeley.
6. The Root DNS server sends back the names/addresses of all the Berkeley nameservers it has in its databse as a 'delegated referral'.
7. The local DNS server randomly picks a Berkeley nameserver and queries it. This random choice spreads out the load of successive requests across several machines.
8. The Berkeley nameserver queried checks it's database and finds it has delegated the cs.berkeley.edu domain to a nameserver on the Computer Science network.
9. The Berekeley.edu DNS server sends back the names/addresses of all the cs.berkeley.edu nameservers it has in its databse as a 'delegated referral'.
10. The user's local DNS server randomly chooses one of the cs.berkeley.edu servers and then queries that nameserver for the host 'eos'.
11. The cs.berkeley.edu nameserver responds with an authoritative answer for the IP address of EOS.
12. The local user's machine now opens a TCP connection to the IP address of the machine EOS.
This resolution process can take up to two minutes, but it distributes the load of resolution across several machines, and allows local network administrators to have direct control over the resolution responses for their network.
b.REVERSE RESOLUTION
Reverse Records (in-addr.arpa)
There are circumstances where it is necessary to translate an IP address back into the name of the device. This is especially useful in the traceroute application allowing the user to see the names of the machines through which packets are flowing instead of raw (and unrecognizable) IP addresses.
Reverse DNS resolution is performed the same way forward resolution is performed, except that the IP addresses and names are in opposite places. You can think of the computer storing everything in an upside-down tree-like structure with the top level domain at the top and the second and third level domains underneath it. For forward host name such as www.netscape.com, the .com is at the top, just under that is the .netscape part, and below that is the www part. Where the nameserver stores the www is also where it stores the IP address.
Reverse resolution is handled by placing it as a special branch off the root called .in-addr.arpa. This special branch allows for reverse resolution by placing names at the nodes corresponding with the IP address that is being resolved.
When looking up the IP address 192.234.42.5 the request is reformatted by the local resolver and sent to the nameserver as 5.42.234.192.in-addr.arpa. This looks like it's backwards, but if you look at the picture of the tree structure above, you can see that the name server stores the information in least-specific to most specific order. Resolution actually works better that way because the resolver begins with the least specific part of any name or address (.com in a name, and .in-addr.arpa in an IP address lookup) and works it's way to the most specific part (the www part of www.company.com in a name, and .5 of 192.234.42.5. What screws most people up is not knowing that IP addresses are actually backwards to start with. We're just putting them in the correct order when we do the lookup. ;-)
www . company . com
<== most specific least ==>
192 . 234 . 42 . 5
<== least specific most ==>
5 . 42 . 234 . 192 . in-addr . arpa
<== most specific least ==>
By the way, the 'in-addr' part simply means 'inverse address', and 'arpa' stands for ARPANET, which just goes to show you how old this process really is if you know what the ARPAnet is...
This 'backwards' way of representing things makes it possible for the programmers to be lazy and not have to write special logic or code to do reverse resolution. It's a strange workaround to the problem, but it works better because it uses the same steps as forward resolution would, and follows the same rules. This makes it's behavior predictable and logical because it doesn't differ greatly from forward lookups of domain names.
c.ROUND ROBIN DNS
The Berkeley Internet Name Daemon (BIND) has a function built in called round-robin resolution. The standard domain name resolution process starts when a client which makes a request to a resolver. It is the resolver's job to discover the best sources for DNS information and to choose the best and closest sources for information. Closeness is defined as being within the domain or one of the sub-domains that are members of the domain. A server whose fully qualified name is part of the domain will be preferred over a server which is not. When more than one record of a specific type exists, the BIND software will rotate the answers it provides. This provides load sharing functionality so that answers requested will come from different servers.
When requesting information from a DNS server it will provide a list of servers. If you immediately query the server a second time, the order of the servers listed will change. Not all servers perform the round robin DNS functionality, though Microsoft claims to support it by default.
FIRST QUERY
Note the order of the names of the nameservers is listed as ns1, ns2, ns3, ns4. That they are listed in alphabetical order is a coincidence in this query. The point is to look at the results from the second and third queries.
C:\Documents and Settings\johnp>nslookup
...
> google.com.
Server: [216.239.32.10]
Address: 216.239.32.10
> set norecurse
> set q=ns
> google.com.
Server: nameserver.inetdaemon.com
Address: 10.0.10.1
Non-authoritative answer:
google.com nameserver = ns1.google.com
google.com nameserver = ns2.google.com
google.com nameserver = ns3.google.com
google.com nameserver = ns4.google.com
ns1.google.com internet address = 216.239.32.10
ns2.google.com internet address = 216.239.34.10
ns3.google.com internet address = 216.239.36.10
ns4.google.com internet address = 216.239.38.10
SECOND QUERY
Notice that the order of the names of the nameservers listed has changed: ns3, ns4, ns1, ns2. What has happened is that at least one other query from someone else on the Internet was run since we ran our first query. Round robin would have handed us ns4, ns1, ns2, ns3.
> google.com.
Server: [216.239.32.10]
Address: 216.239.32.10
google.com nameserver = ns3.google.com
google.com nameserver = ns4.google.com
google.com nameserver = ns1.google.com
google.com nameserver = ns2.google.com
ns3.google.com internet address = 216.239.36.10
ns4.google.com internet address = 216.239.38.10
ns1.google.com internet address = 216.239.32.10
ns2.google.com internet address = 216.239.34.10
THIRD QUERY
Notice that the order of the names of the nameservers listed has changed again: ns4, ns1, ns2, ns3.
> google.com.
Server: [216.239.32.10]
Address: 216.239.32.10
google.com nameserver = ns4.google.com
google.com nameserver = ns1.google.com
google.com nameserver = ns2.google.com
google.com nameserver = ns3.google.com
ns4.google.com internet address = 216.239.38.10
ns1.google.com internet address = 216.239.32.10
ns2.google.com internet address = 216.239.34.10
ns3.google.com internet address = 216.239.36.10
>
SUMMARY
Note that the order of the servers listed changed between queries. As long as there are multiple resource records of the same type, the DNS server should rotate the answers listed. This rotation is referred to as round-robin. This rotation is completely deterministic, which means it does not rotate the list of servers based on load or the number of queries, but rather rotates the list the same way on every single query.
DELEGATION
Domain name resolution begins with a query to the Root Domain Servers (a.root-servers.net, b.root-servers.net etc.). To decrease the load on the root servers, two techniques were developed. The first was delegation, the second, caching.
Delegation is the process of referring DNS resolution requests to the Authoritative Server. For instance, InterNIC delegates berkeley.edu to the nameservers at the University of California at Berkeley. More properly, InterNIC delegates authority over the berkeley.edu domain to the University.
CACHING
Name servers and client resolvers store answers they get from other name servers. This information is added to their an internal database called the cache. Information about hosts is etained for a period of time equal to the time to live value sent by authoritative name server when it returned an answer about a particular host. The cache can contain both authoritative and non-authoritative information, depending on where the answer to the query for that particular host was provided from.
Storing these responses is called caching and allows a nameserver to respond more quickly to multiple queries for the same domain or host. If you are on a website, and want to retrieve the next page on the site, you click a link. Your web browser takes the name of the server, sends it to the the local name server to be turned into an IP address. Once your computer gets an answer, it does not have to look up the host again. Your local computer actually has its own DNS cache as well. Provided the time to live value hasn't expired, that answer will remain in the cache for some time. Once the time to live decays to zero the nameserver will delete the entries containing the host and address information. On your local computer, the cache is emptied when the local computer's default timeout is reached. This is an arbitrary value and is set to approximately 5 minutes on most Windows computers.
A standard DNS architecture will have a primary authoritative server that the DNS administrator configures with domain information in one or more zone files. This primary server will be registered with the domain registrar. This information should of course be backed up on a secondary (slave) server. Once the zone files download succesfully, the secondary server should respond authoritatively if queried. This provides fault tolerance, as well as load balancing of DNS resolution requests.
All that is necessary to configure on the secondary server is a list of domains for which the secondary is to be authoritative. This is done by configuring a list of zone file on the secondary server. When a secondary server is started it downloads these files from the primary DNS server. The secondary server is totally reliant upon the primary server. If the information is not on the primary server, it will never appear on the secondary.
A secondary server performs a 'zone transfer' to download zones from the primary server. When the expire time in the Start of Authority (SOA) resource record decays to zero the secondary server opens a TCP connection on port 53 to a primary server to download the zone file. The server will permit or deny the transfer request depending upon its configuration. This allows the secondary server to mimic the primary, and to contain a backup copy of all DNS information configured in various zone files on the Primary server.
The secondary server will not transfer (download) any zone that contains an error or unrecognized record types (such as WINS records, or records containing the underscore character). The secondary server will not transfer any zone that is not properly configured and does not list the secondary DNS server in the SOA record and where no name server (NS) record for the server doesn't exist.
BIND 8.0 and later contains an additional feature called dynamic update. Normally a zone transfer is initiated by the secondary server after refresh time set in the zone's SOA record has expired. A primary server running BIND 8.0 and later will send out a notification to all its configured secondary DNS servers whenever its zone files are modified and the version number has increased. This allows for faster updates between the secondary servers and the primary server.
Kishore
No comments:
Post a Comment