DNS HOWTO <author>Nicolai Langfeldt <tt>janl@math.uio.no</tt> <date>v1.0, 25 March 1996 <abstract> HOWTO become a totally small time DNS admin. </abstract> <toc> Keywords: DNS, bind, named, dialup, ppp, slip, internet, domain, name, hosts, resolving <bf>Legal mumbo-jumbo:</bf> (C)opyright 1995 Nicolai Langfeldt. Do not modify without amending copyright, distribute freely but retain copyright message. The author wishes to thank Arnt Gulbrandsen who read the drafts to this work countless times and provided many useful suggestions. This will never be a finished document, please send me mail about your problems and successes, it can make this a better HOWTO. So please send money, comments and/or questions to janl@ifi.uio.no. <sect>Introduction.<label id="intro"> <bf>What this is and isn't.</bf> DNS is, to the uninitiated (you ;-), one of the more opaque areas of network administration. This HOWTO will try to make a few things clearer. It describes how to set up a simple DNS name server. For more complex setups you will need to read the Real Documentation. I'll get back to what this Real Documentation consists in <ref id="bigger" name="the last chapter">. Before you start on this you should configure your machine so that you can telnet in and out of it, and make successfuly make all kinds of connections to the net, and you should be able to do <tt>telnet 127.0.0.1</tt> and get your own machine. You also need a good <tt>/etc/host.conf</tt>, <tt>/etc/resolve.conf</tt> and <tt>/etc/hosts</tt> files as a starting point, since I will not explain their function here. If you don't already have all this set up and working the networking/NET-2 HOWTO explains how to set it up. Read it. If you're using SLIP og PPP you need that working. Read the PPP HOWTO if it's not. When I say 'your machine' I mean the macine you are trying to set up DNS on. Not any other machine you might have that's involved in your networking effort. I assume you're not behind any kind of firewall that blocks name queries. If you are you will need a special configuration, see the section on <ref id="misc" name="firewalls and other peculiar net things">. Name serving on Unix is done by a program called <tt/named/ This is a part of the bind package which is coordinated by Paul Vixie for The Internet Software Consortium. <tt/Named/ is included in most Linux distributions and is usualy installed as <tt>/usr/sbin/named</tt>. If you have a named you can probably use it; if you don't have one you can get a binary off a Linix ftp site, or get the latest and greatest source from <htmlurl url="ftp://ftp.vix.com/pub/bin/" name="ftp:ftp.vix.com/pub/bin"> in either the release or testing subdirectory, whatever fits your lifestyle best. DNS is a net-wide database. Take care about what you put into it. If you put junk into it, you, and others will get junk out of it. Keep your DNS tidy and consistent and you will get good service from it. Learn to use it, admin it, debug it and you will be another good admin keeping the net from falling to it's knees overloaded by mismanagement. In this document I state flatly a couple of things that are not completely true (they are at least half truths though). All in the interest of simplification. Things will probably work if you belive what I say. <bf>Tip:</bf> Make backup copies of all the files I instruct you to change if you already have them, so if after going thru this nothing works you can get it back to your old, working state. <sect>A caching only name server.<label id="caching"> <bf>A first stab at DNS config, very useful for dialup users.</bf> A caching only name server will find the answer to name queries and remember the answer the next time you need it. First you need a file called <tt>/etc/named.boot</tt>. This is read when named starts. For now it should simply contain: <code> ; Boot file for nicolais caching name server ; directory /var/named ; ; type domain source file or host cache . root.cache </code> The `<tt/directory/' line tells named where to look for files. All files named subsequently will be relative to this. <tt>/var/named</tt> is the right directory according to the Linux Filesystem Standard. The file named <tt>/var/named/root.cache</tt> is named in this. <tt>/var/named/root.cache</tt> should contain this: <code> ; ---- Root hint cache dump ---- . IN NS A.ROOT-SERVERS.NET . IN NS B.ROOT-SERVERS.NET . IN NS C.ROOT-SERVERS.NET . IN NS D.ROOT-SERVERS.NET . IN NS E.ROOT-SERVERS.NET . IN NS F.ROOT-SERVERS.NET . IN NS G.ROOT-SERVERS.NET . IN NS H.ROOT-SERVERS.NET . IN NS I.ROOT-SERVERS.NET ; ; Prep the cache (hardwire the addresses). Order does not matter ; A.ROOT-SERVERS.NET. IN A 198.41.0.4 B.ROOT-SERVERS.NET. IN A 128.9.0.107 C.ROOT-SERVERS.NET. IN A 192.33.4.12 D.ROOT-SERVERS.NET. IN A 128.8.10.90 E.ROOT-SERVERS.NET. IN A 192.203.230.10 F.ROOT-SERVERS.NET. IN A 39.13.229.241 G.ROOT-SERVERS.NET. IN A 192.112.36.4 H.ROOT-SERVERS.NET. IN A 128.63.2.53 I.ROOT-SERVERS.NET. IN A 192.36.148.17 </code> The file describes the root name servers in the world. This changes over time, see the <ref id="maint" name="maintenance section"> for how to update it. This file is described in the named man page, but is, HMHO, best suited for people that already understand named. Next, you need a <tt>/etc/resolv.conf</tt> looking something like this: <code> search subdomain.your-domain.edu your-domain.edu nameserver 127.0.0.1 </code> The `<tt>search</tt>' line specifies what domains should be searched for any hostnames you want to connect to. The `<tt>nameserver</tt>' line specifies what address your machine can reach a nameserver at, in this case your own machine since that is where your named runs. (Note: Named never reads this file, the resolver that uses named does.) To illustrate what this file does: If a client tries to look up <tt>foo</tt>, <tt>foo.subdomain.your-domain.edu</tt> is tried first, then <tt>foo.your-fomain.edu</tt>, finally <tt>foo</tt>. If a client tries to look up <tt>sunsite.unc.edu</tt>, <tt>sunsite.unc.edu.subdomain.your-domain.edu</tt> is tried first, then <tt>sunsite.unc.edu.your-domain.edu</tt>, and finally <tt>sunsite.unc.edu</tt>. You may not want to put in too many domains in the search line, it takes time to search all the domains. The example assumes you belong in the domain <tt>subdomain.your-domain.edu</tt>, your machine then, is probably called <tt>your-machine.subdomain.your-domain.edu</tt>. The search line should not contain your TLD (Top Level Domain, `<tt/edu/' in this case). If you frequently need to connect to hosts in another domain you can add that domain to the search line like this: <code> search subdomain.your-domain.edu. your-domain.edu. other-domain.com. </code> and so on. Obviosly you need to put real domain names in instead. The last file you have to fix is <tt>/etc/host.conf</tt>. It will probably contain several lines, one should starting with <tt/order/ and it should look like this: <code> order hosts,bind </code> If there is no `<tt/order/' line you should stick one in. It tells the host name resolving routines to first look in <tt>/etc/hosts</tt>, then ask the name server (which you in <tt/resolve.conf/ said is at 127.0.0.1) These two latest files are documented in the resolv(8) manpage (do `<tt/man 8 resolv/'). That man page is IMHO readable, and everyone, especially DNS admins, should read it. Do it now, if you say to yourself "I'll do it later" you'll never get around to it. After all this it's time to start named. Type `<tt>/usr/sbin/named</tt>', and press return, no options. If you're using a dialup connection connect first. Now you can test your setup. If you view your syslog message file (usualy called <tt>/var/adm/messages</tt>) while starting named (<tt>tail -f /var/adm/messages</tt>) you should see something like: <tscreen><verb> Mar 6 23:44:21 roke named[31426]: starting. named 4.9.3-P1 Sat Jan 27 00:36:2 9 MET 1996 janl@roke.slip.ifi.uio.no:/home/janl/bind-4.9.3/named Mar 6 23:44:21 roke named[31426]: cache zone "" loaded (serial 0) Mar 6 23:44:21 roke named[31427]: Ready to answer queries. </verb></tscreen> If there are any messages about errors then there is a mistake named will name the file it is in (one of named.boot and root.cache I hope :-) Kill named and go back and check the named file. At this point we're at a cross roads. If you're using a very recent bind distribution the setup might not work entierly yet. We'll find out when we try to start query it. The program designed for this is nslookup. Start it by giving linux the command `<tt/nslookup/': <tscreen><verb> $ nslookup Default Server: localhost Address: 127.0.0.1 > </verb></tscreen> If that's what you get it's working. If you get this instead: <tscreen><verb> $ nslookup *** Can't find server name for address 127.0.0.1: Non-existent host/domain *** Default servers are not available </verb></tscreen> you need to skip ahead to section the section called <ref id="simple" name="`A Simple domain.'"> and read until you've got two `<tt/primary/' lines in <tt/named.boot/, a file named <tt>pz/127.0.0</tt> and a file <tt>pz/localhost</tt>. Then return here. Now you can enter a query. Try looking up some machine close to you. pat.uio.no is close to me, at the University of Oslo: <tscreen><verb> > pat.uio.no Server: localhost Address: 127.0.0.1 Name: pat.uio.no Address: 129.240.2.50 </verb></tscreen> nslookup now asked your named to look for the machine <tt>pat.uio.no</tt>. It then contacted one of the name server machines named in your <tt>root.cache</tt> file, and asked it's way from there. It might take tiny while before you get the result as it searches all the domains you named in <tt>/etc/resolve.conf</tt>. If you try again you get this: <tscreen><verb> > pat.uio.no Server: localhost Address: 127.0.0.1 Non-authoritative answer: Name: pat.uio.no Address: 129.240.2.50 </verb></tscreen> Note the 'Non-authoritative answer:' line we got this time around. That means that named did not go out on the network to ask this time, it instead looked in it's cache and found it there. But the cached information might be out of date (stale). So you are informed of this (very slight) danger by it saying `Non-authorative answer:'. When <tt/nslookup/ says this the second time you ask for a host it's a sign it caches the information and that it's working. You exit <tt/nslookup/ by giving the command `<tt/exit/'. If you're a dialup (ppp, slip) user please read the <ref id=auto name="section on dialup connections">, there is some advice there for you. Now you know how to set up minimal configuration files for named. <sect>A Simple domain.<label id="simple"> <bf>How to set up your own domain.</bf> Before we really start this section I'm going to serve you some theory on how DNS works. And you're going to read it because it's good for you. If you don't `wanna' you should at least skim it very quickly. Stop skiming when you get to what should go in your <tt>named.boot</tt> file. DNS is a hierarchical system. The top is written `<tt/./' and pronounced 'root'. Under . there are a number of Top Level Domains (TLDs), the best known ones are ORG, COM, EDU and NET, but there are many. When you want to find out the address of <tt/prep.ai.mit.edu/ your name server has to find a name server that serves edu. It asks a <tt/./ server (it already knows the <tt/./ servers, that's what the <tt/root.cache/ file is for), the <tt/./ server gives a list of edu servers. I'll illustrate this here: <tscreen><verb> $ nslookup Default Server: localhost Address: 127.0.0.1 > server c.root-servers.net. Default Server: c.root-servers.net Address: 192.33.4.12 </verb></tscreen> Ask the root server. <tscreen><verb> > set q=ns </verb></tscreen> Set the Query type to NS (name server records). <tscreen><verb> > edu. </verb></tscreen> The trailing . here is significant, it tells the server we're asking that edu is right under ., this narrows the search somewhat. <tscreen><verb> Server: c.root-servers.net Address: 192.33.4.12 edu nameserver = E.ROOT-SERVERS.NET edu nameserver = I.ROOT-SERVERS.NET edu nameserver = F.ROOT-SERVERS.NET edu nameserver = G.ROOT-SERVERS.NET edu nameserver = A.ROOT-SERVERS.NET edu nameserver = H.ROOT-SERVERS.NET edu nameserver = B.ROOT-SERVERS.NET edu nameserver = C.ROOT-SERVERS.NET edu nameserver = D.ROOT-SERVERS.NET E.ROOT-SERVERS.NET internet address = 192.203.230.10 I.ROOT-SERVERS.NET internet address = 192.36.148.17 F.ROOT-SERVERS.NET internet address = 39.13.229.241 G.ROOT-SERVERS.NET internet address = 192.112.36.4 A.ROOT-SERVERS.NET internet address = 198.41.0.4 H.ROOT-SERVERS.NET internet address = 128.63.2.53 B.ROOT-SERVERS.NET internet address = 128.9.0.107 C.ROOT-SERVERS.NET internet address = 192.33.4.12 D.ROOT-SERVERS.NET internet address = 128.8.10.90 </verb></tscreen> This tells us that <tt/*.root-servers.net/ serves <tt/edu./, so we can go on asking <tt/c/. Now we want to know who serves the next level of the domain name: <tt/mit.edu./: <tscreen><verb> > mit.edu. Server: c.root-servers.net Address: 192.33.4.12 Non-authoritative answer: mit.edu nameserver = STRAWB.mit.edu mit.edu nameserver = W20NS.mit.edu mit.edu nameserver = BITSY.mit.edu Authoritative answers can be found from: BITSY.mit.edu internet address = 18.72.0.3 STRAWB.mit.edu internet address = 18.71.0.151 W20NS.mit.edu internet address = 18.70.0.160 </verb></tscreen> <tt/steawb/, <tt/w20ns/ and <tt/bitsy/ serves <tt/mit/, select one and inquire about <tt/ai.mit.edu/: <tscreen><verb> > server W20NS.mit.edu. </verb></tscreen> Hostnames are not case sensitive, but I use my mouse to cut and paste so it gets copied as is from the screen. <tscreen><verb> Server: W20NS.mit.edu Address: 18.70.0.160 > ai.mit.edu. Server: W20NS.mit.edu Address: 18.70.0.160 Non-authoritative answer: ai.mit.edu nameserver = WHEATIES.AI.MIT.EDU ai.mit.edu nameserver = ALPHA-BITS.AI.MIT.EDU ai.mit.edu nameserver = GRAPE-NUTS.AI.MIT.EDU ai.mit.edu nameserver = TRIX.AI.MIT.EDU ai.mit.edu nameserver = MUESLI.AI.MIT.EDU Authoritative answers can be found from: AI.MIT.EDU nameserver = WHEATIES.AI.MIT.EDU AI.MIT.EDU nameserver = ALPHA-BITS.AI.MIT.EDU AI.MIT.EDU nameserver = GRAPE-NUTS.AI.MIT.EDU AI.MIT.EDU nameserver = TRIX.AI.MIT.EDU AI.MIT.EDU nameserver = MUESLI.AI.MIT.EDU WHEATIES.AI.MIT.EDU internet address = 128.52.32.13 WHEATIES.AI.MIT.EDU internet address = 128.52.35.13 ALPHA-BITS.AI.MIT.EDU internet address = 128.52.32.5 ALPHA-BITS.AI.MIT.EDU internet address = 128.52.37.5 GRAPE-NUTS.AI.MIT.EDU internet address = 128.52.32.4 GRAPE-NUTS.AI.MIT.EDU internet address = 128.52.36.4 TRIX.AI.MIT.EDU internet address = 128.52.32.6 TRIX.AI.MIT.EDU internet address = 128.52.38.6 MUESLI.AI.MIT.EDU internet address = 128.52.32.7 MUESLI.AI.MIT.EDU internet address = 128.52.39.7 </verb></tscreen> So <tt/weaties.ai.mit.edu/ is a nameserver for <tt/ai.mit.edu/: <tscreen><verb> > server WHEATIES.AI.MIT.EDU. Default Server: WHEATIES.AI.MIT.EDU Addresses: 128.52.32.13, 128.52.35.13 </verb></tscreen> Now I change query type, we've found the name server so now we're going to ask about everything wheaties knows about <tt/prep.ai.mit.edu/. <tscreen><verb> > set q=any > prep.ai.mit.edu. Server: WHEATIES.AI.MIT.EDU Addresses: 128.52.32.13, 128.52.35.13 prep.ai.mit.edu CPU = dec/decstation-5000.25 OS = unix prep.ai.mit.edu inet address = 18.159.0.42, protocol = tcp #21 #23 #25 #79 prep.ai.mit.edu preference = 1, mail exchanger = life.ai.mit.edu prep.ai.mit.edu internet address = 18.159.0.42 ai.mit.edu nameserver = alpha-bits.ai.mit.edu ai.mit.edu nameserver = wheaties.ai.mit.edu ai.mit.edu nameserver = grape-nuts.ai.mit.edu ai.mit.edu nameserver = mini-wheats.ai.mit.edu ai.mit.edu nameserver = trix.ai.mit.edu ai.mit.edu nameserver = muesli.ai.mit.edu ai.mit.edu nameserver = count-chocula.ai.mit.edu ai.mit.edu nameserver = life.ai.mit.edu ai.mit.edu nameserver = mintaka.lcs.mit.edu life.ai.mit.edu internet address = 128.52.32.80 alpha-bits.ai.mit.edu internet address = 128.52.32.5 wheaties.ai.mit.edu internet address = 128.52.35.13 wheaties.ai.mit.edu internet address = 128.52.32.13 grape-nuts.ai.mit.edu internet address = 128.52.36.4 grape-nuts.ai.mit.edu internet address = 128.52.32.4 mini-wheats.ai.mit.edu internet address = 128.52.32.11 mini-wheats.ai.mit.edu internet address = 128.52.54.11 mintaka.lcs.mit.edu internet address = 18.26.0.36 </verb></tscreen> So starting at <tt/./ we found the successive name servers for the next level in the domain name. If you had used your own DNS server instead of using all those other servers, your named would of-course cache all the information it found while diging this out for you, and would not have to ask again for a while. A much less talked about, but just as important domain is <tt/in-addr.arpa/. It too is nested like the `normal' domains. <tt/in-addr.arpa/ is a hack, a good hack, but still a hack, that alows us to get the hosts name when we have it's address. If you have the address of a machine: 192.128.52.43 named procedes just like for the <tt/prep.ai.mit.edu/ example: find <tt/arpa./ servers. Find <tt/in-addr.arpa./ servers, find <tt/192.in-addr.arpa./ servers, find <tt/128.192.in-addr.arpa./ servers, <tt/find 52.128.192.in-addr.arpa./ servers. Find needed records for <tt/43.52.128.192.in-addr.arpa./ Clever huh? (say `yes'). I have just told a lie. DNS does not work literally the way I just told you. But it's close enough. Now to define our own domain. We're going to make the domain linux.bogus and define machines in it. I use a totally bogus domain name to make sure we disturb no-one Out There. But before we can even start defining our own domain you have to teach your named about localhost. Make the directory <tt>/var/named/pz</tt> (pz for Primary Zone) and place these lines at the end of your <tt/named.boot/ file: <code> primary 0.0.127.in-addr.arpa pz/127.0.0 primary localhost pz/localhost </code> Please note the lack of `<tt/./' at the end of the domain names in this file. The first line names the file <tt>pz/127.0.0</tt> as defining <tt/0.0.127.in-addr.arpa/. This should be the contents: <code> $ORIGIN 0.0.127.IN-ADDR.ARPA. @ IN SOA linux.bogus. hostmaster.linux.bogus. ( 1 ; Serial 360000 ; Refresh 300 ; Retry 3600000 ; Expire 360000 ) ; Minimum NS ns.linux.bogus. 1 PTR localhost. </code> Please note the `<tt/./' at the end of the domain names in this file in contrast to the <tt/named.boot/ file above. This `zone file' contains 3 `resource records' (RRs): A SOA RR. A NS RR nd a PTR RR. SOA is short for Start Of Authority. Before the first record comes a $ORIGIN directive, it is widely considered Good Practice to have a $ORIGIN directive at the start of each zone file. @ is a special notation meaning the origin, so the first line really says <tscreen><verb> 0.0.127.IN-ADDR.ARPA IN SOA ... </verb></tscreen> NS is the Name Server RR, it tells DNS what machine is the name server of the domain. And finaly the PTR record says that 1.0.0.127.IN-ADDR.ARPA (i.e. 127.0.0.1) is named localhost. The SOA record is the preamble to _all_ zone files, and there should be exactly one in each zone file, the very first record. It describes the zone, where it comes from (a machine called <tt/linux.bogus/), who is responsible for its contents (<tt/hostmaster@linux.bogus/), what version of the zone file this is (serial: 1), and other things having to do with caching and secondary DNS servers. For the rest of the fields ,refresh, retry, expire and minimum use the numbers used in this HOWTO and you should be safe. The NS record tells us who does DNS serving for <tt/0.0.127.in-addr.arpa/, it is <tt/ns.linux.bogus/. The PTR record tells us that <tt/1.0.0.127.in-addr.arpa/ (aka 127.0.0.1) is known as <tt/localhost/. The file <tt>pz/localhost</tt> should cointain this: <code> $ORIGIN localhost. @ IN SOA linux.bogus. hostmaster.linux.bogus. ( 1 ; Serial 360000 ; Refresh 300 ; Retry 3600000 ; Expire 360000 ) ; Minimum NS ns.linux.bogus. A 127.0.0.1 </code> If you're skipping ahead from section 2 you can kill and restart your named, then go back to section 2. Now kill and restart your named and use nslookup to examine what you've done: <tscreen><verb> $ nslookup Default Server: localhost Address: 127.0.0.1 > 127.0.0.1 Server: localhost Address: 127.0.0.1 Name: localhost Address: 127.0.0.1 </verb></tscreen> so it manages to get <tt/localhost/ from 127.0.0.1, good. Don't push it, we'll move on to checking <tt/localhost/: <tscreen><verb> > set q=any > localhost. Server: localhost Address: 127.0.0.1 localhost origin = linux.bogus mail addr = hostmaster.linux.bogus serial = 1 refresh = 360000 (4 days 4 hours) retry = 300 (5 mins) expire = 3600000 (41 days 16 hours) minimum ttl = 360000 (4 days 4 hours) localhost nameserver = ns.linux.bogus localhost internet address = 127.0.0.1 localhost nameserver = ns.linux.bogus </verb></tscreen> Looks good. Now for our main task, the <tt/linux.bogus/ domain, insert a new primary line in <tt/named.boot/: <code> primary linux.bogus pz/linux.bogus </code> Note the continued lack of ending `<tt/./' on the domain name in the <tt/named.boot/ file. In the linux.bogus zone file we'll put some totally bogus data: <code> ; ; Zone file for linux.bogus ; $ORIGIN linux.bogus. ; ; Mandatory minimum for a working domain ; @ IN SOA linux.bogus. hostmaster.linux.bogus. ( 199511301 ; serial, todays date + todays serial # 900 ; refresh, seconds 600 ; retry, seconds 3600000 ; expire, seconds 86400 ) ; minimum, seconds ; @ NS ns.linux.bogus. @ NS ns.friend.bogus. ns.friend.bogus. A 127.0.0.10 @ MX 10 mail.linux.bogus ; Primary Mail Exchanger @ MX 20 mail.friend.bogus. ; Secondary Mail Exchanger mail.friend.bogus. A 127.0.0.11 </code> There is one new RR type in this file, the MX, or Mail eXchanger RR. It tells mail systems where to send mail that is addressed to <tt/someone@linux.bogus/, namely too <tt/mail.linux.bogus/ or <tt/mail.friend.bogus/. The number before each machine name is that MX RRs priority, The RR with the lowest number (10) is the one mail should be sent to primarily. If that fails it can be sent to one with a higher number, a secondary mail handler, i.e. <tt/mail.friend.bogus/ which has priority 20 here. Restart named by running <tt>/usr/sbin/named.restart</tt>. Examine the results with nslookup: <tscreen><verb> $ nslookup > set q=any > linux.bogus Server: localhost Address: 127.0.0.1 linux.bogus origin = linux.bogus mail addr = hostmaster.linux.bogus serial = 199511301 refresh = 900 (15 mins) retry = 600 (10 mins) expire = 3600000 (41 days 16 hours) minimum ttl = 86400 (1 day) linux.bogus nameserver = ns.linux.bogus linux.bogus nameserver = ns.friend.bogus linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus linux.bogus preference = 20, mail exchanger = mail.friend.bogus linux.bogus nameserver = ns.linux.bogus linux.bogus nameserver = ns.friend.bogus </verb></tscreen> Upon careful examination you will discover a bug. The line <tscreen><verb> linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus </verb></tscreen> is all wrong. It should be <tscreen><verb> linux.bogus preference = 10, mail exchanger = mail.linux.bogus </verb></tscreen> I deliberately made a mistake so you could learn from it :-) Looking in the zone file we find that the line <code> @ MX 10 mail.linux.bogus ; Primary Mail Exchanger </code> is missing a period. Or has a 'linux.bogus' too many. If a machine name does not end in a period in a zone file the origin is added to it's end. So either <tscreen><verb> @ MX 10 mail.linux.bogus. ; Primary Mail Exchanger </verb></tscreen> or <tscreen><verb> @ MX 10 mail ; Primary Mail Exchanger </verb></tscreen> is correct. I prefer the latter form, it's less to type. In a zone file the domain should either be written out and ended with a `<tt/./' or it should not be included at all, in which case it defaults to the $ORIGIN. I must stress that in the named.boot file there should _not_ be `<tt/./'s after the domain names. You have no idea how many times a `<tt/./' too many or few have fouled up things and confused the h*ll out of people. So having made my point here is the new zone file, with some extra information in it too: <code> ; ; Zone file for linux.bogus ; $ORIGIN linux.bogus. ; ; Mandatory minimum for a working domain ; @ IN SOA linux.bogus. hostmaster.linux.bogus. ( 199511301 ; serial, todays date + todays serial # 900 ; refresh, seconds 600 ; retry, seconds 3600000 ; expire, seconds 86400 ) ; minimum, seconds ; @ NS ns ; Inet Address of name server @ NS ns.friend.bogus. ns.friend.bogus. A 127.0.0.10 @ MX 10 mail ; Primary Mail Exchanger @ MX 20 mail.friend.bogus. ; Secondary Mail Exchanger mail.friend.bogus. A 127.0.0.11 ; ; Extras ; localhost A 127.0.0.1 @ TXT "Linux Bogus, your DNS consultant" ns A 127.0.0.2 MX 10 mail MX 20 mail.friend.bogus. HINFO "Pentium" "Linux 1.2" TXT "RMS" richard CNAME ns www CNAME ns donald A 127.0.0.3 MX 10 mail MX 20 mail.friend.bogus. HINFO "i486" "Linux 1.2" TXT "DEK" mail A 127.0.0.4 MX 10 mail MX 20 mail.friend.bogus. HINFO "386sx" "Linux 1.0.9" ftp CNAME 127.0.0.5 MX 10 mail MX 20 mail.friend.bogus. HINFO "P6" "Linux 1.3.59" </code> There are a number of new RRs here: HINFO (Host INFOrmation) has two parts, it's a good habit to quote each. The first part is the hardware or CPU on the machine and the second part the software or OS on the machine. ns has a Pentium CPU and runs Linux 1.2. The TXT record is a free text record that you can use for anything you like. CNAME (Canonical NAME) is a way to give each machine several names. So richard and www is a alias for ns. It's important to note that A MX, CNAME and SOA record should never refer to an other CNAME record, they should only refer to something with a A record, so it would wrong to have <code> foobar CNAME richard ; NO! </code> but correct to have <code> foobar CNAME ns ; Yes! </code> It's also important to note that a CNAME is not a legal host name for a mail adddress: <tt/webmaster@www.linux.bogus/ is illegal with the setup shown above and you can expect quite a few mail admins Out There to enforce this rule even if it works for you. The way to avoild this is to use A records instead: <code> foobar A 127.0.0.2 </code> Paul Vixie, the primary named wizard, recomends not using CNAME. So consider not using it very seriously. Load the new database by running <tt>/usr/sbin/named.reload</tt>, this causes named to read it's files again. <tscreen><verb> $ nslookup Default Server: localhost Address: 127.0.0.1 > ls -d linux.bogus </verb></tscreen> This means that all records should be listed. <tscreen><verb> [localhost] linux.bogus. SOA linux.bogus hostmaster.linux.bogus. (1995 11301 900 600 3600000 86400) linux.bogus. NS ns.linux.bogus linux.bogus. NS ns.friend.bogus linux.bogus. MX 10 mail.linux.bogus linux.bogus. MX 20 mail.friend.bogus linux.bogus. TXT "Linux Bogus, your DNS consultant" mail A 127.0.0.4 mail MX 10 mail.linux.bogus mail MX 20 mail.friend.bogus mail HINFO 386sx Linux 1.0.9 localhost A 127.0.0.1 www CNAME ns.linux.bogus donald A 127.0.0.3 donald MX 10 mail.linux.bogus donald MX 20 mail.friend.bogus donald HINFO i486 Linux 1.2 donald TXT "DEK" richard CNAME ns.linux.bogus ftp CNAME 127.0.0.5.linux.bogus ftp MX 10 mail.linux.bogus ftp MX 20 mail.friend.bogus ftp HINFO P6 Linux 1.3.59 ns A 127.0.0.2 ns MX 10 mail.linux.bogus ns MX 20 mail.friend.bogus ns HINFO Pentium Linux 1.2 ns TXT "RMS" linux.bogus. SOA linux.bogus hostmaster.linux.bogus. (1995 11301 900 600 3600000 86400) </verb></tscreen> That's good. Let's check what it says for www alone: <tscreen><verb> > set q=any > www.linux.bogus. Server: localhost Address: 127.0.0.1 www.linux.bogus canonical name = ns.linux.bogus </verb></tscreen> ...In other words, the real name of <tt>www.linux.bogus</tt> is <tt>ns.linux.bogus</tt> <tscreen><verb> linux.bogus nameserver = ns.linux.bogus linux.bogus nameserver = ns.friend.bogus ns.linux.bogus internet address = 127.0.0.2 </verb></tscreen> and ns.linux.bogus has the address 127.0.0.2. Looks good too. Of course, this domain is highly bogus, and so are all the addresses in it. For a real domain insert the real domain names and addresses and all the other information. When that is done you need a reverse lookup zone file, it should be like the 127.0.0 file and contain exactly one PTR RR for each address in use, i.e. <tscreen><verb> 127.0.0.2 PTR ns.linux.bogus. 127.0.0.3 PTR donald.linux.bogus. 127.0.0.4 PTR mail.linux.bogus. 127.0.0.5 PTR ftp.linux.bogus. </verb></tscreen> for our example domain (in addition to the SOA RR of-course). Now it's time for you to play around with things and set up your domain. When you've finished playing with the <tt/linux.bogus/ domain remove it from your <tt/named.boot/ file. <sect>DNS and firewalls and other peculiar net things.<label id="misc"> This is really outside the scope of this HOWTO. But I'll give a couple of hints: `forwarders', `slave', and have a look in the litterature list at the end of this HOWTO. <sect>Maintenance<label id="maint"> <bf>Keeping it working.</bf> There is one maintenance task you have to do on nameds, other than keeping them running. That's keeping the <tt/root.cache/ file updated. The easiest way is using dig, first run dig with no arguments, you will get the <tt/root.cache/ according to your own server. Then ask one of the listed root servers with <tt/dig @rootserver/. You will note that the output looks terrebly like a root.cache file except for a couple of extra numbers. Those numbers are harmless. Save it to a file (<tt/dig @e.root-servers.net >root.cache.new/) and replace the old <tt/root.cache/ with it. You can also get the same information using nslookup with <tt/set q=ns/, asking a root server for `<tt/./' will list the root servers, simple editing will render the output in <tt/root.cache/ format. Lastly you can get the latest <tt/root.cache/ from <url url="ftp://rs.internic.net/domain/root.cache" name="ftp:rs.internic.net/domain/root.cache">. You need a new one very seldom, don't get it more than at most once a year, <tt/rs.internic.net/ does not need the extra load from you, and every one else, getting the file once a week. Remember to restart named after replacing the cache file. <sect>Automatic setup for dialup connections.<label id="auto"> This section explains how I have set things up to automate everything. My way might not suit you at all, but you might get a idea from something I've done. Also, I use ppp for dialup, while many use slip or cslip, so almost everything in your setup can be different from mine. But slip's dip program should be able to do many of the things I do. Normaly, when I'm not connected to the net I have a <tt/resolv.conf/ file simply containing the line <tscreen><verb> domain uio.no </verb></tscreen> This ensures I don't have to wait for the hostname resolving library to try to connect to a nameserver that can't help me. But when I connect I want to start my named and have a <tt/resolv.conf/ looking like the one described above. I have solved this by keeping two <tt/resolv.conf/ 'template' files named <tt/resolv.conf.local/ and <tt/resolve.conf.connected/. The latter looks like the <tt/resolve.conf/ described before in this document. To automaticaly connect to the net I run a script called 'ppp-on': <code> #!/bin/sh echo calling... pppd </code> pppd has a file called <tt/options/ that tells it the particulars of how to get connected. Once my ppp connection is up the pppd starts a script called <tt/ip-up/ (this is described in the pppd man page). This is parts of the script: <code> #!/bin/sh interface="$1" device="$2" speed="$3" myip="$4" upip="$5" ... echo 1&2 PPP: IP up cp -v /etc/resolv.conf.connected /etc/resolv.conf ... /usr/sbin/named echo PPP: ip-up finished </code> I.e. I start my named there. When ppp is disconnected pppd runs a script called <tt/ip-down/: <code> #!/bin/sh echo 1>&2 PPP: IP down cp /etc/resolv.conf.local /etc/resolv.conf read namedpid &etago;var/run/named.pid kill $namedpid </code> So this gets things configured and up when connecting and disconfigured and down when disconnecting. Some programs, irc and talk come to mind, make a few too many assumptions, and for irc the dcc features and talk to work right you have to fix your hosts file. I insert have this in my <tt/ip-up/ script: <code> cp /etc/hosts.ppp /etc/hosts echo $myip roke >>/etc/hosts </code> <tt/hosts.ppp/ simply contains <code> 127.0.0.1 localhost </code> and the echo thing inserts the ip# i have received for my host name (roke). It is probably not smart to run named when you are not connected to the net, this is because named will try to send queries to the net and it has a long timeout, and you have to wait for this timeout every time some program tries to resolve a name. If you're using dialup you should start named when connecting and kill it when disconnecting. I have received mail saying it isn't so, but I have not been able to make it work having to wait for long timeouts. Please mail all details if you have better information. <sect>How to become a bigger time DNS admin.<label id="bigger"> <bf>Documentation and tools.</bf> Real Documentation exists. Online and in print. The reading of several of these is required to make the step from small time DNS admin to a big time one. In print the standard book is DNS and BIND by C. Liu and P. Albitz from O'Reilly & Associates, Sebastopol, CA, ISBN 0-937175-82-X. I read this, it's excellent. There is also a section in on DNS in TCP/IP Network Administration, by Craig Hunt from O'Reilly..., ISBN 0-937175-82-X. Another must for Good DNS administration (or good anything for that matter) is Zen and the Art of Motorcycle Maintenance by Robert M. Prisig :-) Available as ISBN 0688052304 and others. Online you will find stuff on <url url="http://www.vix.com/isc/bind.html">; A FAQ, a reference manual (BOG; Bind Operations Guide) as well as papers and protocol definitions and DNS hacks. I have not read most of these, but then I'm not a bigtime DNS admin either. Arnt Gulbrandsen on the other hand has read BOG and he's extatic about it :-). The newsgroup <htmlurl url="news:comp.protocols.tcp-ip.domains" name="comp.protocols.tcp-ip.domains"> is about DNS. In addition there are a number of RFCs about DNS, the most important are probably these: <descrip> <tag/RFC 1713/ A. Romao, Tools for DNS debugging, 11/03/1994. <tag/RFC 1712/ C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, DNS Encoding of Geographical Location, 11/01/1994. <tag/RFC 1536/ A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller, Common DNS Implementation Errors and Suggested Fixes., 10/06/1993. <tag/RFC 1035/ P. Mockapetris, Domain names - implementation and specification, 11/01/1987. <tag/RFC 1034/ P. Mockapetris, Domain names - concepts and facilities, 11/01/1987. <tag/RFC 1033/ M. Lottor, Domain administrators operations guide, 11/01/1987. <tag/RFC 1032/ M. Stahl, Domain administrators guide, 11/01/1987. <tag/RFC 974/ C. Partridge, Mail routing and the domain system, 01/01/1986. </descrip> </article>