Domain Name Service. in-addr sfu

Transcription

1 Domain Name Service It s nice to be able to refer to machines by names, instead of numbers. Humans do better with fraser.sfu.ca than with When the Internet was small & cute and still the ARPAnet, the business of relating names to numbers was handled by a computer and some humans at the Network Information Center. As the Internet grew and became large and fractious, maintaining a single host database file became impossible. There were too many changes to be processed, and too many translation requests to be answered. No single ofifice or computer could handle the load. What was needed was a new system that was scaleable and practical. The solution was the Domain Name Service (). Defined in RFCs 1034 and 1035, it specifies how to partition the name space and delegate authority for name to address translations based on that partition. In concept, much like the solution to handling address assignment and routing. Chronologically, it looks like came first ( judging from publication dates of various RFCs. The organisation chosen for the name space is a tree. gtlds (unnamed root) cctlds arpa com edu gov... net... aero... bz ca cc in-addr sfu csil cs... fraser ( ) cs-vnl-d01 ( ) gallifrey ( ) (cs-vnl-d01) (fraser) 47 (gallifrey) At the top is an unnamed root, sometimes visible as a terminating. at the end of a domain name. Immediately below the root are the top-level domains, or TLD s. There are geographic TLDs (commonly known as country code domains or cctlds), with two letter codes specified by the ISO. For Canada, the code is ca. There are the well-known generic top-level domains (gtlds): 1 May, 2009

2 com edu gov mil int net org commercial organisations educational institutions U.S. government U.S. military international (treaty) organisations networks other organisations (non-profits, etc.) More recently, new gtlds have been added. It s now possible for an organisation to sponsor a domain by providing the infrastructure necessary for name registration. For example, Name Constituency Type aero air transport industry sponsored biz business generic restricted coop cooperatives sponsored info generic museum museums sponsored name individuals generic restricted pro professionals generic restricted At present (2012) there are over 20 TLDs, some sponsored by quite small user communities, others open to anyone. Most recently, the ICANN has introduced internationalised domain names expressed using unicode. Technical planning for IDNs dates to 2003 at present, IDN cctlds are in use, with IDN gtlds coming soon. See for additional information. The whole business of domain names is, well, a business, and litigation for desirable domain names is common. There are competing organisations at the level of the root, and this has generated controversy and name conflicts. A Wikipedia article, root, gives a nice introduction. For some interesting history and discussion of the pressures being brought to bear on the system, have a look at RFCs 3071 and The sfu domain is a second-level domain, registered under the ca cctld. To refer to a system at SFU, fraser, for example, you might use the name fraser.sfu.ca. The sfu domain is itself divided into lower-level domains, such as cs, fas, csil, ensc, cecm, and others. 2 May, 2009

3 One other TLD that needs special mention is the in-addr.arpa domain. This is used for translation of IP addresses back to host names. The host fraser has IP address A query for the name in-addr.arpa would return the name fraser. Notice that the octets of the IP address are written according to the standard ordering, where the portions of the name are written from most local to most global. Let s be precise about what we mean by a domain and a zone. A domain is a complete subtree in the name tree. A zone is a subtree, minus any delegated subtrees. Generally, we would phrase this as a zone is a domain, minus any delegated subdomains. Delegation is an administrative matter, in which responsibility for a portion of the name space is handed off by one organisation to another. The point is that a domain is defined as a structure (a subtree) in the name tree. A zone is partially defined by the tree structure (a subtree) and partially by administrative boundaries (minus delegated subtrees). When an administrative authority takes control of a zone, it must agree to provide two completely independent servers (i.e., on different machines, on different networks, independent power supplies, etc.) so that any reasonable single-point failure will not leave the domain without a server. Most often, an administrative authority will have control of several zones. In the simplest case (no delegated subdomains), there would be a zone for the domain and a zone for the corresponding in-addr.arpa domain. The text gives another example, where an administrative authority might have control over a subtree in a generic domain, and over a corresponding subtree in a country domain. While there s often a correspondence between physical network structure, organisational administrative structure, internet addresses, and domain name structure, recognise that there s no requirement that this be so. It s just that most often, an organisation will apply for a block of IP addresses and a domain, and then create physical subnets (IP address assignments) and subdomains that correspond to its internal organisational structure. Let s look again at the sfu.ca domain, a subdomain of the ca cctld. 3 May, 2009

4 The Faculty of Applied Sciences Network Support Group (NSG) is an independent administrative authority, delegated from IT Services (ITS), the administrators of the sfu.ca domain. The NSG administers the cs (Computing Science) domain, as well as several others: fas, ensc (Engineering Science), and math (Mathematics and Statistics). Physically, this group of workstations and network segments is the FASNet. If you look up the name servers for the fas.sfu.ca domain (using nslookup or dig) you ll find that the NSG runs a name server, cs.sfu.ca, and has an agreement with ITS to provide independent service using the servers whistler.sfu.ca, seymour.sfu.ca, and ns3.sfu.ca. Moving up the tree, ITS provides service for sfu.ca using the servers whistler.sfu.ca, seymour.sfu.ca, and ns3.sfu.ca. Since ns3.sfu.ca is located at Harbour Centre, this satisfies the requirement for physically independent servers. The Canadian Internet Registration Authority (CIRA) operates or contracts for the operation of ten servers for the ca domain 1. It s common for one organisation to make an agreement with another to provide an independent name server. ICANN contracts with various organisations to operate the 13 root servers which serve the. domain, a.root-servers.net through m.root-servers.net. It administers some TLDs directly and contracts with companies or organisations for administration of others. If you want to apply for a subdomain within the ca domain today, you d apply to the CIRA. CIRA took over from the previous organisation, a volunteer group called the.ca committee, in Fall, You, however, cannot deal directly with CIRA you ll have to go through a CIRA certified registrar, thus providing additional Internet business opportunities. In general, administration of a cctld is handled by an organisation in that country. If you want to register a subdomain in one of the generic domains (gtlds), you d go to one of the registries accredited by the Internet Corporation for Assigned Numbers and Names (ICANN), the organisational (but not, apparently, operational) successor to the IANA. It s worth repeating that registering a domain name is entirely independent of acquiring an IP address. You need both in order to construct entries for your domain. 1 Eight servers, a, c, e, f, j, k, l, and z.ca-servers.ca are operated by CIRA. Two, tld.isc-sns.net and sns-pb.ics.org, are operated by the Internet Systems Consortium (ISC). 4 May, 2009

5 Now that we know the basic structure, let s delve into the workings of the protocol. An implementation of is divided into two components: The resolver is most often implemented as a subroutine library used by client programs to compose queries and receive answers. The name server is a dæmon (named in the Unix world). It listens for queries at well-known port 53 (UDP and TCP). (Look for domain in /etc/services.) UDP is used for most queries and responses. In the special case where the entire contents of a database is being transferred (an activity called a zone transfer) TCP may be used to avoid datagram size limitations and ensure reliable data transfer. The most visible use of is to answer queries for the IP address associated with a host name. In fact, it handles several other types of information and could potentially be used as a general key-value service. To explain how a query is answered we ll stick with name to address translation. The resolver composes the query and sends it to one of the servers that it knows about (call this server the local server). For the typical case of a lightweight resolver library dealing with a set of local servers, the local servers will be configured to accept recursive queries (defined immediately below) from processes running on the local workstations. If the local server doesn t know the answer, the question is passed to a server at a higher level (closer to the root of the name tree). In the absence of cached information (as explained below), this will be one of the Internet root servers at the root of the tree. The query is then passed down the tree until it reaches a server which knows the answer. There are two ways in which this can be accomplished, iterative and recursive. In an iterative query, the name server which receives the query will respond with the answer or with the name(s) of the name server(s) that it would consult to find the answer. In a recursive query, the name server which receives the query will take it on itself to send off a query to another name server, if necessary, and will respond with the final answer. 5 May, 2009

6 You can see the process of delegation from the Internet root servers by using the trace option to the dig command ( dig +trace name ). In a standard configuration, a name server starts off knowing the names and IP addresses of the 13 root servers for the Internet. There are only 13 root servers because the designers of decided that the records required to answer a query for the name servers for the. domain should fit in a 512 byte UDP datagram 2. At one time, this was an actual physical limit. More recently, use of anycast 3 IP addresses has removed the physical limit, and there are now many root servers at over 100 geographically distributed locations. See for an interesting article about a distributed denial-of-service attack on the Internet root servers on February 6, The article includes a description of the Internet root server system. See for one of several maps to be found on the Internet. servers do not start with more extensive knowledge of servers higher in the name tree because this would imply an obligation by those servers to distribute notifications if they changed their IP address. Given the expansion at each level of the tree, this is an unreasonable burden. (See, for example, RFC ) In particular, and despite a widespread belief to the contrary, a server does not start life knowing the address of its immediate parent server in the name tree. (See, for example, RFC ) It will, however, quickly learn the name and IP address of its parent in the normal course of answering queries. As we ll see, servers must be told the names of the servers for domains below them in the hierarchy. This is what allows a server at a higher level to pass a request down the tree to the server for a particular domain. This implies an obligation by the lower server to notify the (single) parent server if it changes its IP address. A subset of the servers for a domain, called primary servers, must also be initialised (from files) with knowledge of hosts within their do- 2 The figure of 512 bytes was chosen during the design of the Internet protocols. Adding a 64 byte header allowance gives the minimum IP packet size of 576 bytes. Because defines a compression scheme to limit the repetition of data in messages, it s not straightforward to demonstrate that this limits the number of root servers to Anycast is a relatively new use of IP addressing and the routing infrastructure which allows a single IP address to be assigned to many different physical interfaces. 6 May, 2009

7 main. Typically there is exactly one primary server, to avoid replication of the data files. Efificient operation of the system depends on local caches of records. Suppose the resolver on a host contacts a local server with a query for the IP address associated with a specific host name. When an answer to the query comes back to the local server, it will typically include not only the address for the specific name given in the request, but also records for the authoritative name servers for the domain, plus additional records that are likely to be useful in the near future. All the records are cached, along with the answer for the specific host. The next time there s a query for that specific host, the local server will answer it from its own cache. The next time there s a query for an unknown host in the same domain, it ll be passed directly to the domain s name server, using the cached records that specify the servers for the domain. That s our second cut at describing the system. Now, let s get really specific. The reference implementation of is an open source package called BIND (for Berkeley Internet Name Dæmon), now maintained by the Internet Software Consortium. The current release of software is BIND 9. We ll start with the resolver library. The resolver doesn t need to be told very much just the IP addresses of the servers it should use. On unix systems, the place to look is /etc/resolv.conf. It can contain the IP addresses of up to three name servers. The name server dæmon is a bit more complicated. The first thing we need to understand is the distinction between a primary server, a secondary server, and a cache-only server. A primary or master server for a zone initialises its cache from a set of files that are maintained by a human. These files contain information about the hosts in the zone. We haven t entirely gotten rid of the need for a human to maintain the name to address information, simply parcelled it out into manageable bits. A secondary or slave server for a zone initialises its cache from the primary server for a domain. 7 May, 2009

8 Primary and secondary servers are authoritative for a domain. When one of them provides an answer, that s the end of it. The reason for having primary and secondary servers is so that the files which are the source of host information for the domain exist in exactly one place. The primary server initialises itself from the files, and then the secondary servers initialise themselves from the primary server. A cache-only server is defined by the absence of primary or secondary server status. A cache-only server may be initialised with the names of the Internet root servers, or it may be given a short list of name servers to which it will forward all queries. All servers, as they receive answers to queries, gradually build the capability to answer more and more queries locally. The reason for having cache-only servers is efificiency. We might as well accumulate a cache of information close to the workstation. A workstation might run its own cache-only server, or an organisation might provide several, scattered about its intranet. It s considered good operational practice to configure authoritative servers so that they do not cache additional information. This improves their reliability (stability) and protects the integrity of the authoritative information. When a server starts up, it looks for a configuration file. The default file for unix is typically /etc/named.conf. The configuration file can specify lots of options for named, but the important thing we need to know here is that it will contain a set of records which associate domain names with database files called zone files. The format of a minimal record for a primary server would be zone "domain-name" IN { type master file pathname } We want to know this to understand one of the common conventions in a zone file, which is that the stands for the current domain name. The initial definition of the current domain name occurs when named reads domain-name in the configuration file and associates it with the corresponding zone file. Also, keep in mind that all names are interpreted relative to the current domain unless they are specified as fully-qualified domain names (FQDN). A fully qualified domain name ends with a., e.g., orion.csil.sfu.ca. 8 May, 2009

9 So, if the configuration file has directed named to read a particular file for the domain csil.sfu.ca, names in the file will have.csil.sfu.ca. tacked onto the end unless they already end with a.. To summarize: When named starts, it looks for a configuration file, by default /etc/named.conf. This configuration file contains lines which associate domain names with data files containing records for that domain. More precisely, each data file contains records for the domain, minus delegated subdomains, plus glue records specifying the name servers for delegated subdomains. The data files are called zone files because the contain information for a zone. The second chunk of knowledge we need is just what is defined in the records. There are about 50 resource record (RR) types. We ll restrict ourselves to six of them that are the most important in practice in IPv4. The ones we ll talk about are Start of Authority (SOA), Name Server (NS), Address (A), Canonical Name (CNAME), Domain Name Pointer (PTR), and Mail Exchange (MX). The standard format for a resource record is [name] [ttl] [class] type data The name specifies a host or domain. If name is omitted, it defaults to the last explicitly specified name. The ttl specifies how long (in seconds) this entry can be cached. If it hasn t been refreshed within the specified time, it should be deleted. For, time-to-live has traditionally been relatively long on the order of days on the theory that host names & related information don t really change all that often. The rise of ISPs and dynamic IP address assignment has obviously changed the rules of the game for a subset of records. If ttl is omitted, it defaults to the value given in the SOA record. The class is always IN, for Internet, as far as we ll be concerned. It is possible to use for other classes of information, but it s not common. If class is omitted, it defaults to the last explicitly specified class. The type of record is specified by one of the codes (SOA, NS, etc.) mentioned above. The data format depends on the type of record. The overall organisation of a database initialisation file is a SOA record, which defines the primary server for a domain, followed by a series of 9 May, 2009

10 other records which define hosts and services in the domain and servers for subdomains (called points of delegation in terminology). The SOA record specifies the host that is the primary server for a zone. It also provides contact information and time limits for records for the zone. By definition, there is only one SOA record in a zone file. The RFCs actually state that the SOA record defines the start of authority for a zone. The original RFCs are silent on just which server should be named in the SOA record, but subsequent RFCs (see, for example, RFC 2136 for Dynamic ) indicate this should be the primary server. A single host may be the primary server for several zones recall the text s example about parallel organisational and geographic domains, or the SFU example with one host handling multiple domains at the same level of the hierarchy. In this case, the host will be named in the SOA record of several zone files. The format for a SOA record in a zone file is [zone] [ttl] IN SOA origin contact ( serial refresh retry expire minimum ) All times are in seconds. Most commonly, the zone is entered referring to the domain name specified in the line in the boot file. ttl is commonly omitted in nearly all records, and will default to the value given in the SOA record for minimum. Typically, the only reason for specifying a different ttl is if a change is anticipated and the administrator wants to make sure the record will not persist in the database of other servers. The class is IN, as mentioned previously, and the type is SOA. origin is the FQDN (fully qualified domain name) of the host which is the master server for the domain. contact is an address for the person responsible for the administration of the of the domain. (Note that a. replaces that would normally appear in an address to separate the user ID from the host name.) 10 May, 2009

11 Each record is nominally a single line. In a zone file, the continuation convention is to enclose the data with parentheses (). Why the origin and contact aren t included in the parentheses is unclear apparently, just convention carried through years of illustrative examples. serial is a version number. There are many conventions here. The main thing is that a server be able to compare two serial values as numbers and decide which is more recent. There are some rather arcane rules here, which you should read carefully if you want to use something other than a straight number. (There s provision, for example, for dotted version numbers.) refresh tells a secondary server the interval at which it should check with the primary server and update its database. It decides whether an update is necessary by comparing the serial number stored with its database with the serial number of the primary s database. If the primary s information is more recent, the secondary will download the newer database. Typically the refresh interval will be once or twice a day unless network changes are planned. retry is the interval between attempts by the secondary server to contact the primary server. This is typically set to something on the order of half an hour to an hour. expire is the interval that a secondary server will consider database information to remain valid without receiving a refresh from the primary server. On the basis that data tends to be stable, this is set to a large value a month to a month and a half. Typically this limit will be relevant only in the event of catastrophe (e.g., the system administrator is hit by a bus and the primary server goes down while the hiring process grinds to completion). minimum is the default ttl for a record. This value is important to other servers which have obtained and cached the record. As with other timeouts, this is set to a value on the order of a few weeks to a month. The NS (name server) record defines an authoritative nameserver for a domain (primary or secondary). The format is [domain] [ttl] IN NS server The domain, ttl, and IN fields are as for SOA. The NS code says that this is a name server record. server is the host name of the name server. When specifying a name server for the current domain, the domain field can be left empty. 11 May, 2009

12 The other important use of a NS record is to specify the name servers for delegated subdomains. This is how a query works its way down from the root of the tree to a server for a specific domain. In this case, the domain field would contain the name of the subdomain (which is interpreted within the current domain, i.e., the current domain is tacked on the end). An A (address) record provides the host to IP address translation information. The format is [host] [ttl] IN A IP address The host name will usually be present (unless this record follows immediately after some other record for the host). The IP address is specified in the usual dotted decimal form. MX (mail exchange) records allow mail to a domain, or to a specific host, to be directed to a designated host. The format is [host domain] [ttl] IN MX preference host One can specify multiple mail exchange hosts, in which case a mailer will try them in order of preference until it finds one that works. The preference is an integer, smaller is better. The host field specifies the mail exchange host. The CNAME (canonical name) record is used to specify alternate names for a host. The format is nickname [ttl] IN CNAME official name The serious purpose of this type of record is to allow various standard nicknames to be mapped to hosts, e.g., loghost, mailhost. You can assign as many nicknames to a host as you like (keeping in mind that you re really assigning nicknames for a particular IP address). Recall that the in-addr.arpa domain exists to translate IP addresses back to names. The PTR record is used to specify this inverse translation. The format is IP address [ttl] IN PTR name 12 May, 2009

13 The IP address is usually specified relative to the current domain (which in this case would be the network number). The name of the host is specified as a FQDN. In PTR records it must be a FQDN because we certainly don t want the parser tacking the current domain (.in-addr.arpa) onto the end of the name! There are a number of other record types HINFO (host info), WKS (wellknown services), and various experimental types but they re not common. Some have fallen into disuse due to security concerns, others simply remain experimental (thus uncommon by definition). And there are new record types for IPv6, which we ll consider in that context. To see how this all fits together, here s an example of configuration and zone files for a fictional domain nuts.com. This example originally appeared in TCP/IP Network Administration by Craig Hunt, published by O Reilly and Associates, but has been discontinued in the 3 rd edition. It has been rewritten to conform to the syntax introduced with BIND 8. Let s start with the named configuration file, often called named.conf in unix systems. /* nuts.com primary name server configuration file. */ options { directory "/var/named" } /* specify the zone files */ zone "nuts.com" { type master file "named.hosts" } zone " in-addr.arpa" { type master file "named.rev" } zone " in-addr.arpa" { type master file "named.local" } /* hint is used to initialise the cache with the names of one or more of the Internet root servers (the. domain). */ zone "." { type hint file "named.ca" } 13 May, 2009

14 There s a zone file for each of four domains administered by Nuts, Inc. As we ll see, the main resource records for nuts.com will be found in named.hosts. The PTR records required to translate IP addresses back to names will be found in the files named.rev and named.local. Finally, the file named.ca will contain the information required to contact the Internet root servers. Here s the nuts.com named.hosts file. Contact and record lifetime information for IN SOA almond.nuts.com. jan.almond.nuts.com. ( serial number slave refresh interval 3600 slave retry interval slave db expiry interval default ttl for individual records ) Note that bind has syntax problems if the name for a record doesn t start in the first column --- it tries to interpret it as the class. This is a consequence of allowing name and ttl to both default (name to the most recent name, and ttl to the value from the SOA record). The NS and MX records that follow take advantage of the defaults. Name servers for nuts.com. Note FQDN s. The most recent explicitly specified name remains in effect until changed. In this case, the name = nuts.com. IN NS almond.nuts.com. IN NS filbert.nuts.com. IN NS foo.army.mil. Mail servers for nuts.com, redirects mail for user@nuts.com IN MX 10 almond.nuts.com. IN MX 20 pecan.nuts.com. Associate localhost with loopback address The name for this record is localhost.nuts.com. localhost IN A Hosts in nuts.com domain. almond is the logging host, MX record is a courtesy for some mailer implementations. almond IN A May, 2009

15 IN MX 5 almond.nuts.com. loghost IN CNAME almond almond is also a gateway and mil-gw is the name of the interface on the MILNET side. Class A network 26/8 belongs to the Defense Information Systems Agency, according to the IANA IPv4 address space assignment record. The name for this A record is mil-gw.nuts.com. mil-gw IN A MX record here redirects mail even if specifically sent to peanut. peanut IN A IN MX 5 almond.nuts.com. goober IN CNAME peanut more hosts pecan IN A walnut IN A filbert IN A And here are the name server records for the subdomains that have been delegated off as independent zones. plant IN NS pack.plant.nuts.com. IN NS pecan.nuts.com. sales IN NS acorn.sales.nuts.com. IN NS pack.plant.nuts.com. And we need to know how to reach the name servers for the delegated subdomains. pack.plant IN A acorn.sales IN A Remember that both the name and ttl portions of a record are commonly defaulted by leaving the fields blank. For ttl, the default is the value given for the minimum field in the SOA record. For name, the rule is that the last explicitly specified name qualifies in this respect) remains in effect until explicitly changed. Also keep in mind that names which are not specified as FQDN s will have the value tacked onto the end. Here s the named.rev file. 15 May, 2009

