Ce document correspond à la copie cachée proposée par G o o g l e pour la page http://www.scit.wlv.ac.uk/~jphb/comms/dns.html . La « copie cachée » proposée par G o o g l e correspond à la version d?une page telle qu?elle se présentait lors de la dernière consultation effectuée par Google. Il se peut que la page ait été modifiée depuis cette date. Cliquez ici pour consulter la page actuelle (sans mises en valeur). Google n’est ni affilié aux auteurs de cette page ni responsable de son contenu.

Les termes de recherche suivants ont été mis en valeur : domain name service

Domain Name Service The Domain Name System (DNS) is the method by which Internet addresses in mnemonic form such as are converted into the equivalent numeric IP address such as 134.220.4.1. To the user and application process this translation is a service provided either by the local host or from a remote host via the Internet. The DNS server (or resolver) may communicate with other Internet DNS servers if it cannot translate the address itself. These notes will discuss sunc.scit.wlv.ac.uk.

1. 2. 3. 4.

The form of mnemonic addresses understood by DNS The hierarchichal structure of DNS servers and their databases How DNS servers communicate with each other The user and program interfaces to DNS

DNS name structure DNS names are constructed hierarchichally. The highest level of the hierarchy being the last component or label of the DNS address. Labels can be up to 63 characters long and are case insensitive. A maximum length of 255 characters is allowed. Labels must start with a letter and can only consist of letters, digits and hyphens. [Unfortunately some administrators construct names that start with digits. This is wrong and can easily cause problems with software that simply inspects the first character of a host address to determine whether a DNS name or an IP address has been quoted.] Note In the early days of the Internet users in at least one country (the United Kingdom) adopted a similar scheme with the highest hierarchical level appearing first rather than last. I.e. uk.ac.wlv.scit.sun rather than sunc.scit.wlv.ac.uk. This practice is, fortunately, obsolete. DNS addresses can be relative or fully qualified. A fully qualified address includes all the labels and is globally unique. A relative address can be converted by appending the local domain information. For example sunc.scit.wlv.ac.uk is a fully qualified name for the host sunc in the domain scit.wlv.ac.uk . Strictly there should be a stop at the end of a fully qualified name but this is often

overlooked. The final most significant label of a fully qualified name can fall into one of three classes arpa This is a special facility used for reverse translation, i.e. going from IP address to fully qualified domain address. If everything is properly configured a suitably framed query for 1.4.220.134.in-addr.arpa will return sunc.scit.wlv.ac.uk . Details of this will be described later. 3 letter codes The DNS was orginally introduced in the United States of America and the final component of an address was intended to indicate the type of organisation hosting the computer. Some of the three letter final labels (edu, gov, mil) are still only used by organisations based in the USA, others can be used anywhere in the world. The three letter codes are code com edu gov int mil net org

meaning Commercial. Now international. Educational. Government. International Organisiation. Military. Network related. Miscellaneous Organisation.

Two letter codes The final two letter codes indicate the country of origin and are defined in ISO 3166 with the minor exception that uk is used for the United Kingdom rather than gb although there are some .gb sites. [This apparently happened because the ISO committee was unaware that Northern Ireland was part of the United Kingdom but not part of Great Britain.] The two letter code us is used by some sites in the United States of America. In some countries there are sub-domains indicating the type of organisation such as ac.uk , co.uk , sch.uk in the United Kingdom and edu.au and com.au in Australia. Most European countries have not adopted this useful practice. A fuller discussion of the United Kingdom DNS domains is provided by the UK Network Information Centre. To obtain a domain address it is necessary to identify the administrator of the required domain and then all that is basically necessary is to send the administrator the required code and the associated IP address

and they will, if they accept the request, include the details in their databases. Conditions for acceptance vary widely between administrators, the administrators for the com and org being, apparently, quite happy to accept anything from anywhere.

