####################################################################### Searchable Keywords: DNS dns named named.conf zone secondary Notes How the DNS works Delegated, distributed database Hierarchical layout - The top is called the "root" - no identifier Then come the so-called "top level domains", or TLD - edu, com, org, uk, au, nz, etc Each level below that comes from the level above Hence we can represent it all as a tree A complete reference to a record is provided by listing all the nodes from bottom to the root, in order Lots of types of information available for each record. These include: A - host address CNAME - Canonical name MX - mail exchanger PTR - pointer to other information And several others Three parts to a complete Domain Name System: Program - knows a name, wants the address Resolver - finds addresses for programs Server - has records for names and addresses, and other things (CNAME, MX, etc) How it all works (simple example): 1.Program asks resolver - "what is the address for foo.bar.com?" 2.Resolver doesn't know, asks Name server - "what is the address for foo.bar.com?" 3.Local name server doesn't know, tells resolver "I don't know, but the name server "a.root-servers.net, IP address 1.2.3.4, will have a better idea" 4.Resolver asks NS at 1.2.3.4 "What is the address for foo.bar.com?" 5.NS 1.2.3.4 (a.root-servers.net) says "I don't know, but a.ns.com, IP address 5.6.7.8 will have a better idea" 6.Resolver asks NS at 5.6.7.8 "What is the address for foo.bar.com?" 7.NS 1.2.3.4 (a.ns.com) says "I don't know, but ns.bar.com, IP address 123.234.56.1 will have a better idea" 8.Resolver asks NS at 123.234.56.1 "What is the address for foo.bar.com?" 9.NS 123.234.56.1 (ns.bar.com) says "The address for foo.bar.com is 123.234.56.99" 10.Resolver tells program "The address for foo.bar.com is 123.234.56.99" 11.Program is very pleased, tells resolver that it will get a big present for it's birthday (not really - resolvers don't have birthdays) How it all works (complicated example): In the words of Microsoft and Apple: "You don't need to know." They're right, unless you're writing a Nameserver or Resolver. The process of checking down the hierarchy is the result of delegation. The delegation is composed in terms of zones - areas of the namespace which a server is responsible for. In the example above: root control is held by a.root-servers.net The com namespace is delegated to a.ns.com The bar.com namespace is delegated to ns.bar.com Some of the bar.com namespace may be delegated to other nameservers Namespace delegation does not have to be the same as IP address assignments Several IP portions may come under one NS, and vice versa Any server which contains information (primary or secondary) for a portion of namespace is said to be "authoritative" for that space Primary server - the machine which holds the original file of info for a domain Secondary server - a machine which transfers data from another server (primary or secondary) and is on the NS list for that domain DNS under Linux - BIND The rest of these notes apply only to BIND 8. Those running BIND 4 are out of luck - upgrade. One main config file - /etc/named.conf (/etc/bind/named.conf in Debian) All other config files can be anywhere - as specified in named.conf Format of named.conf - sections, containing config options. All are ; separated (like C) Sections: logging - see documentation options - global configuration options zone - one per primary or secondary zone we are authoritative for acl, key, trusted-keys - security config, see documentation server - config of how we interact with remote servers - see documentation controls - specifying ways to control the nameserver while it's running - see documentation include - Include a specified file at this point - like C 's #include directive We will look at options and zone here. Options This section specifies all global options, and defaults for zone sections. There are a lot of options, but we'll only look at a few here. For the rest, see named.conf(5). directory - The directory which all relative pathnames (ie anything not starting with /) will be relative to forward - either first or only. Sets whether we forward queries on to other nameservers, or work them out ourselves forwarders - Who we will forward to. If there are several, try the query with each one in turn Zone There must be one of these for each zone we are authoritative for (including reverse lookup zones). Typically each zone will list where we get the data from (and store it to), who we will send the data to, and other options. For full information, see named.conf(5). For each zone statement, we must specify the zone which this statement relates to. This is a domain address (without trailing '.') in quotes. For example, zone "foo.domain.edu" is a nice, valid zone definition. The options for the zone are specified in { } after the zone definition. See the example config files for detailed syntax. type - one of master, slave, stub, forward, or hint. master and slave are obvious enough - specify we are a master or slave server for the zone. forward tells the NS to just pass any queries for the zone onto another server (use forwarders option for that), stub we won't go into, and hint gives the initial root servers list which we will use to get a real root servers list. file - the filename (either relative to directory or absolute) where the data for this zone is stored. For primary zones, this is where the data is, and for secondary zones, this is where it will be stored. allow-transfer - A list of addresses from which we will accept requests to transfer zones from. allow-update - A list of addresses from which we will accept updates to the DNS information. Useful for dynamic DNS, but that's it. allow-query - Who we will allow to ask about this zone notify - Will we tell the secondary servers we've updated? notify-also - A list of hosts which aren't secondary servers for this zone who we will also tell about updates Zone files The major part of setting up a DNS is making the zone files. You need to do this for: The localhost lookup localhost reverse lookup Every zone for which you are primary reverse lookup for every zone for which you are primary A zone file consists of a group of resource records (RRs) of various types. I'll go through a few common types then see how to put them together. SOA - Start Of Authority. Stores data on the domain name, who is responsible for it (e-mail address), and various timeout parameters. The arguments are: Primary nameserver for the domain E-mail address of the person responsible for the domain, with the '@' replaced by a '.' Serial number for this revision of the zone file refresh time - how long the secondaries should wait between updates from the primary retry time - if the secondary cannot connect to the primary initially when trying for a new zone file, how long to wait between connection attempts expire - if we haven't updated from the server in this long, we have to remove the data minimum - the minimum amount of time before the data will expire from caches All of the time values are specified in seconds. A - Address. The address for the specified host or domain in the appropriate format for the network type. IP address for us. MX - Mail Exchanger. Specifies data for how mailers should attempt to deliver mail to a host or domain. CNAME - Canonical name. Specifies the 'real' or canonical name for an alias. PTR - Pointer. Points to another record. Used for reverse lookups. HINFO - Machine and OS records for a host. TXT - textual information associated with a host. The format for a single RR is as follows: Name Address class (use IN for Internet) Data type Data each data item goes on a new line. To split an RR over several lines, use parenthese (common in SOAs). For examples on how to do all of these, look at the various examples. References RFC1033 RFC1034 RFC1035 RFC974 named.conf(5) http://eeunix.ee.usm.maine.edu/guides/dns The DNS-HOWTO The BIND 8 configuration file documentation <<<<<<<<<<<<<<<<<<<<<<<< /etc/named.conf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The configuration file Once you have your zone files in order, you can alter the configuration file to suit your particular file system. In BIND 8.x, the named configuration file is called named.conf. It is stored in the /etc directory. BIND 8 is flexible about the comments it accepts. This means that lines in the configuration file that look like: /* This is a comment line */ // This is a comment line # This is a comment line will be interpreted as comments and therefore will be ignored. The first modification you'll need to make is to tell named where to find the zone files you just created. You can store these anywhere in the file system, however many people choose to store them somewhere in the /usr or /var directories. As long as you identify their location in named.conf, anywhere will do just fine. # BIND 8 config file options { directory "/usr/localstructure/named"; # Place other options here. }; zone "test.k12.mi.us" in { type master; file "db.test"; }; zone "210.234.123.in-addr.arpa." in { type master; file "db.123.234.210"; }; zone "0.0.127.in-addr.arpa" in { type master file "db.127.0.0"; }; zone "." in { type hint; file "db.cache"; }; <<<<<<<<<<<<<<< Build a secondary DNS (slave) >>>>>>>>>>>>>>>>>>>>>>>>>> In the configuration file, you will need to move it to the /etc directory on the slave computer and make the following modifications: 1.In the options statement, you must change the path name to point to the directory that holds the zone files. 2.In the "zone" statements for the name-to-address and address-to-name files, you must change the "type" statements to "slave." You must also add a line that points to the master name server(s), along with the master's IP address. This information will be used when the slave attempts to do a zone transfer. Building on our previous example, a secondary server's etc/named.conf file would look like this: options { directory "/usr/local/named"; # Place other options here. }; zone "test.k12.mi.us" in { type slave; file "db.test"; masters { 123.234.210.1; }; }; zone "210.234.123.in-addr.arpa." in { type slave; file "db.123.234.210"; masters { 123.234.210.1; }; }; zone "0.0.127.in-addr.arpa" in { type master file "db.127.0.0"; }; zone "." in { type hint; file "db.cache"; }; It's OK to leave the zone configuration information for the loopback file designated as a master, and you don't need to make any changes in the cache file, either. These files are the same, whether they are on a master or slave server, so local copies of these files can be kept on the slave server in the interest of saving time and effort during a zone transfer. There! The files you need to run a secondary name server are now located on the slave server, and with any luck, they're properly configured. To run your slave server, simply start named. (Type /etc/named at the command prompt.) To start named, you must have root privileges. Once named is running, look in the directory where you keep your zone files to see if backup copies of your name-to-address and address-to-name files have been created. If so, that indicates that your secondary has successfully pulled the zone files from the master name server. NOTE: After you make changes to any of the primary zone files ALWAYS increment the Serial number. This will allow for an automatic update to your secondary DNS server once the TTL(time to live) has expired. Once the TTL is up it should go to the primary and uodate itself. To force a update to the secondary. Move(mv) the directory that the zone files reside in to something like zones.old and recreate an empty zones diretory. Then stop and start named on the secondary. The secondary should read the /etc/named.conf file which says go to the primary and retrieve zone files. A good site for plain old good DNS info is.............. http://supportnet.merit.edu/m-spectop/t-dns/setup.html alot of this info came from there. <<<<<<<<<<<<<<<<< map domain.com to www.domain.com >>>>>>>>>>>>>>>>>> Purpose: so you can put either domain.com or www.domain.com and still end on the same page. As straightforward as this may seem there is an absolute order this is to be done in. Typical forward lookup DNS file. # more db.mydomain.com $TTL 86400 @ IN SOA myhost.mydomain.com. root.mydomain.com. ( 200110067 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum NS rachel.mydomain.com. MX 10 pingy.mydomain.com. TXT "My Domain" localhost A 127.0.0.1 vmnet0 A 192.168.1.1 internal A 192.168.2.1 bsd-rtr A 192.168.2.2 alderon A 192.168.1.3 rachel A 192.168.1.6 mydomain.com. A 192.168.1.5 <-------- create "A" record for domain first www.mydomain.com. CNAME mydomain.com. <------ point alias to domain name Update the serial number and HUP named. The results of a nslookup should look like some below. NOTE: you CAN NOT create the "A" record for www.mydomain.com and alias the mydomain.com to it. This error out. Also, note the "periods" at the end of the FQDNs # nslookup mydomainn.com Server: rachel.mydomain.com Address: 192.168.1.6 Name: mydomain.com Addresses: 192.168.1.5, 192.168.1.6 --------------------------------------------------------------------- Building a Stealthed master To build a stealth master, your servers contain master zones files for your domain names. Your hosting provider's DNS boxes are then slaved to your masters in your providers named.conf file. However, the NS records for your domains only reference your provider's DNS servers, not yours at your your registar. The end result is that all DNS queries are handled by your hosting provider, yet you retain complete control over the domain records -- when you make a change on your DNS server, notices are sent to the hosting provider's servers and are updated nearly instantly. The only draw back is that your registar is tied to your provider. What hapeens if you have multiple providers or change providers ? If yo don't want to manage DNS. Contact a DNS provider. They will do it all. ( Neustar ). #------------------------- trouble shooting --------------------------# o Whenever I start up my Named server the following error > shows up in the syslog, no Default TTL set using SOA > minimum instead. or Sep 5 23:57:32 rachel named[7580]: Zone "1.168.192.in-addr.arpa" (file zone/1.1 68.192): No default TTL set using SOA minimum instead try this in your zone files..................... -- File: db.127.0.0 $TTL 86400 <--------- This whats added. This variable sets the minium TTL @ IN SOA ns.promedia.com. root.ns.promedia.com. ( 20010125 ; Serial 8H ; Refresh 2H ; Retry 1W ; Expire 8H) ; Minimum TTL IN NS ns.promedia.com. 1 IN PTR localhost. -- Attached file included as plaintext by Listar -- -- File: db.192.168.1 $TTL 86400 @ IN SOA ns.promedia.com. root.ns.promedia.com. ( 20010125 ; serial 8H ; refresh 2H ; retry 1W ; expire 8H ) ; minimum TTL ............................etc #---------------------------------------------------------------------# !!!! You changed the name of your name server or you change domain names !!!! DON'T FORGET TO UPDATE THE RESOLV.CONF FILE AND MAKE SURE THE DOMAIN FILE HAS THE CORRECT DOMAIN LISTED #------------------ forwarding and forwarders ----------------------# What Are Forwarders? A forwarder provides a way to keep off-site DNS traffic to a minimum by allowing you to designate a name server that handles inquiries for other name servers. Off-site queries are sent first to the forwarder, which caches the response information. Then the forwarder attempts to answer future queries from information already in its cache. When selecting a name server to designate as a forwarder, make sure that you (or your staff) have control over the server. Otherwise, if zone data is corrupted on the host indicated in the forwarders line, you have no way to prevent the other name server from acquiring the same corrupted data. If control of the system is not available, the corrupted data stays that way until the other host is fixed. How Do You Add Forwarders? To add a forwarder, add a forwarders line to the DNS configuration on all the other servers at your site to direct them to send their queries through the designated forwarder. The DNS configuration on the forwarder itself is not modified. To add a forwarders line, follow these steps. 1. Using a text editor, add a forwarders statement to the optoins section of the DNS configuration file /etc/named.conf that includes the IP address of the DNS server or servers to which name server requests are forwarded. For example, to add two servers with IP addresses 192.1.1.98 and 192.1.1.99 as forwarders for your network, the forwarders line would be: forwarders { 192.1.1.98; 192.1.1.99; }; 2. Once the forwarders line is added, restart the master server: ------------------------------------------------------------------------------ RECURSION Recursion does have its security problems although in order for your local clients to do forward/reverse lookups you have to have recursion on . By default it is on. You can turn it off with the line recursion no ; in the options section at the top of the /etc/named.conf The syntax for that recursion line you have to be careful of. Its a bracketed statement inside a bracketed statement. I tried putting comments around the recursion and forwarders statements but thats exactly what kept hosing my named. When I restarted named and did a nslookup( I know it's depreciated ) I got the message........... osal% nslookup *** Can't find server name for address 192.168.10.5: Server failed Default Server: ns1.leftlogical.net Address: 192.168.10.6 The clue here is the "Can't find server...." that is the first DNS server this host should be using not the one that show up under "Default Server". The recursion line I ended up using was. allow-recursion { 127.0.0.0/8;192.168.10.0/24; 192.168.20.0/24; 10.10.30/2 4; }; It appears to work. ===================================================================== TTL. refresh, minimum TTL, expire.............. This would be part of the header for each zone file( 1.168.19 ) ( the actual numbers of course would more than likely be different ) 200110055 ; serial 28800 ; refresh (8 hours) 14400 ; retry (4 hours) 3600000 ; expire (5 weeks 6 days 16 hours) 86400 ; minimum (1 day) ===================================================================== See also, Solaris_notes on DNS for reference