Cmpt 471 DNS

Domain Name Service

e It’s nice to be able to refer to machines by names, instead of numbers. Hu-mans do better with fraser.sfu.ca than with 142.58.101.25.

e When the Internet was small & cute and still the ARPAnet, the business ofrelating names to numbers was handled by a computer and some humans atthe Network Information Center. As the Internet grew and became large andfractious, maintaining a single host database file became impossible. Therewere too many changes to be processed, and too many translation requeststo be answered. No single ofifice or computer could handle the load.

e What was needed was a new system that was scaleable and practical. Thesolution was the Domain Name Service (DNS). Defined in RFCs 1034 and1035, it specifies how to partition the name space and delegate authority forname to address translations based on that partition.

f In concept, much like the solution to handling address assignment androuting. Chronologically, it looks like DNS came first ( judging frompublication dates of various RFCs.

e The organisation chosen for the DNS name space is a tree.

(unnamed root)

ca. . . . . . . . . . . .com

. . .

gov

. . .

edu

. . .

net

. . .

aero

. . .

bz

. . . . . .

cc

. . .

arpa

in-addr

142 199

58 60

3

47

101

105

21

142

(cs-vnl-d01) (fraser) (gallifrey)

sfu

fraser

(142.58.101.25)

cs

. . .

csil

cs-vnl-d01

(142.58.21.142)

. . .

gallifrey

(199.60.3.37)

. . .

gTLDs ccTLDs

f At the top is an unnamed root, sometimes visible as a terminating ‘.’ atthe end of a domain name.

f Immediately below the root are the ‘top-level domains’, or TLD’s.There are geographic TLDs (commonly known as ‘country code’ domainsor ccTLDs), with two letter codes specified by the ISO. For Canada, thecode is ‘ca’.There are the well-known generic top-level domains (gTLDs):

1 May, 2009

Cmpt 471 DNS

com commercial organisationsedu educational institutionsgov U.S. governmentmil U.S. militaryint international (treaty) organisationsnet networksorg other organisations (non-profits, etc.)

More recently, new gTLDs have been added. It’s now possible for anorganisation to sponsor a domain by providing the infrastructure nec-essary for name registration. For example,

Name Constituency Typeaero air transport industry sponsoredbiz business generic – restrictedcoop cooperatives sponsoredinfo genericmuseum museums sponsoredname individuals generic – restrictedpro professionals generic – restricted

At present (2012) there are over 20 TLDs, some sponsored by quite smalluser communities, others open to anyone.Most recently, the ICANN has introduced internationalised domain namesexpressed using unicode. Technical planning for IDNs dates to 2003; atpresent, IDN ccTLDs are in use, with IDN gTLDs coming soon. Seehttp://www.icann.org/en/topics/idn/ for additional information.The whole business of domain names is, well, a business, and litigationfor desirable domain names is common.There are competing organisations at the level of the DNS root, andthis has generated controversy and name conflicts. A Wikipedia arti-cle, http://en.wikipedia.org/wiki/Alternative_DNS_root, givesa nice introduction.

f For some interesting history and discussion of the pressures being broughtto bear on the DNS system, have a look at RFCs 3071 and 3467.

e 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 namefraser.sfu.ca.

f The sfu domain is itself divided into lower-level domains, such as cs,fas, csil, ensc, cecm, and others.

2 May, 2009

Cmpt 471 DNS

e 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.

f The host fraser has IP address 142.58.101.25.

f A query for the name 25.101.58.142.in-addr.arpa would return thename fraser.

f Notice that the octets of the IP address are written according to thestandard DNS ordering, where the portions of the name are writtenfrom most local to most global.

e Let’s be precise about what we mean by a DNS domain and a DNS zone.

f A DNS domain is a complete subtree in the DNS name tree.

f A DNS zone is a subtree, minus any delegated subtrees. Generally, wewould phrase this as “a zone is a DNS domain, minus any delegatedsubdomains”. Delegation is an administrative matter, in which respon-sibility for a portion of the DNS name space is handed off by one organ-isation to another.

f The point is that a domain is defined as a structure (a subtree) in theDNS name tree. A zone is partially defined by the DNS tree structure(a subtree) and partially by administrative boundaries (minus delegatedsubtrees).

f When an administrative authority takes control of a zone, it must agreeto provide two completely independent DNS servers (i.e., on differentmachines, on different networks, independent power supplies, etc.) sothat any reasonable single-point failure will not leave the domain with-out a DNS server.

f Most often, an administrative authority will have control of several zones.In the simplest case (no delegated subdomains), there would be a zonefor the domain and a zone for the corresponding in-addr.arpa do-main. The text gives another example, where an administrative author-ity might have control over a subtree in a generic domain, and over acorresponding subtree in a country domain.

f While there’s often a correspondence between physical network struc-ture, organisational administrative structure, internet addresses, anddomain name structure, recognise that there’s no requirement that thisbe so. It’s just that most often, an organisation will apply for a blockof IP addresses and a domain, and then create physical subnets (IP ad-dress assignments) and DNS subdomains that correspond to its internalorganisational structure.

e Let’s look again at the sfu.ca domain, a subdomain of the ca ccTLD.

3 May, 2009

Cmpt 471 DNS

f The Faculty of Applied Sciences Network Support Group (NSG) is anindependent 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 (En-gineering 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 (usingnslookup or dig) you’ll find that the NSG runs a name server, cs.sfu.ca,and has an agreement with ITS to provide independent DNS service us-ing the servers whistler.sfu.ca, seymour.sfu.ca, and ns3.sfu.ca.

f Moving up the tree, ITS provides DNS service for sfu.ca using theservers whistler.sfu.ca, seymour.sfu.ca, and ns3.sfu.ca. Sincens3.sfu.ca is located at Harbour Centre, this satisfies the requirementfor physically independent DNS servers.

f The Canadian Internet Registration Authority (CIRA) operates or con-tracts for the operation of ten DNS servers for the ca domain1. It’s com-mon for one organisation to make an agreement with another to providean independent name server.

f ICANN contracts with various organisations to operate the 13 rootservers which serve the ‘.’ domain, a.root-servers.net throughm.root-servers.net. It administers some TLDs directly and contractswith companies or organisations for administration of others.

e If you want to apply for a subdomain within the ca domain today, you’d applyto the CIRA. CIRA took over from the previous organisation, a volunteergroup called the .CA committee, in Fall, 2000. You, however, cannot dealdirectly 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 thatcountry.

e 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 forAssigned Numbers and Names (ICANN), the organisational (but not, appar-ently, operational) successor to the IANA.

e It’s worth repeating that registering a domain name is entirely independentof acquiring an IP address. You need both in order to construct DNS entriesfor your domain.

1Eight 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 Consor-tium (ISC).

4 May, 2009

Cmpt 471 DNS

e Now that we know the basic structure, let’s delve into the workings of theprotocol.

e An implementation of DNS is divided into two components:

f The resolver is most often implemented as a subroutine library used byclient programs to compose DNS queries and receive answers.

f The name server is a dæmon (named in the Unix world). It listensfor queries at well-known port 53 (UDP and TCP). (Look for domain in/etc/services.)

f UDP is used for most queries and responses. In the special case wherethe entire contents of a DNS database is being transferred (an activitycalled a zone transfer) TCP may be used to avoid datagram size limita-tions and ensure reliable data transfer.

e The most visible use of DNS is to answer queries for the IP address associatedwith a host name. In fact, it handles several other types of information andcould potentially be used as a general key-value service.

e To explain how a query is answered we’ll stick with name to address transla-tion. The resolver composes the query and sends it to one of the DNS serversthat it knows about (call this server the local server).

f For the typical case of a lightweight resolver library dealing with a setof local DNS servers, the local DNS servers will be configured to acceptrecursive queries (defined immediately below) from processes runningon the local workstations.

e If the local server doesn’t know the answer, the question is passed to a serverat a higher level (closer to the root of the DNS name tree). In the absence ofcached information (as explained below), this will be one of the Internet rootservers at the root of the tree. The query is then passed down the tree untilit reaches a server which knows the answer.

f There are two ways in which this can be accomplished, iterative andrecursive.

f In an iterative query, the name server which receives the query will re-spond with the answer or with the name(s) of the name server(s) that itwould consult to find the answer.

f In a recursive query, the name server which receives the query will takeit on itself to send off a query to another name server, if necessary, andwill respond with the final answer.

5 May, 2009

Cmpt 471 DNS

f You can see the process of delegation from the Internet root servers byusing the trace option to the dig command (‘dig +trace name’).

e In a standard configuration, a name server starts off knowing the names andIP addresses of the 13 root servers for the Internet.

f There are only 13 root servers because the designers of DNS decidedthat the DNS records required to answer a query for the name serversfor the ‘.’ domain should fit in a 512 byte UDP datagram2.At one time, this was an actual physical limit. More recently, use of any-cast3 IP addresses has removed the physical limit, and there are nowmany root servers at over 100 geographically distributed locations. Seehttp://www.icann.com/announcements/announcement-08mar07.htmfor an interesting article about a distributed denial-of-service attack onthe Internet root servers on February 6, 2007. The article includes adescription of the Internet root server system.See http://www.icann.org/maps/root-servers.htm for one of sev-eral maps to be found on the Internet.

f DNS servers do not start with more extensive knowledge of servershigher in the DNS name tree because this would imply an obligationby those servers to distribute notifications if they changed their IP ad-dress. Given the expansion at each level of the DNS tree, this is anunreasonable burden. (See, for example, RFC 2826 §1.3.)In particular, and despite a widespread belief to the contrary, a DNSserver does not start life knowing the address of its immediate parentserver in the DNS name tree. (See, for example, RFC 2181 §6.) It will,however, quickly learn the name and IP address of its parent in thenormal course of answering queries.

f As we’ll see, servers must be told the names of the servers for domainsbelow them in the hierarchy. This is what allows a server at a higher levelto 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) parentserver if it changes its IP address.

f A subset of the DNS servers for a domain, called primary servers, mustalso be initialised (from files) with knowledge of hosts within their do-

2The figure of 512 bytes was chosen during the design of the Internet protocols. Adding a64 byte header allowance gives the minimum IP packet size of 576 bytes. Because DNSdefines a compression scheme to limit the repetition of data in DNS messages, it’s notstraightforward to demonstrate that this limits the number of root servers to 13.

3Anycast is a relatively new use of IP addressing and the routing infrastructure whichallows a single IP address to be assigned to many different physical interfaces.

6 May, 2009

Cmpt 471 DNS

main. Typically there is exactly one primary server, to avoid replicationof the data files.

e Efificient operation of the system depends on local caches of DNS records.

f Suppose the resolver on a host contacts a local DNS server with a queryfor the IP address associated with a specific host name.

f When an answer to the query comes back to the local server, it willtypically include not only the address for the specific name given inthe request, but also records for the authoritative name servers for thedomain, plus additional records that are likely to be useful in the nearfuture.

f All the records are cached, along with the answer for the specific host.

f The next time there’s a query for that specific host, the local DNS serverwill answer it from its own cache. The next time there’s a query foran unknown host in the same domain, it’ll be passed directly to thedomain’s name server, using the cached records that specify the DNSservers for the domain.

e That’s our second cut at describing the system. Now, let’s get really specific.

f The reference implementation of DNS is an open source package calledBIND (for Berkeley Internet Name Dæmon), now maintained by the In-ternet Software Consortium. The current release of DNS software isBIND 9.

e We’ll start with the resolver library.

f The resolver doesn’t need to be told very much — just the IP addressesof the DNS servers it should use.

f On unix systems, the place to look is /etc/resolv.conf. It can containthe IP addresses of up to three DNS name servers.

e The name server dæmon is a bit more complicated. The first thing we need tounderstand is the distinction between a primary server, a secondary server,and a cache-only server.

f A primary or master server for a zone initialises its cache from a set offiles that are maintained by a human. These files contain informationabout the hosts in the zone. We haven’t entirely gotten rid of the need fora human to maintain the name to address information, simply parcelledit out into manageable bits.

f A secondary or slave server for a zone initialises its cache from theprimary server for a domain.

7 May, 2009

Cmpt 471 DNS

f Primary and secondary servers are authoritative for a domain. Whenone of them provides an answer, that’s the end of it. The reason forhaving primary and secondary servers is so that the files which are thesource of host information for the domain exist in exactly one place. Theprimary server initialises itself from the files, and then the secondaryservers initialise themselves from the primary server.

f A cache-only server is defined by the absence of primary or secondaryserver status. A cache-only server may be initialised with the names ofthe Internet root servers, or it may be given a short list of name serversto which it will forward all queries.

f All servers, as they receive answers to queries, gradually build the ca-pability to answer more and more queries locally. The reason for havingcache-only servers is efificiency. We might as well accumulate a cache ofinformation close to the workstation. A workstation might run its owncache-only server, or an organisation might provide several, scatteredabout its intranet.

f It’s considered good operational practice to configure authoritative serversso that they do not cache additional information. This improves theirreliability (stability) and protects the integrity of the authoritative infor-mation.

e When a DNS server starts up, it looks for a configuration file. The default filefor unix is typically /etc/named.conf.

f The configuration file can specify lots of options for named, but the im-portant thing we need to know here is that it will contain a set of recordswhich 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 ; }

