DNS-domain name system

(DNS-domain name system) programs seldom confer with hosts, mailboxes, and different resources by their binary network addresses. instead of binary numbers, they use ASCII strings, such as tana@art.ucsd.edu. Nevertheless, the network itself only understands binary addresses, so this mechanism is needed to convert the computer code strings to network addresses. In the following sections, we will study how this mapping is accomplished on the Internet. Way back within the ARPANET, there was simply a file hosts.txt, that listed all. 

the hosts and their Ip addresses. Every night, all the hosts would fetch it from the site at which it was maintained. fora network.of a few hundred large timesharing machines, this approach worked reasonably well. However, when thousands of workstations were connected to the net, everyone realized that this approach could not continue to work forever. for one thing, the size of the file would become overlarge. However, even more important, hostname conflicts would occur constantly unless names were centrally managed, something unthinkable in a huge international network.to solve these problems, DNS (the Domain Name System)was invented.(DNS-domain name system)

The essence of DNS is that the invention of a stratified,domain-based naming scheme and a distributed database system for implementing this naming scheme. it is primarily used for mapping hostnames and email destinations to informatics addresses but can also be used for other purposes.DNS is defined in RFCs 1034 and 1035. Very, in short, the way DNS is used is as follows. To map a name onto an IP address, and applications program calls a library procedure known as the resolver, passing it the name as a parameter. The resolver sends a UDP packet to an area DNS server, which then appearance up the name and returns the informatics address to the resolver, which then returns it to the caller. armed with the IP address, the program can then establish a TCP connection with the destination, or send it UDP PACKETS.

The DNS Name Space

Managing a large and constantly changing set of names is a nontrivial problem. In the postal system, name management is done by requiring letters to specify ( simplicity or explicitly )(DNS-domain name system) the country, state or province, city, and street address of the addressee. By using this kind of hierarchical addressing, there is no confusion between the Marvin Anderson on Main St. in white plains, N.Y. and the Marvin Anderson on main st. in Austin, Texas. DNS works the same way.

Conceptually, the internet is divided into several hundred top-level domains, where each domain covers many hosts. Each domain is partitioned into subdomains, and these are further partitioned, and so on. all these domains can be represented by a tree, as shown in fig 7-25. the leaves of the tree represent domains that have no subdomains (but do contain machines,of course)A leaf domain may contain a single host or it may represent a company and contains thousands of hosts.

The top_level domains come in two flavors: generic and countries.The generic domains are com (commercial),edu(educational institutions),gov(the U.S.federal government),int(certain international organizations),mil (the U.S.armed forces),net(network providers),and org (nonprofit organizations).the country domains include one entry for every country as defined in ISO 3166.(DNS-domain name system)

Each domain is named by the path upward from it to the (unnamed)root.The components are separated by periods (pronounced “dot”). Thus Sun Microsys_tems engineering department might be eng.sun com, rather than a UNIX_style name such as /com/sun’eng. Notice that this hierarchical naming means that eng. sun com does not conflict with the potential use of eng in eng .yale.edu., which might be used by the Yale English department. Domain names are case insensitive, so edu and EDU mean the same thing. Component names can be up 63 characters long and full path names must not exceed 255 characters.

(DNS-domain name system) In principle, domains can be inserted into the tree in tow different ways. for example, cs.yale.edu could equally well be listed under us country domain as cs.yale.ct.us.in practice, however, nearly all organizations in the United States are under a generic domain, and nearly all outside the united states are under the domain of their country. there is no rule against registering under two top-level domains, but doing so might be confusing, so few organizations do it. Each domain controls how it allocates the domains under it. For example, Japan has domains ac.jp and co.jp that mirror edu and com. The Netherlands does not make this distinction and puts all organizations directly under nl. Thus all three of the following are university computer science departments.

           1.cs.yale.edu(Yale University, in the United States )

           2.cs.vu.nl (Vrije University, in The Netherlands)

           3.cs.keio.ac.jp(Keio University,in Japan)

To create a new domain, permission is required to the domain in which it will be included. For example, if a VLSI group is stated at Yele and wants to be known as vlsi.cs.yale.edu, it needs permission from whoever manages cs.yale.edu. Similarly, if a new university is chartered. say, the University of Northern South Dakota, it must ask the manager of the edu domain to assign it unsd.edu. In this way, name conflicts are avoided and each domain can keep track of all its subdomains. Once a new domain has been created and registered, it can create subdomains, such as cs.unsd.edu, without getting permission from anybody higher up the tree.

   The naming follows an organization’s boundaries, not physical networks. For example, if the computer science and electrical engineering department are located in the same building and share the same LAN, they can nevertheless have a distinct domain. Similarly, even if computer science is split over Babbage Hall and Tur-ing Hall, all the hosts in both buildings will normally belong to the same domain. 

