1 CMPT 471 Networking II DNS © Janice Regan,

2 Database / authoritative servers  When a authoritative master or slave DNS server is initialized it loads a configuration file which associates domain names with data files containing DNS resource records for that domain  For linux systems that file is usually /etc/named.conf, configuration for the DNS daemon named. This file will be present only on hosts running DNS servers  Next we need to look at what is in the files referred to in the configuration file. There will be one file for each domain this DNS server serves.

© Janice Regan, Format of resource records  The detailed format depends on the particular resource record, but all resource records follow the pattern  name ttl class type data  The first two items may be omitted, name defaults to the last specified name ttl defaults to the value given in the SOA record  Class is usually IN for internet  Type is a code from the RFC (A, SOA, MX, PTR)  Data depends on the type of record

© Janice Regan, Organization of DNS data file  Remember domain names are case insensitive  All records start in the first column of the file  The usual order for records in the file is  $TTL: set time to live (bind 8 and later only)  SOA record: indicates authority for the zone  NS record: gives a name authoritative name servers for the zone  Other records giving data on hosts in the zone A: Name to address mapping records PTR: Address to name mapping records CNAME: canonical name data (aliases)

© Janice Regan, SOA record  zone IN SOA primarymasterNS contact ( serial refresh time retry time expire time negative caching ttl )  Zone, primarymasterNS and contact must be fully qualified domain names ending in.  The contact is the mail address of the contact assuming that the first. in the domain name is replaced  The parentheses allow the record to span more than one line

© Janice Regan, SOA record fields  serial is a serial number indicating the age of the data file (last update). Used when a slave server contacts the master server. The slave will update its database if the serial number indicates its database is older that the master’s.  Serial is incremented each time data in the DNS database is changed  You should use a tool to update your DNS database, this will prevent you from forgetting to update serial  refresh gives the interval at which the slave server should check with the master server to determine if an update is needed (RFC 1537 recommends 24 hours)  An update is needed if the serial number of the master server's data base is larger than the serial number of the slave server's

© Janice Regan, SOA record fields  Retry: if the slave cannot reach the master at the end of a refresh interval, it will retry after the interval specified in the retry field (recommended 2 hours)  Expire: If the slave fails to contact the master within the expire interval the slave stops giving answers about the zone. (recommended 30 days)

© Janice Regan, SOA record fields: TTL  For BIND versions before version 8 the TTL was set using the last field in the SOA record  For versions 8 and above of BIND the final field is used for the negative caching TTL, the time a remote name server can cache negative responses about our zone (non existent hosts)  In v8 and above the TTL is set using the $TTL statement.  $TTL 3h indicates a TTL of 3 hours  RFC 1537 recommends a default TTL of 4 days  Server supplies TTL in query responses, telling the server receiving the response how long it may cache the information.

© Janice Regan, Nameserver records  One record for each authoritative DNS name server for the zone is added to the zone file  Zone IN NS nameserver  Zone and nameserver must be fully qualified domain names ending in.  Nameservers should be well connected (stable, accessible)  One record for each name to address mapping. Each interface on a multihomed host must have its own record  Hostname IN A IPaddress  Hostname must be a fully qualified domain name Address records