f We want to know this to understand one of the common conventions ina DNS zone file, which is that the character ‘@’ stands for ‘the currentdomain name’. The initial definition of the current domain name occurswhen named reads domain-name in the configuration file and associatesit with the corresponding zone file.

f Also, keep in mind that all names are interpreted relative to the cur-rent domain unless they are specified as fully-qualified domain names(FQDN).

d A fully qualified domain name ends with a ‘.’, e.g.,‘orion.csil.sfu.ca.’

8 May, 2009

Cmpt 471 DNS

f So, if the configuration file has directed named to read a particular file forthe domain csil.sfu.ca, names in the file will have ‘.csil.sfu.ca.’tacked onto the end unless they already end with a ‘.’.

e To summarize: When named starts, it looks for a configuration file, by de-fault /etc/named.conf. This configuration file contains lines which asso-ciate domain names with data files containing DNS records for that domain.More precisely, each data file contains DNS records for the domain, minusdelegated subdomains, plus ‘glue’ records specifying the name servers for del-egated subdomains. The data files are called zone files because the containinformation for a zone.

e The second chunk of knowledge we need is just what is defined in the DNSrecords.

e There are about 50 DNS resource record (RR) types. We’ll restrict ourselvesto six of them that are the most important in practice in IPv4.

f 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).