DNS servers and their databases For any group of computers partaking of the DNS naming scheme there is likely to be a single definitive list of DNS names and associated IP addresses. The group of computers included in this list is called a zone . A zone could be a top level national domain or a university department. Within a zone DNS service for subsidiary zones may be delegated along with a subsidiary domain . The computer that maintains the master list for a zone is said to have authority for that zone and will be the primary name server for that zone, there will also be secondaries for that zone. When any process needs to determine an IP address given a DNS address it calls upon the local host to resolve the address. This can be done in a variety of ways Table lookup. On Unix hosts the table is called /etc/hosts The process communicates with a local name server process. This is commonly called named on a Unix system. named initially obtains information from /etc/hosts but also maintains a cache of recent requests. It sends a message to a remote system that is identified from the information in the file /etc/resolv.conf.

Finally if a network information system (NIS) is in use DNS service may be one of the facilities provided by the network information system. Most SUN systems work this way although the NIS master will use one or more of the techniques described above to build and maintain the master database. If a named process cannot resolve an address locally it will call upon higher authority. Ultimately it will attempt to contact the system that is authoritative for the zone in question, however, unless the information is cached or in the hosts local files then it will not know the address of the authoritative server. This problem is resolved by recursive resolution of requests, i.e. any DNS server will pass requests it cannot handle to a higher level server and so on until either the request can be handled (either by sending a message to the identified authoritative host) or until the root of the DNS name space is reached. There are eight servers that can serve requests at the root of the DNS name space, all servers should know their IP addresses so that DNS service can be offered even if there are no cached addresses and no local servers indicated by the /etc/resolv.conf file. The root servers will know the IP addresses of the servers for all the national DNS zones and the three letter zones.

Communication between servers The message formats used for exchange of queries and responses between hosts and DNS servers is specified in RFC 1035. Queries and responses can be transferred either via TCP or via UDP. There are

"well-known" port numbers for DNS service using either protocol. The format of a DNS query and response is Bits 0-15 Identification

Bits 16-31 flags number of answer number of questions RRs number of authority number of RRs additional RRs questions answers (RRs) authority (RRs) additional information RRs are Resource Records The 16 flag bits provide further information about the query QR bit. A single indicating a query (0) or a response (1) opcode 4 bits whose value means Value Meaning 0 Standard Query 1 Inverse Query 2 Server status request AA bit If set, this means that the server is authoritative for the domain in question. TC bit If set this means that the reply size exceeded 512 bytes and only the first 512 bytes were actually returned. This will only be used if the response is being returend via UDP. RD bit.

If this bit is not set then recursion is denied. This means that if the responding server cannot resolve the query itself rather than passing it on to "higher authority" and returning the result it eventually receives, it will simply return a list of other servers to try. RA bit. If this bit is set by a responding server then that server is indicating that it can handle queries recusively. 3 unused bits. These must be zero. 4 rcode bits. This indicates the status Value 0 1 2 3 4 5

Meaning No error Malformed Query Server Failed Name Does not Exist Query type unsupported by server Server refused to answer

After the 12 byte header the DNS query message consists of a block of questions which in turn consist of query name, query type and query class. Typically the query name is the name of site, each component of the name is sent a sequence of characters preceded by a byte holding the binary count of the number of characters in the component. The name is terminated by a zero byte. The query type indicates the type of information required encoded in a 16 bit field. Common values are

Name A NS CNAME PTR HINFO MX TXT AAAA AXFR ANY

Value 1 2 5 12 13 15 16 28 252 255

Description IPv4 Address (32 bits) Name Server Canonical Name Pointer Record Host Information Mail Exchange Record Text String IPv6 Address (128 bits) Request for Zone Transfer Request for All Records