Resource Records

Every domain, whether it is a single host or a top-level domain, can have a set of resource records associated with it. For a single host, the most common resource record is just its IP address, but many other kinds of resource records also exist When a resolver gives a domain name to DNS, what it gets back are the resource records associated with that name Thus the real function of DNS i to map domain names on resource records A resource record is a five-tuple. Although they are encoded in binary for efficiency, in most expositions resource records are presented as ASCII text, one line per resource record. The format we will use is as follows: Domain name Time to live Type Class Value The Domain name tells the domain to which this record applies. Normally.(DNS-domain name system) mam records exist for each domain and each copy of the database holds information ut multiple domains This field is thus the primary earth key used to say weed. The order of the records in the database is not significant. When a que I made about a domain all the matching records of the class requested are retail The Timeline In field gives an indication of how stable the record is Information that is highly stable is assigned a large value, such as 86400 (the number of seconds in 1 day). Information that is highly volatile is assigned a small value such as 60 (1 minute). We will come back to this point later when we have discussed caching The Type field tells what kind of record this is. The most important types are listed in.

An SOA record provides the name of the primary source of information about the name server’s zone described below the email address of its administrator, a unique serial number, and various mags and timeouts. The most important record type is the A (Addres:) record. It holds a 32-bit IP address for the same host. Every Internet host must have at least one IP address, so Other machines can communicate with it. Some hosts have two or more network connections, in which case diy will have one type 1 resource record per network convection (and thus per IP address). The next most important record type is the MX record. It specifies the name of the domain prepared to accept email for the specified domain.

(DNS-domain name system) A common use of this record i Bowmachine that is not on the Internet to receive email from Internet sites. Delivery is accomplished by having the non-Internet site make an arrangement with some Internet site to accept email to it and forward it using whatever protocol the two of them agree on For example, suppose that Cathy is a computer science graduate student at UCLA. After she gets her degree in Al, she sets up a company, Electrobrain Common to commercialize near des She cannot at and internet connect angel shoes mantra me allow her in nave net email sent the times a day she will call op and collect the Net Weather met the com domain and is assumed the domain electrobrain.com She might then the administrator of the com domain to update an A record to the com database as follows

electrobrain.com        B6400      IN      MX       1        mailserver.cs.ucla.edu

In this way, mail will be forwarded UCLA where she can pick it up by logging THE Alternatively, LICLA could call her and transfer tie entail by any protocol they mutually great The records specify name servers For example, every DNS database nor mally huku NS record for each of the top-level domains, so email can be sent to distant parts of the morning tree. We will come back to this point later CNAME records allow aliases to be created. For example, a person familiar with Internet naming in general, waiting to send message to someone who login name is paul in the computer science department at M.LT might guess that paulecmit.edu will work Actually tus address will not work because of the domain for MITS.computer science department is ies.mit.edu. However, as a service to people who do not know this, M.IT could create a CNAME entry to point people and programs in the right direction. An entry like this one might do the job

Cs.mit.edu     86400     IN       CNAME lcs.mit.edu

Like CNAME, PIR points to another name However, unlike CNAME, which i really just a macro definition. PTR is a regular DNS datatype whose interpret in depends on the context in which is found in practice it is nearly always used to associate a nine with an IP address to allow lookups of the IP address and return the name of the corresponding machine HINFO records allow people to find out what kind of machine and operating system a domain corresponds to Finally, TXT records allow domains to identify themselves in arbitrary wavs. Both of these record types are for user convenience. Neither is required, so programs cannot count on getting them and probably can not deal with them if they do get them). Getting back to the general structure of resource records,(DNS-domain name system) the fourth field of every resource record is the Class For Internet information, it is always IN. For ton-Internet information, other codes can be used Finally. we come to the value field. This field can be a number, a domain name, or an ASCII string The semantics depend on the record type. A short Fig. 7-26 description of the Value fields for each of the principal records types is given in As an example of the kind of information, one might find in the DNS database of the domain. see Fig. 7-27 This figure depicts part of a ( semihypothetical ) database for the cay NL domain shown in Fig: 7-25, Theidatahase contains seven types of resource records.