f 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 tothe last explicitly specified name.The ttl specifies how long (in seconds) this entry can be cached. If ithasn’t been refreshed within the specified time, it should be deleted. ForDNS, time-to-live has traditionally been relatively long — on the orderof 30 – 40 days — on the theory that host names & related informationdon’t really change all that often. The rise of ISPs and dynamic IPaddress assignment has obviously changed the rules of the game for asubset of DNS records. If ttl is omitted, it defaults to the value given inthe SOA record.The class is always IN, for Internet, as far as we’ll be concerned. It ispossible to use DNS for other classes of information, but it’s not com-mon. 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.) men-tioned above.The data format depends on the type of record.

e The overall organisation of a DNS database initialisation file is a SOA record,which defines the primary DNS server for a domain, followed by a series of

9 May, 2009

Cmpt 471 DNS

other records which define hosts and services in the domain and DNS serversfor subdomains (called points of delegation in DNS terminology).

e The SOA record specifies the host that is the primary server for a zone. Italso provides contact information and time limits for DNS records for thezone. By definition, there is only one SOA record in a zone file.

f The RFCs actually state that the SOA record defines the start of author-ity for a zone.

f The original RFCs are silent on just which server should be named inthe SOA record, but subsequent RFCs (see, for example, RFC 2136 forDynamic DNS) indicate this should be the primary server.A single host may be the primary server for several zones; recall thetext’s example about parallel organisational and geographic domains, orthe SFU example with one host handling multiple domains at the samelevel of the hierarchy. In this case, the host will be named in the SOArecord of several zone files.