16 Address to host name reverse IN SOA almond.nuts.com. jan.almond.nuts.com. ( serial number slave refresh interval 3600 slave retry interval slave db expiry interval default ttl for individual records ) Name servers for in-addr.arpa, note FQDN s. IN NS almond.nuts.com. IN NS filbert.nuts.com. IN NS foo.army.mil. And now the PTR records that define the address to name mapping. The names here are also FQDN, we don t want in-addr.arpa on the end IN PTR almond.nuts.com IN PTR peanut.nuts.com IN PTR pecan.nuts.com IN PTR walnut.nuts.com. 2.1 IN PTR filbert.nuts.com. Name servers for delegated subdomains, to match the delegation in named.hosts. 18 IN NS pack.plant.nuts.com. IN NS pecan.nuts.com. 6 IN NS acorn.sales.nuts.com. IN NS pack.plant.nuts.com. Here s the named.local file. This file defines the address to host name mapping for this IN SOA almond.nuts.com. jan.almond.nuts.com. ( serial number slave refresh interval 3600 slave retry interval slave db expiry interval default ttl for individual records ) Typically the name server will be the local machine. IN NS almond.nuts.com. And the actual address to name PTR record. 16 May, 2009

17 1 IN PTR localhost. And finally, the named.ca file. This is actually the cache file from the Network Lab. As you can see, only the names have been changed, to confuse the newcomers. This file holds the information on root name servers needed to initialize the cache of the local name server. formerly NS.INTERNIC.NET IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET A formerly NS1.ISI.EDU NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET A formerly C.PSI.NET NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET A formerly TERP.UMD.EDU NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET A formerly NS.NASA.GOV NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET A formerly NS.ISC.ORG NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET A formerly NS.NIC.DDN.MIL NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET A formerly AOS.ARL.ARMY.MIL NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET A formerly NIC.NORDU.NET 17 May, 2009