Query class is usually 1 meaning an Internet domain query, other values could be used for different addressing domains. Response Records known as RRs form the body of the reply to a DNS query. They are used for the answers, authority and additional information fields. The form is Bits 0-15 Bits 16-31 Domain Name type class Time to live Resource Data Resource Data length Resource data (continued) The domain name is the query name from the query. The type is the query type. The class is 1 for the Internet domain . The time to live is the time for which the information can be cached by the client, typically two days, expressed in seconds. The resource data length specifies the number of bytes of resource data. It is important to note that queries can be made for information relating to both individual hosts and for zones/domains. Most of the query types are fairly obvious. The MX query is used specifically for mail handling and can return information about hosts not directly or regularly connected to the Internet. The result of an MX query for such a host is the address of an Internet host that will receive mail for such a host and make its own arrangements for forwarding the mail via non-Internet means or when the host does connect. An MX query response for a domain provides the address of the host that will handle mail for that domain allowing email addresses of the form User@domain_name. The NS query can be used to identify the name servers for a particular domain.

User Interfaces On Unix systems the normal user interface is the program /usr/sbin/nslookup . [The actual path may be different on some hosts] . This can be used to perform almost any DNS function and display the results to the user. Here is an example of its use on scitsc.wlv.ac.uk . Note . This example was prepared before the scit.wlv.ac.uk zone was delegated, scitsc is now known as sunc although the old name still works. bash$ /usr/etc/nslookup Default Server: scitsc.wlv.ac.uk Address: 134.220.4.1 > set q=A > ccub.wlv.ac.uk. Server: scitsc.wlv.ac.uk Address: 134.220.4.1 Name: ccub.wlv.ac.uk Address: 134.220.1.20 > set q=CNAME > www.wlv.ac.uk. Server: scitsc.wlv.ac.uk Address: 134.220.4.1 www.wlv.ac.uk canonical name = ccuf.wlv.ac.uk > set q=MX > wlv.ac.uk. Server: scitsc.wlv.ac.uk Address: 134.220.4.1 wlv.ac.uk preference = 1, mail exchanger = wlv.ac.uk wlv.ac.uk inet address = 134.220.1.12 > set q=HINFO > ccub.wlv.ac.uk. Server: scitsc.wlv.ac.uk Address: 134.220.4.1 ccub.wlv.ac.uk CPU=SUN 690MP > set q=PTR > 12.1.220.134.in-addr.arpa Server: scitsc.wlv.ac.uk Address: 134.220.4.1

OS=Solaris 2.4

12.1.220.134.in-addr.arpa

host name = ccug.wlv.ac.uk

Here it shows that sunc was providing DNS service. A number of queries were made. The query type was specified using nslookup’s set q= command. Type A A simple query for the IP address corresponding to ccub.wlv.ac.uk. Type CNAME

A given host can have several DNS names. One of these is the canonical or reference name. This query reveals that www.wlv.ac.uk is really ccuf.wlv.ac.uk. Type MX A mail exchanger query, this time for the domain wlv.ac.uk which reveals that mail sent to [email protected] is actually sent to 134.220.1.12 which is really ccug.wlv.ac.uk. (see below). Type HINFO An HINFO query. This is only useful if the DNS domain administrator has bothered to create the relevant records and keep them up to date. Type PTR A PTR query. This shows "inverse" or "reverse" resolution. Notice the very clumsy way the query has to be entered, this is partly because IP addresses have the most sigificant part first whereas DNS addresses have the most significant part last. There are plenty of pieces of software that do reverse resolution without this clumsy interface.

Program Interface The commonest program interface to DNS uses the library functions gethostbyaddr(). These are discussed in more detail elsewhere.

gethostbyname()

and

Exploring a zone The nslookup program can be used to obtain a listing of all the hosts in a zone. To do this it is first necessary to identify the name server for the zone. This is done using an NS query, setting the server parameter to one or other of the identified name servers and then using nslookup ’s ls command. Note that in this example the user was careful to include the final dot on the domain name, this prevented nslookup from trying to append the local default domain name ( scit.wlv.ac.uk. ) to the required domain name. For large domains the ls command has an option to write its results to a file. bash$ /usr/sbin/nslookup Default Server: sunc.scit.wlv.ac.uk Address: 134.220.4.1 > set q=NS > bilston.ac.uk. Server: sunc.scit.wlv.ac.uk Address: 134.220.4.1 Non-authoritative answer: bilston.ac.uk nameserver = unad1.wlv.ac.uk bilston.ac.uk nameserver = ccua.wlv.ac.uk bilston.ac.uk nameserver = ccub.wlv.ac.uk Authoritative answers can be found from:

unad1.wlv.ac.uk internet address = 134.220.192.26 ccua.wlv.ac.uk internet address = 134.220.1.39 ccub.wlv.ac.uk internet address = 134.220.1.20 > server ccub.wlv.ac.uk Default Server: ccub.wlv.ac.uk Address: 134.220.1.20 > ls bilston.ac.uk. [ccub.wlv.ac.uk] bilston.ac.uk. bilston.ac.uk. bilston.ac.uk. gw novix1 www fc student1

server = ccub.wlv.ac.uk server = unad1.wlv.ac.uk server = ccua.wlv.ac.uk 194.62.148.1 195.188.205.2 194.62.148.4 194.62.148.5 195.18.205.3

The session above was logged in March 1998. It reveals 5 hosts in the bilston.ac.uk domain . Surprisingly three different class C IP network addresses appear in the output. This was because the organisation was in the process of changing its Internet Service Provider accounting for two of the network addresses, the third (195.18.205) is, apparently, a typographical error for 195.188.205. Furthre information on identifying the ownership of an IP network and, implicitly, a DNS domain can be found in the notes on IP routing.

Alternative DNS hierarchies With the rapid commercialisation of the Internet in the late 1990’s disputes over DNS names arose from time to time and suggestions have been made for the creation of extra top level domains. The root of the current DNS hierarchy is maintained by the Network Information Center on a contract from the government of the United States of America. There have been several attempts to set up alternative hierarchies. The most succesful (at the time of writing - April 1998) is probably Alternic. To use the Alternic DNS service you need to know the address of their root servers, one of these is mx.alternic.net . Here’s an example showing that it does work for DNS resolution of www.alternic.nic. bash$ /usr/sbin/nslookup Default Server: sunc.scit.wlv.ac.uk Address: 134.220.4.1 > server mx.alternic.net Default Server: mx.alternic.net Address: 206.191.128.47 > www.alternic.nic. Server: mx.alternic.net Address: 206.191.128.47 Name: www.alternic.nic Address: 206.191.128.47

Alternic uses three letter top level domains for countries (such as jpn and ger ) and has a large number

of commercially oriented top level domains. At the time of writing the only domains with significant populations are porno and xxx. A normal name server can only resolve Alternic addresses if they’re already in its cache. Most DNS implementations with a list of root servers consult them in random order or consistently consult the first one in the list. Including one of the Alternic servers in amongst the list of root servers will not provide consistent resolution of addresses in both hierarchies. [Note: this particular aberration seems to have fizzled out (May 1999)]

Zones of Convenience It is tempting to think that an Internet host with a name ending in ".uk" is actually located in the United Kingdom. There is no requirement that this should be so. For example the well known host www.yahoo.co.uk is actually located in southern Germany. In the case of the United Kingdom it is simply necessary to present the organisation that runs the ".co.uk" domain with an IP address (and a suitable sum of money !) and the DNS address will be registered. The top-level administration of the ".uk" domain will only delegate to specifically UK based organisations. Some administrations are distinctly less fussy and a number of "zones of convenience" along the same lines as "flags of convenience" have come into fairly common usage. These are mostly poor third world countries or tiny groups of islands desperate for some hard cash, they also tend to sell un-necessary sets of stamps and coins to guillible collectors. The most common ones seem to be ".cc" (the Cocos-Keeling Islands), ".to" (Tonga) and ".nu" (Niue). At one time both ".is" (Iceland) and ".tm" (Turkmenistan) allowed their top level domains to be used in this fashion, but they now seem to adopt a more rational approach. Some of the blame must attach to Internic who have created some pretty unlikely top-level domains. It is difficult to imagine anybody using ".bv", the allocated top-level domain for Bouvet Island, an uninhabited (an uninhabitable !) Norwegian Dependency about half-way between South Africa and Antarctica whose only claim to fame is that it is the most isolated piece of land in the world. Communication Systems (CP3340) Home Page.