The first uncomment line of Fig. 7-27 gives some basie information about the domain, which will not concern us further. The next two lines give textual information about where the domain is located. Then come two entries giving the first and second places to try to deliver email sent to person @es. vu.nl. The zephyr (a specific machine) should be tried first. If that fails, the top should be tried next. After the blank line, added for readability, come lines telling that the flies is a Sun workstation running UNIX and giving both of its IP addresses. Then three choices are given for handling email sent to flits.cs.vu.ni. The first choice is naturally the flits itself, but if it is down, the zephyr and top are the second and third choices. Next comes an alias, www.cs.V.nl , so that this address can be used without designating a specific machine. Creating this alias allows es.vu.nl to change its World Wide Web server without invalidating the address people use to get to it. A similar argument holds for fip.cs.vu.nl.(DNS-domain name system) The next four lines contain a typical entry for a workstation, in this case, rowboat.cs.vu.nl. The information provided contains the IP address, the primary and secondary mail drops, and information about the machine. Then comes an entry for a non-UNIX system that is not capable of receiving mail itself, followed by an entry for a laser printer. What is not shown (and is not in this file), are the IP addresses to use to look up the top level domains. These are needed to look up distant hosts, but since they are not part of the cs.vu.nl domain, they are not in this file. They are sup- plied by the root servers, whose IP addresses are present in a system configuration file and loaded into the DNS cache when the DNS server is booted. They have very long timeouts, so once loaded, they are never purged from the cache.

Name Servers

In theory at least, a single name server could contain the entire DNS database and respond to all queries about it. In practice, this server would be so overloaded as to be useless. Furthermore, if it ever went down, the entire Internet would be crippled. To avoid the problems associated with having only a single source of information, the DNS name space is divided up into nonoverlapping zones.One possible way to divide up the name space of Fig. 7-25 is shown in Fig. 7-28. Each zone contains some part of the tree and also contains name servers holding the authortative information about that zone. Normally, a zone will have one primary name server, which gets its information from a file on its disk, and one or more secondary name servers, which get their information from the primary name server. To improve reliability, some servers for a zone can be located outside the zone.

Where the zone boundaries are placed within a zone is up to that zone’s administrator. This decision is made in large part based on how many name servers are desired, and where. For example, in Fig. 7-28, Yale has a server for vale.edu that handles eng.yale.edu but not cs.yale.edu, which is a separate zone with its own name servers. Such a decision might be made when a department such as English does not wish to run its own name server, but a department such as computer science does. Consequently, cs.yale.edu is a separate zone but eng.yale.edu is not. When a resolver has a query about a domain name, it passes the query to one of the local name servers.(DNS-domain name system) If the domain being sought falls under the jurisdiction of the name server, such as ai.cs.yale.edu falling under cs.yale.edu, it returns the authoritative resource records. An authoritative record is one that comes from the authority that manages the record, and is thus always correct. Authoritative records are in contrast to cached records, which may be out of date. If, however, the domain is remote and no information about the requested domain is available locally, the name server sends a query message to the top level name server for the domain requested. To make this process clearer, consider the example of Fig. 7-29. Here, a resolver on flits.cs.vu.nl wants to know the IP address of the host linda.cs.yale.edu. In step ! it sends a query to the local name server, cs.vu.nl. This query contains the domain name sought, the type (A) and the class (IN).

Let us suppose the local name server has never had a query for this domain before and knows nothing about it. It may ask a few other nearby name servers. but if none of them know, it sends a UDP packet to the server for edu given in its database (see Fig. 7-29), edu-server.net. It is unlikely that this server knows the address of linda.cs.yale.edu. and probably does not know cs. yale.edu either, but it must know all of its own children, so it forwards the request to the name server for yale.edu (step 3). In turn, this one forwards the request to cs.yale.edu (step 4). which must have the authoritative resource records. Since each request is from a client to a server, the resource record requested works its way back in steps 5 through 8. Once these records get back to the cs.vu.nl name server, they will be entered into a cache there, in case they are needed later. However, this information is not authoritative, since changes made at cs.yale.edu will not be propagated to all the caches in the world that may know about it. For this reason, cache entries should not live too long. This is the reason that the Time_to_live field is included in each resource record.

It tells remote name servers how long to cache records. if a certain machine has had the same IP address for years, it may be safe to cache that information for 1 day. For more volatile information, it might be safer to purge the records after a few seconds or a minute. It is worth mentioning that the query method described here is known as a recursive query, since each server that does not have the requested information goes and finds it somewhere, then reports back. An alternative form is also possible. In this form, when a query cannot be satisfied locally, the query fails, but the name of the next server along the line to try is returned. This procedure gives the client more control over the search process. Some servers do not implement recursive queries and always return the name of the next server to try. It is also worth pointing out that when a DNS client fails to get a response before its timer goes off, it normally will try another server next time. The assumption here is that the server is probably down. rather than the request or reply got lost.

Fore Know More

HOME