f The format for a SOA record in a zone file is

[zone] [ttl] IN SOA origin contact (serialrefreshretryexpireminimum )

All times are in seconds.

f Most commonly, the zone is entered as ‘@’, referring to the domain namespecified in the line in the boot file.

f ttl is commonly omitted in nearly all records, and will default to thevalue given in the SOA record for minimum. Typically, the only reasonfor specifying a different ttl is if a change is anticipated and the admin-istrator wants to make sure the record will not persist in the databaseof other DNS servers.

f The class is IN, as mentioned previously, and the type is SOA.

f origin is the FQDN (fully qualified domain name) of the host which isthe master DNS server for the domain.

f contact is an email address for the person responsible for the adminis-tration of the of the domain. (Note that a ‘.’ replaces the ‘@’ that wouldnormally appear in an email address to separate the user ID from thehost name.)

10 May, 2009

Cmpt 471 DNS

f Each record is nominally a single line. In a DNS zone file, the contin-uation convention is to enclose the data with parentheses ‘()’. Why theorigin and contact aren’t included in the parentheses is unclear — ap-parently, just convention carried through years of illustrative examples.

f serial is a version number. There are many conventions here. Themain thing is that a DNS server be able to compare two serial values asnumbers and decide which is more recent. There are some rather arcanerules here, which you should read carefully if you want to use somethingother than a straight number. (There’s provision, for example, for dottedversion numbers.)