18 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET A temporarily housed at NSI (InterNIC) NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET A housed in LINX, operated by RIPE NCC NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET A temporarily housed at ISI (IANA) NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET A housed in Japan, operated by WIDE NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET A Now that we ve seen how the primary server s database is established from files, let s have a quick look at message types and how they re used to communicate between resolver and server, and between servers. We won t look at the details of messages, which use a fair bit of optimisation to reduce the number of bytes actually transmitted. is, in some ways, a simple protocol. There are queries, and responses to queries. Originally, there were three types of query: standard (QUERY), inverse (IQUERY), and server status (STATUS). Inverse queries are now obsolete. A header is present in both queries and responses. It specifies the type of query or response, various control flags, and the size of the remaining sections of the message. A query has only one additional section: the question section, which contains a question record (a domain name, and the type and class of query). A response has up to three additional sections: answer, authority, and additional. The answer section contains resource records which satisfy the query. (I.e., they matched the specified name, type, and class keys.) 18 May, 2009

19 The authority section contains resource records which specify an authoritative name server for the domain specified in the query. The additional section contains resource records which are related to the query but not strictly part of the answer (address records, for example, to go with SOA, NS, or MX records). Inverse queries were not simply address name mappings. They provided a general way of performing the reverse mapping from resource to name. Given a resource (in the answer section), the response to an inverse query would fill the question section with all the names that possess the resource. Inverse query support was specified as optional and was never widely implemented. It was a difificult service to provide, and there were concerns that inverse queries could result in huge amounts of data returned in an answer. As network administrators became more security conscious, there were also concerns about the amount of information that could be revealed through inverse queries. If all you really want is address name translation, use a standard query in the.in-addr.arpa domain. Because inverse query support was specified as optional because the primary type of inverse query was translation of an IP address to a name and because of the implementation and security issues, inverse queries are ofificially made obsolete by RFC Dynamic As originally conceived, had a static database of files, and updates were made by manually editing those files. This seemed a reasonable choice given that information was expected to be relatively static. That changed as networks grew. But what really broke the relatively static mold was the introduction of environments like ISPs, drop-in networks, and wireless networks, where it was routine to have computers dropping in and out of the network in a time frame measured in minutes. Dynamic, defined in RFC 2136, is an extension of the protocol which provides for on-line updates. The original protocol provided for QUERY, IQUERY, and STATUS messages. 19 May, 2009