© Janice Regan, Alias records  One record for each alias for a given host  hostalias IN CNAME hostname OR hostname IN A IPaddress  hostname and hostalias must be fully qualified domain names ending in.  Do not use aliases in the data portion of the database file (  A server will replace the alias with the canonical name then look up the canonical name (both returned)  The second form can be used to differentiate between multiple interfaces on a single host  The first form will choose one of the multiple interfaces according to a simple algorithm (alternate, first in list, …)

© Janice Regan,  One record for each address to name mapping. Each interface on a multihomed host must have its own record  Arpaaddress IN PTR hostname  hostname must be a fully qualified domain name  Arpaaddress must have the form in-addr.arpa.  Arpaaddress of host is in-addr.arpa. PTR records

© Janice Regan, Example from Albitz + Liu  We are making the database files for a DNS server on the machine terminator.movie.edu. This DNS server will serve zone movie.edu  terminator has two network interfaces one on network /24, and one on /24.  Since a DNS server must also service inverse queries we must also service the zones  in-addr.arpa  in-addr.arpa  We will need to make an initialization file for each of these zones. These files will be db.movie.edu, db , and db

© Janice Regan, Examples: resource records bigt.movie.edu IN CNAME terminator.movie.edu in-addr.arpa. IN PTR carrie.movie.edu  The second number in the first three records is the TTL, this is often omitted when records are input but appears in output of dig and other resolvers. isc.org IN NS ns-ext.lga1.isc.org. ns-ext.lga1.isc.org IN A

© Janice Regan, server data file db.movie.edu: 1 $TTL 3h Movie.edu. IN SOA terminatior.movie.edu. al.robocob.movie.edu.( 1; Serial 3h; Refresh after 3 hours 1h; Retry after 1 hour 1w ; Expire after 1 week 1h ); Negative caching TTL 1 hour ; ; Name servers ; Movie.edu. IN NS terminator.movie.edu. Movie.edu. INNSwormhole.movie.edu. : :Addresses ; Localhost.movie.edu.IN A robocop.movie.edu.IN A terminator.movie.edu.IN A

© Janice Regan, server data file db.movie.edu: 2 diehard.movie.eduIN A misery.movie.eduIN A shining.movie.eduIN A carrie.movie.eduIN A Wormhole.movie.edu.INA Wormhole.movie.edu.INA : :Aliases ; bigtt.movie.eduIN CNAME terminatior.movie.edu. dh.movie.eduIN CNAME diehard.movie.edu. wh.movie.eduIN CNAME wormhole.movie.edu. ; ; Interface specific names ; Wh249.movie.edu.INA Wh253.movie.eduINA

Aliases  The CNAME is used to look up the name of the host (not the alias)  Then the name is looked up to find the requested information describing the host  Requesting the information for a dns name for a multihomed host will return all information regarding all interfaces of the multihomed host (in a list)  If we ping, or execute another command that does a dns lookup it will use the first name in the list (which one is it?) not the interface we want. We also need interface specific names © Janice Regan,

© Janice Regan, server data file, db $TTL 3h in-addr.arpa..IN SOA terminatior.movie.edu. al.robocob.movie.edu.( 1; Serial 3h; Refresh after 3 hours 1h; Retry after 1 hour 1w ; Expire after 1 week 1h ); Negative caching TTL 1 hour ; ; Name servers ; in-addr.arpa. IN NS terminator.movie.edu in-addr.arpa. INNSwormhole.movie.edu. ; :Addresses point to canonical name ; in-addr.arpa. IN PTRwormhole.movie.edu. 2, in-addr.arpa. IN PTR robocop.movie.edu in-addr.arpa. IN PTR terminator.movie.edu in-addr.arpa. IN PTR diehard.movie.edu.

© Janice Regan, Server data file, db $TTL 3h in-addr.arpa..IN SOA terminatior.movie.edu. al.robocob.movie.edu.( 1; Serial 3h; Refresh after 3 hours 1h; Retry after 1 hour 1w ; Expire after 1 week 1h ); Negative caching TTL 1 hour ; ; Name servers ; in-addr.arpa. IN NS terminator.movie.edu in-addr.arpa. INNSwormhole.movie.edu. ; :Addresses point to canonical name ; in-addr.arpa. IN PTRwormhole.movie.edu. 2, in-addr.arpa. IN PTR misery.movie.edu in-addr.arpa. IN PTR shining.movie.edu in-addr.arpa. IN PTR carrie.movie.edu.

© Janice Regan, Comments on the example  Aliases, alternate names for particular domains, can be implemented in different ways  Using a CNAME record. A CNAME record maps a alias onto its canonical name. A nameserver replaces the alias with the canonical name.  In a multihomed system we can have a name for each interface of the system, we do not want these names to be aliases. The name and address of each interface will be in a separate address record.  Using an additional address record to define an alias that are not due to multiple interfaces may confuse the sendmail or require additional configuration to make sure in understands all possible aliases

© Janice Regan, Root Hints Data  In addition to your local data you need to know where the name servers for the root zone are  Remember every DNS server needs to know the addresses of the root server  Download a copy of named.root from the root zone servers (ftp.rs.internic.net, ) to make sure your list of root server information is currentftp.rs.internic.net  The names and addresses of the root servers are stored in this file which should be renamed db.cache to prepare it for use

© Janice Regan, Sample contents of db.cache INNSA.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET A ; INNSB.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET INA ; INNSC.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET INA ; ; more similar entries ; INNSM.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET INA

© Janice Regan, Configuration File  The nameserver needs to be instructed to read all of the data files we have constructed  The file containing these instructions is the configuration file in  /etc/named-boot (BIND 4)  src/bin/named-bootconf (BIND 8)  contrib/named-bootconf (BIND 9)

© Janice Regan, Configuration file format ;BIND 4 configuration file Directory /var/named ;Directory contains the zone data files primarymovie.edudb.movie.edu primary in-addr.arpadb primary in-addr.arpadb primary in-addr.arpadb cache.db.cache

© Janice Regan, Configuration file format (1) // BIND configuration file options{ directory “/var/named”; // additional options }; zone “movie.edu”{ type master; file “db.movie.edu”; }; zone “ in-addr.arpa”{ type master; file “db ” };

© Janice Regan, Configuration file format (1) zone “ in-addr.arpa”{ type master; file “db ” }; zone “ in-addr.arpa”{ type master; file “db ” }; zone “.”{ type hint; file “db.cache” };

© Janice Regan, Configuration file format (1) // BIND configuration file for slave server options{ directory “/var/named”; // additional options }; zone “movie.edu”{ type slave; file “bak.movie.edu”; masters{ ; } }; zone “ in-addr.arpa”{ type slave; file “bak ” masters{ ; } };

© Janice Regan, Configuration file format (1) zone “ in-addr.arpa”{ type slave; file “bak ” masters{ ; } }; zone “ in-addr.arpa”{ type master; file “db ” }; zone “.”{ type hint; file “db.cache” };

© Janice Regan, Tools  Tools to help an administrator set up these files are available  Can make the zone data files using h2n which generates files based on your /etc/hosts file

© Janice Regan, Slave servers  Entries in the configuration of the form zone “movie.edu”{ type slave; masters{ }; file “bak.movie.edu”; };  Can have multiple levels of slaves (slaves using other slaves as masters) but it does take longer for updates

© Janice Regan, Caching only nameserver  Not authoritative for any domain (except in-addr.arpa)  Needs a root hints file  Configuration file contains only options, zone “ in-addr.arpa”, and zone “.”