f refresh tells a secondary server the interval at which it should checkwith the primary server and update its database. It decides whetheran update is necessary by comparing the serial number stored withits database with the serial number of the primary’s database. If theprimary’s information is more recent, the secondary will download thenewer database. Typically the refresh interval will be once or twice a dayunless network changes are planned.

f retry is the interval between attempts by the secondary server to contactthe primary server. This is typically set to something on the order of halfan hour to an hour.

f expire is the interval that a secondary server will consider database in-formation to remain valid without receiving a refresh from the primaryserver. On the basis that DNS data tends to be stable, this is set to alarge value — a month to a month and a half. Typically this limit willbe relevant only in the event of catastrophe (e.g., the system adminis-trator is hit by a bus and the primary server goes down while the hiringprocess grinds to completion).

f minimum is the default ttl for a record. This value is important to otherservers which have obtained and cached the record. As with other time-outs, this is set to a value on the order of a few weeks to a month.

e The NS (name server) record defines an authoritative nameserver for a do-main (primary or secondary). The format is

[domain] [ttl] IN NS server

f The domain, ttl, and IN fields are as for SOA.

f The NS code says that this is a name server record.

f server is the host name of the name server.

f When specifying a name server for the current domain, the domain fieldcan be left empty.

11 May, 2009

Cmpt 471 DNS

f The other important use of a NS record is to specify the name serversfor delegated subdomains. This is how a query works its way downfrom the root of the DNS tree to a server for a specific domain. In thiscase, the domain field would contain the name of the subdomain (whichis interpreted within the current domain, i.e., the current domain istacked on the end).

e An A (address) record provides the host to IP address translation information.The format is

[host] [ttl] IN A IP address

f The host name will usually be present (unless this record follows imme-diately after some other record for the host).

f The IP address is specified in the usual dotted decimal form.

e MX (mail exchange) records allow mail to a domain, or to a specific host, tobe directed to a designated host. The format is

[host|domain] [ttl] IN MX preference host

f One can specify multiple mail exchange hosts, in which case a mailerwill try them in order of preference until it finds one that works. Thepreference is an integer, smaller is better.

f The host field specifies the mail exchange host.

e The CNAME (canonical name) record is used to specify alternate names fora host. The format is

nickname [ttl] IN CNAME official name

f The serious purpose of this type of record is to allow various standardnicknames to be mapped to hosts, e.g., loghost, mailhost.

f You can assign as many nicknames to a host as you like (keeping inmind that you’re really assigning nicknames for a particular IP address).

e Recall that the in-addr.arpa domain exists to translate IP addresses backto names. The PTR record is used to specify this inverse translation. Theformat is

IP address [ttl] IN PTR name

12 May, 2009

Cmpt 471 DNS

f The IP address is usually specified relative to the current domain (whichin this case would be the network number).

f The name of the host is specified as a FQDN. In PTR records it must bea FQDN because we certainly don’t want the parser tacking the currentdomain (.in-addr.arpa) onto the end of the name!

e There are a number of other record types — HINFO (host info), WKS (well-known services), and various experimental types — but they’re not common.Some have fallen into disuse due to security concerns, others simply remainexperimental (thus uncommon by definition). And there are new record typesfor IPv6, which we’ll consider in that context.

e To see how this all fits together, here’s an example of DNS configurationand zone files for a fictional domain nuts.com. This example originallyappeared in TCP/IP Network Administration by Craig Hunt, published byO’Reilly and Associates, but has been discontinued in the 3rd edition. It hasbeen rewritten to conform to the syntax introduced with BIND 8.

e Let’s start with the named configuration file, often called named.conf in unixsystems.

/*nuts.com primary name server configuration file.

*/options { directory "/var/named" ; } ;

/* specify the zone files */

zone "nuts.com" {type master ;file "named.hosts" ; } ;

zone "66.128.in-addr.arpa" {type master ;file "named.rev" ; } ;

zone "0.0.127.in-addr.arpa" {type master ;file "named.local" ; } ;

/*‘hint’ is used to initialise the cache with the names of one or more ofthe Internet root servers (the ‘.’ domain).

*/

zone "." {type hint ;file "named.ca" ; } ;