20 Dynamic adds the UPDATE message, to allow for online incremental updating of resource records. Without this, the only way to update the database for the primary server was to edit a zone file and reload it. An UPDATE message specifies what is to be updated and prerequisite conditions for applying the update. The prerequisite conditions take the form of requirements for the presence or absence of particular resource records or sets of records. The update can result in the addition or deletion of one or more records. (Modification is deletion followed by addition.) Updates are atomic. All prerequisites are checked for satisfaction, then all updates are applied. If, for some reason, any individual change fails, the entire update is retracted. A program making an update request (a dhcp dæmon, for example) can contact any primary or secondary server for the zone it wants to update 4. If the server isn t the master server for the zone, it is obligated to forward the request to the master server and then forward the response to the original requestor. Allowing dynamic update introduces all the complications of maintaining a database in the presence of concurrent transactions. A particularly nasty quirk is that either UDP or TCP can be used to request an update the answer is returned by the same protocol. Suppose an UPDATE message delivered by UDP is successfully processed by the server but the UDP reply is lost. The requestor repeats the request. The repeat request fails, because the successful execution of the original request changed the database records in the server and the prerequisites no longer hold. This time the reply failure is successfully delivered to the requestor. The server and the requestor are now inconsistent, because the server s database has been updated but the requestor thinks the update has failed. The writers of the RFC recommend the use of TCP if this sort of situation is possible. 4 The details as stated in RFC 2136 are more complicated. If a server receiving an update request is not authoritative for the zone being updated, it returns a not authorised error to the requestor. In practice, this restricts requests to the primary and secondary servers for a zone. 20 May, 2009

21 Security is another big concern if on-line updates are possible. One solution is to configure the server so that it will only accept updates from a known set of trusted IP addresses. A better solution is to use a secured version of the protocol (RFC 2137), or run using a secure version of IP. (For secure, read encrypted, with authentication.) 21 May, 2009