13 May, 2009

Cmpt 471 DNS

There’s a zone file for each of four domains administered by Nuts, Inc. Aswe’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 befound in the files named.rev and named.local. Finally, the file named.cawill contain the information required to contact the Internet root DNS servers.

e Here’s the nuts.com named.hosts file.

; Contact and record lifetime information for nuts.com.

@ IN SOA almond.nuts.com. jan.almond.nuts.com. (10118 ; serial number43200 ; slave refresh interval3600 ; slave retry interval3600000 ; slave db expiry interval2592000 ; 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 is; ‘@’ = ‘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 127.0.0.1

; Hosts in nuts.com domain.

; almond is the logging host, MX record is a courtesy for; some mailer implementations.

almond IN A 128.66.12.1

14 May, 2009

Cmpt 471 DNS

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 26.104.0.19

; MX record here redirects mail even if specifically sent to peanut.

peanut IN A 128.66.12.2IN MX 5 almond.nuts.com.

goober IN CNAME peanut

; more hosts

pecan IN A 128.66.12.3walnut IN A 128.66.12.4filbert IN A 128.66.1.2

; 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 128.66.18.15acorn.sales IN A 128.66.6.1

Remember that both the name and ttl portions of a record are commonlydefaulted by leaving the fields blank.

f For ttl, the default is the value given for the minimum field in the SOArecord.

f For name, the rule is that the last explicitly specified name (‘@’ qualifiesin this respect) remains in effect until explicitly changed. Also keep inmind that names which are not specified as FQDN’s will have the valueof ‘@’ tacked onto the end.

e Here’s the named.rev file.

15 May, 2009

Cmpt 471 DNS

; Address to host name reverse mappings.

@ IN SOA almond.nuts.com. jan.almond.nuts.com. (10118 ; serial number43200 ; slave refresh interval3600 ; slave retry interval3600000 ; slave db expiry interval2592000 ; default ttl for individual records )

; Name servers for 66.128.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 66.128.in-addr.arpa; on the end.

1.12 IN PTR almond.nuts.com.2.12 IN PTR peanut.nuts.com.3.12 IN PTR pecan.nuts.com.4.12 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.

e Here’s the named.local file.

; This file defines the address to host name mapping for this host

@ IN SOA almond.nuts.com. jan.almond.nuts.com. (10118 ; serial number43200 ; slave refresh interval3600 ; slave retry interval3600000 ; slave db expiry interval2592000 ; 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

Cmpt 471 DNS

1 IN PTR localhost.

e And finally, the named.ca file. This is actually the cache file from the Net-work Lab. As you can see, only the names have been changed, to confusethe newcomers.

; This file holds the information on root name servers needed to; initialize the cache of the local name server.

; formerly NS.INTERNIC.NET;. 3600000 IN NS A.ROOT-SERVERS.NET.A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4

; formerly NS1.ISI.EDU;. 3600000 NS B.ROOT-SERVERS.NET.B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107

; formerly C.PSI.NET;. 3600000 NS C.ROOT-SERVERS.NET.C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12

; formerly TERP.UMD.EDU;. 3600000 NS D.ROOT-SERVERS.NET.D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90

; formerly NS.NASA.GOV;. 3600000 NS E.ROOT-SERVERS.NET.E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10

; formerly NS.ISC.ORG;. 3600000 NS F.ROOT-SERVERS.NET.F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241

; formerly NS.NIC.DDN.MIL;. 3600000 NS G.ROOT-SERVERS.NET.G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4

; formerly AOS.ARL.ARMY.MIL;. 3600000 NS H.ROOT-SERVERS.NET.H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53

; formerly NIC.NORDU.NET

17 May, 2009

Cmpt 471 DNS

;. 3600000 NS I.ROOT-SERVERS.NET.I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17

; temporarily housed at NSI (InterNIC);. 3600000 NS J.ROOT-SERVERS.NET.J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10

; housed in LINX, operated by RIPE NCC;. 3600000 NS K.ROOT-SERVERS.NET.K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129

; temporarily housed at ISI (IANA);. 3600000 NS L.ROOT-SERVERS.NET.L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12

; housed in Japan, operated by WIDE;. 3600000 NS M.ROOT-SERVERS.NET.M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33

e Now that we’ve seen how the primary server’s DNS database is establishedfrom files, let’s have a quick look at DNS message types and how they’re usedto communicate between resolver and server, and between servers. We won’tlook at the details of DNS messages, which use a fair bit of optimisation toreduce the number of bytes actually transmitted.

e DNS is, in some ways, a simple protocol. There are queries, and responsesto queries. Originally, there were three types of query: standard (QUERY),inverse (IQUERY), and server status (STATUS). Inverse queries are now ob-solete.

f A header is present in both queries and responses. It specifies the typeof query or response, various control flags, and the size of the remainingsections of the message.

f A query has only one additional section: the ‘question’ section, whichcontains a question record (a domain name, and the type and class ofquery).

f A response has up to three additional sections: answer, authority, andadditional.

f The answer section contains resource records which satisfy the query.(I.e., they matched the specified name, type, and class keys.)

18 May, 2009

Cmpt 471 DNS

The authority section contains resource records which specify an au-thoritative name server for the domain specified in the query.The additional section contains resource records which are related to thequery but not strictly part of the answer (address records, for example,to go with SOA, NS, or MX records).

e Inverse queries were not simply address → name mappings. They provideda general way of performing the reverse mapping from resource to name.Given a resource (in the answer section), the response to an inverse querywould fill the question section with all the names that possess the resource.

f Inverse query support was specified as optional and was never widely im-plemented. It was a difificult service to provide, and there were concernsthat inverse queries could result in huge amounts of data returned inan answer. As network administrators became more security conscious,there were also concerns about the amount of information that could berevealed through inverse queries.

f If all you really want is address → name translation, use a standardquery in the .in-addr.arpa domain.

f Because inverse query support was specified as optional; because theprimary type of ‘inverse’ query was translation of an IP address to a DNSname; and because of the implementation and security issues, inversequeries are ofificially made obsolete by RFC 3425.

Dynamic DNS

e As originally conceived, DNS had a static database of files, and updates weremade by manually editing those files. This seemed a reasonable choice giventhat DNS information was expected to be relatively static.

e That changed as networks grew. But what really broke the ‘relatively static’mold was the introduction of environments like ISPs, ‘drop-in’ networks, andwireless networks, where it was routine to have computers dropping in andout of the network in a time frame measured in minutes.

e Dynamic DNS, defined in RFC 2136, is an extension of the DNS protocolwhich provides for on-line updates.

f The original DNS protocol provided for QUERY, IQUERY, and STATUSmessages.

19 May, 2009

Cmpt 471 DNS

f Dynamic DNS adds the UPDATE message, to allow for online incremen-tal updating of resource records. Without this, the only way to updatethe DNS database for the primary server was to edit a zone file andreload it.

e An UPDATE message specifies what is to be updated and prerequisite condi-tions for applying the update.

f The prerequisite conditions take the form of requirements for the pres-ence or absence of particular resource records or sets of records.

f The update can result in the addition or deletion of one or more records.(Modification is deletion followed by addition.)

f Updates are atomic. All prerequisites are checked for satisfaction, thenall updates are applied. If, for some reason, any individual change fails,the entire update is retracted.

e A program making an update request (a dhcp dæmon, for example) can con-tact any primary or secondary DNS server for the zone it wants to update4.If the server isn’t the master server for the zone, it is obligated to forward therequest to the master server and then forward the response to the originalrequestor.

e Allowing dynamic update introduces all the complications of maintaining adatabase in the presence of concurrent transactions.

f A particularly nasty quirk is that either UDP or TCP can be used torequest an update; the answer is returned by the same protocol.Suppose an UPDATE message delivered by UDP is successfully pro-cessed by the server but the UDP reply is lost. The requestor repeatsthe request. The repeat request fails, because the successful executionof the original request changed the database records in the server andthe prerequisites no longer hold. This time the reply — failure — issuccessfully delivered to the requestor. The server and the requestor arenow inconsistent, because the server’s database has been updated butthe requestor thinks the update has failed.The writers of the RFC recommend the use of TCP if this sort of situationis possible.

4The details as stated in RFC 2136 are more complicated. If a server receiving an updaterequest 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 secondaryservers for a zone.

20 May, 2009

Cmpt 471 DNS

e Security is another big concern if on-line updates are possible.

f One solution is to configure the DNS server so that it will only acceptupdates from a known set of trusted IP addresses.

f A better solution is to use a secured version of the DNS protocol (RFC 2137),or run DNS using a secure version of IP. (For ‘secure’, read ‘encrypted,with authentication’.)

21 May, 2009