LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/HOWTO/DNS-HOWTO-5.html

831 lines
32 KiB
HTML
Raw Blame History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>DNS HOWTO : A simple domain.</TITLE>
<LINK HREF="DNS-HOWTO-6.html" REL=next>
<LINK HREF="DNS-HOWTO-4.html" REL=previous>
<LINK HREF="DNS-HOWTO.html#toc5" REL=contents>
</HEAD>
<BODY>
<A HREF="DNS-HOWTO-6.html">Next</A>
<A HREF="DNS-HOWTO-4.html">Previous</A>
<A HREF="DNS-HOWTO.html#toc5">Contents</A>
<HR>
<H2><A NAME="simple"></A> <A NAME="s5">5. A <EM>simple</EM> domain.</A></H2>
<P><B>How to set up your own domain.</B>
<P>
<H2><A NAME="ss5.1">5.1 But first some dry theory</A>
</H2>
<P>First of all: you read all the stuff before here right? You have
to.
<P>
<P>Before we <EM>really</EM> start this section I'm going to serve you
some theory on and an example of how DNS works. And you're going to
read it because it's good for you. If you don't want to you should at
least skim it very quickly. Stop skimming when you get to what should
go in your <CODE>named.conf</CODE> file.
<P>
<P>DNS is a hierarchical, tree structured system. The top is written
`<CODE>.</CODE>' and pronounced `root', as is usual for tree data-structures.
Under <CODE>.</CODE> there are a number of Top Level Domains (TLDs); the best
known ones are <CODE>ORG</CODE>, <CODE>COM</CODE>, <CODE>EDU</CODE> and <CODE>NET</CODE>, but there
are many more. Just like a tree it has a root and it branches out.
If you have any computer science background you will recognize DNS as
a search tree, and you will be able to find nodes, leaf nodes and
edges. The dots are nodes, the edges are on the names.
<P>
<P>When looking for a machine the query proceeds recursively into the
hierarchy starting at the root. If you want to find the address of
<CODE>prep.ai.mit.edu.</CODE>, your nameserver has to start asking somewhere.
It starts by looking it its cache. If it knows the answer, having
cached it before, it will answer right away as we saw in the last
section. If it does not know it will see how closely it can match the
requested name and use whatever information it has cached. In the
worst case there is no match but the `.' (root) of the name, and the
root servers have to be consulted. It will remove the leftmost parts
one at a time, checking if it knows anything about <CODE>ai.mit.edu.</CODE>,
then <CODE>mit.edu.</CODE>, then <CODE>edu.</CODE>, and if not that it does know about
<CODE>.</CODE> because that was in the hints file. It will then ask a <CODE>.</CODE>
server about <CODE>prep.ai.mit.edu</CODE>. This <CODE>.</CODE> server will not know
the answer, but it will help your server on its way by giving a
referral, telling it where to look instead. These referrals will
eventually lead your server to a nameserver that knows the answer. I
will illustrate that now. <CODE>+norec</CODE> means that dig is asking
non-recursive questions so that we get to do the recursion ourselves.
The other options are to reduce the amount of dig produces so this
won't go on for too many pages:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ ;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 980
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; AUTHORITY SECTION:
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>This is a referral. It is giving us an "Authority section" only, no
"Answer section". Our own nameserver refers us to a nameserver. Pick
one at random:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET.
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 58260
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; AUTHORITY SECTION:
mit.edu. 172800 IN NS BITSY.mit.edu.
mit.edu. 172800 IN NS STRAWB.mit.edu.
mit.edu. 172800 IN NS W20NS.mit.edu.
;; ADDITIONAL SECTION:
BITSY.mit.edu. 172800 IN A 18.72.0.3
STRAWB.mit.edu. 172800 IN A 18.71.0.151
W20NS.mit.edu. 172800 IN A 18.70.0.160
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>It refers us to MIT.EDU servers at once. Again pick one at random:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu.
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 29227
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
prep.ai.mit.edu. 10562 IN A 198.186.203.77
;; AUTHORITY SECTION:
ai.mit.edu. 21600 IN NS FEDEX.ai.mit.edu.
ai.mit.edu. 21600 IN NS LIFE.ai.mit.edu.
ai.mit.edu. 21600 IN NS ALPHA-BITS.ai.mit.edu.
ai.mit.edu. 21600 IN NS BEET-CHEX.ai.mit.edu.
;; ADDITIONAL SECTION:
FEDEX.ai.mit.edu. 21600 IN A 192.148.252.43
LIFE.ai.mit.edu. 21600 IN A 128.52.32.80
ALPHA-BITS.ai.mit.edu. 21600 IN A 128.52.32.5
BEET-CHEX.ai.mit.edu. 21600 IN A 128.52.32.22
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>This time we got a "ANSWER SECTION", and an answer for our
question. The "AUTHORITY SECTION" contains information about which
servers to ask about <CODE>ai.mit.edu</CODE> the next time. So you can ask
them directly the next time you wonder about <CODE>ai.mit.edu</CODE> names.
Named also gathered information about <CODE>mit.edu</CODE>, so of
<CODE>www.mit.edu</CODE> is requested it is much closer to being able to
answer the question.
<P>
<P>So starting at <CODE>.</CODE> we found the successive name servers for each
level in the domain name by referral. 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 digging this out
for you, and it would not have to ask again for a while.
<P>
<P>In the tree analogue each ``<CODE>.</CODE>'' in the name is a branching
point. And each part between the ``<CODE>.</CODE>''s are the names of
individual branches in the tree. One climbs the tree by taking the
name we want (<CODE>prep.ai.mit.edu</CODE>) asking the root (<CODE>.</CODE>) or
whatever servers father from the root toward <CODE>prep.ai.mit.edu</CODE> we
have information about in the cache. Once the cache limits are
reached the recursive resolver goes out asking servers, pursuing
referrals (edges) further into the name.
<P>
<P>A much less talked about, but just as important domain is
<CODE>in-addr.arpa</CODE>. It too is nested like the `normal' domains.
<CODE>in-addr.arpa</CODE> allows us to get the host's name when we have its
address. A important thing to note here is that the IP addresses are
written in reverse order in the <CODE>in-addr.arpa</CODE> domain. If you have
the address of a machine: <CODE>198.186.203.77</CODE> named proceeds to find
the named 77.203.168.198.in-addr.arpa/ just like it did for
<CODE>prep.ai.mit.edu</CODE>. Example: Finding no cache entry for any match
but `.', ask a root server, <CODE>m.root-servers.net</CODE> refers you to some
other root servers. <CODE>b.root-servers.net</CODE> refers you directly to
<CODE></CODE>bitsy.mit.edu/. You should be able to take it from there.
<P>
<P>
<H2><A NAME="ss5.2">5.2 Our own domain</A>
</H2>
<P>Now to define our own domain. We're going to make the domain
<CODE>linux.bogus</CODE> and define machines in it. I use a totally bogus
domain name to make sure we disturb no-one Out There.
<P>
<P>One more thing before we start: Not all characters are allowed in
host names. We're restricted to the characters of the English
alphabet: a-z, and numbers 0-9 and the character '-' (dash). Keep to
those characters (BIND 9 will not bug you if you break this rule, BIND
8 will). Upper and lower-case characters are the same for DNS, so
<CODE>pat.uio.no</CODE> is identical to <CODE>Pat.UiO.No</CODE>.
<P>
<P>We've already started this part with this line in <CODE>named.conf</CODE>:
<P>
<HR>
<PRE>
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
</PRE>
<HR>
<P>
<P>Please note the lack of `<CODE>.</CODE>' at the end of the domain names in
this file. This says that now we will define the zone
<CODE>0.0.127.in-addr.arpa</CODE>, that we're the master server for it and
that it is stored in a file called <CODE>pz/127.0.0</CODE>. We've already
set up this file, it reads:
<P>
<HR>
<PRE>
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR localhost.
</PRE>
<HR>
<P>
<P>Please note the `<CODE>.</CODE>' at the end of all the full domain names in
this file, in contrast to the <CODE>named.conf</CODE> file above. Some people
like to start each zone file with a <CODE>$ORIGIN</CODE> directive, but
this is superfluous. The origin (where in the DNS hierarchy it
belongs) of a zone file is specified in the zone section of the
<CODE>named.conf</CODE> file; in this case it's <CODE>0.0.127.in-addr.arpa</CODE>.
<P>
<P>This `zone file' contains 3 `resource records' (RRs): A SOA RR. A
NS RR and a PTR RR. SOA is short for Start Of Authority. The `@' is a
special notation meaning the origin, and since the `domain' column for
this file says 0.0.127.in-addr.arpa the first line really means
<P>
<BLOCKQUOTE><CODE>
<PRE>
0.0.127.in-addr.arpa. IN SOA ...
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>NS is the Name Server RR. There is no '@' at the start of this
line; it is implicit since the previous line started with a '@'.
Saves some typing that. So the NS line could also be written
<P>
<BLOCKQUOTE><CODE>
<PRE>
0.0.127.in-addr.arpa. IN NS ns.linux.bogus
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>It tells DNS what machine is the name server of the domain
<CODE>0.0.127.in-addr.arpa</CODE>, it is <CODE>ns.linux.bogus</CODE>. 'ns' is a
customary name for name-servers, but as with web servers who are
customarily named <CODE>www.</CODE><EM>something</EM>. The name may be anything.
<P>
<P>And finally the PTR (Domain Name Pointer) record says that the host
at address 1 in the subnet <CODE>0.0.127.in-addr.arpa</CODE>, i.e., 127.0.0.1
is named <CODE>localhost</CODE>.
<P>
<P>The SOA record is the preamble to <EM>all</EM> zone files, and there
should be exactly one in each zone file, at the top (but after the
<CODE>$TTL</CODE> directive). It describes the zone, where it comes from (a
machine called <CODE>ns.linux.bogus</CODE>), who is responsible for its
contents (<CODE>hostmaster@linux.bogus</CODE>; you should insert your e-mail
address here), 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. Before the SOA
comes a mandatory line, the <CODE>$TTL 3D</CODE> line. Put it in all your
zone files.
<P>
<P>Now restart your named (<CODE>rndc stop; named</CODE>) and use <CODE>dig</CODE> to
examine your handy work. <CODE>-x</CODE> asks for the inverse query:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ dig -x 127.0.0.1
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 30944
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 259200 IN PTR localhost.
;; AUTHORITY SECTION:
0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus.
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:02:39 2001
;; MSG SIZE rcvd: 91
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>So it manages to get <CODE>localhost</CODE> from 127.0.0.1, good. Now for
our main task, the <CODE>linux.bogus</CODE> domain, insert a new 'zone'
section in <CODE>named.conf</CODE>:
<P>
<HR>
<PRE>
zone "linux.bogus" {
type master;
notify no;
file "pz/linux.bogus";
};
</PRE>
<HR>
<P>
<P>Note again the lack of ending `<CODE>.</CODE>' on the domain name in the
<CODE>named.conf</CODE> file.
<P>
<P>In the <CODE>linux.bogus</CODE> zone file we'll put some totally bogus
data:
<P>
<HR>
<PRE>
;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
;
NS ns ; Inet Address of name server
MX 10 mail.linux.bogus ; Primary Mail Exchanger
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
;
localhost A 127.0.0.1
ns A 192.168.196.2
mail A 192.168.196.4
</PRE>
<HR>
<P>
<P>Two things must be noted about the SOA record. <CODE>ns.linux.bogus</CODE>
<EM>must</EM> be a actual machine with a A record. It is not legal to
have a CNAME record for the machine mentioned in the SOA record. Its
name need not be `ns', it could be any legal host name. Next,
<CODE>hostmaster.linux.bogus</CODE> should be read as hostmaster@linux.bogus.
This should be a mail alias, or a mailbox, where the person(s)
maintaining DNS should read mail frequently. Any mail regarding the
domain will be sent to the address listed here. The name need not be
`hostmaster', it can be your normal e-mail address, but the e-mail
address `hostmaster' is often expected to work as well.
<P>
<P>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
<CODE>someone@linux.bogus</CODE>, namely to <CODE>mail.linux.bogus</CODE> or
<CODE>mail.friend.bogus</CODE>. The number before each machine name is that
MX RR's priority. The RR with the lowest number (10) is the one mail
should be sent to if possible. If that fails the mail can be sent to
one with a higher number, a secondary mail handler, i.e.,
<CODE>mail.friend.bogus</CODE> which has priority 20 here.
<P>
<P>Reload named by running <CODE>rndc reload</CODE>. Examine the results
with <CODE>dig</CODE>:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ dig any linux.bogus
; &lt;&lt;>> DiG 9.1.3 &lt;&lt;>> any linux.bogus
;; global options: printcmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 55239
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;linux.bogus. IN ANY
;; ANSWER SECTION:
linux.bogus. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
linux.bogus. 259200 IN NS ns.linux.bogus.
linux.bogus. 259200 IN MX 20 mail.friend.bogus.
linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus.
;; AUTHORITY SECTION:
linux.bogus. 259200 IN NS ns.linux.bogus.
;; ADDITIONAL SECTION:
ns.linux.bogus. 259200 IN A 192.168.196.2
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:06:45 2001
;; MSG SIZE rcvd: 184
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Upon careful examination you will discover a bug. The line
<P>
<BLOCKQUOTE><CODE>
<PRE>
linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus.
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>is all wrong. It should be
<P>
<BLOCKQUOTE><CODE>
<PRE>
linux.bogus. 259200 IN MX 10 mail.linux.bogus.
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>I deliberately made a mistake so you could learn from it :-)
Looking in the zone file we find this line:
<P>
<BLOCKQUOTE><CODE>
<PRE>
MX 10 mail.linux.bogus ; Primary Mail Exchanger
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>It 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 its end causing the double <CODE>linux.bogus.linux.bogus</CODE>. So
either
<P>
<HR>
<PRE>
MX 10 mail.linux.bogus. ; Primary Mail Exchanger
</PRE>
<HR>
<P>or
<P>
<HR>
<PRE>
MX 10 mail ; Primary Mail Exchanger
</PRE>
<HR>
<P>is correct. I prefer the latter form, it's less to type. There are
some BIND experts that disagree, and some that agree with this. In a
zone file the domain should either be written out and ended with a
`<CODE>.</CODE>' or it should not be included at all, in which case it
defaults to the origin.
<P>
<P>I must stress that in the named.conf file there should <EM>not</EM> be
`<CODE>.</CODE>'s after the domain names. You have no idea how many times a
`<CODE>.</CODE>' too many or few have fouled up things and confused the h*ll
out of people.
<P>
<P>So having made my point here is the new zone file, with some extra
information in it as well:
<P>
<HR>
<PRE>
;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
;
TXT "Linux.Bogus, your DNS consultants"
NS ns ; Inet Address of name server
NS ns.friend.bogus.
MX 10 mail ; Primary Mail Exchanger
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
localhost A 127.0.0.1
gw A 192.168.196.1
TXT "The router"
ns A 192.168.196.2
MX 10 mail
MX 20 mail.friend.bogus.
www CNAME ns
donald A 192.168.196.3
MX 10 mail
MX 20 mail.friend.bogus.
TXT "DEK"
mail A 192.168.196.4
MX 10 mail
MX 20 mail.friend.bogus.
ftp A 192.168.196.5
MX 10 mail
MX 20 mail.friend.bogus.
</PRE>
<HR>
<P>
<P>
<P>CNAME (Canonical NAME) is a way to give each machine several names.
So www is an alias for ns. CNAME record usage is a bit
controversial. But it's safe to follow the rule that a MX, CNAME or
SOA record should <EM>never</EM> refer to a CNAME record, they should only
refer to something with an A record, so it is inadvisable to have
<P>
<HR>
<PRE>
foobar CNAME www ; NO!
</PRE>
<HR>
<P>but correct to have
<P>
<HR>
<PRE>
foobar CNAME ns ; Yes!
</PRE>
<HR>
<P>
<P>Load the new database by running <CODE>rndc reload</CODE>, which causes
named to read its files again.
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ dig linux.bogus axfr
; &lt;&lt;>> DiG 9.1.3 &lt;&lt;>> linux.bogus axfr
;; global options: printcmd
linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
linux.bogus. 259200 IN NS ns.linux.bogus.
linux.bogus. 259200 IN MX 10 mail.linux.bogus.
linux.bogus. 259200 IN MX 20 mail.friend.bogus.
donald.linux.bogus. 259200 IN A 192.168.196.3
donald.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
donald.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
donald.linux.bogus. 259200 IN TXT "DEK"
ftp.linux.bogus. 259200 IN A 192.168.196.5
ftp.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
ftp.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
gw.linux.bogus. 259200 IN A 192.168.196.1
gw.linux.bogus. 259200 IN TXT "The router"
localhost.linux.bogus. 259200 IN A 127.0.0.1
mail.linux.bogus. 259200 IN A 192.168.196.4
mail.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
mail.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
ns.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
ns.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
ns.linux.bogus. 259200 IN A 192.168.196.2
www.linux.bogus. 259200 IN CNAME ns.linux.bogus.
linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 41 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:12:31 2001
;; XFR size: 23 records
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>That's good. As you see it looks a bit like the zone file itself.
Let's check what it says for <CODE>www</CODE> alone:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$<24>dig www.linux.bogus
; &lt;&lt;>> DiG 9.1.3 &lt;&lt;>> www.linux.bogus
;; global options: printcmd
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 16633
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;www.linux.bogus. IN A
;; ANSWER SECTION:
www.linux.bogus. 259200 IN CNAME ns.linux.bogus.
ns.linux.bogus. 259200 IN A 192.168.196.2
;; AUTHORITY SECTION:
linux.bogus. 259200 IN NS ns.linux.bogus.
;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:14:14 2001
;; MSG SIZE rcvd: 80
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>In other words, the real name of <CODE>www.linux.bogus</CODE> is
<CODE>ns.linux.bogus</CODE>, and it gives you some of the information it has
about ns as well, enough to connect to it if you were a program.
<P>
<P>Now we're halfway.
<P>
<H2><A NAME="ss5.3">5.3 The reverse zone</A>
</H2>
<P>Now programs can convert the names in linux.bogus to addresses
which they can connect to. But also required is a reverse zone, one
making DNS able to convert from an address to a name. This name is
used by a lot of servers of different kinds (FTP, IRC, WWW and others)
to decide if they want to talk to you or not, and if so, maybe even
how much priority you should be given. For full access to all services
on the Internet a reverse zone is required.
<P>
<P>Put this in <CODE>named.conf</CODE>:
<P>
<HR>
<PRE>
zone "196.168.192.in-addr.arpa" {
type master;
notify no;
file "pz/192.168.196";
};
</PRE>
<HR>
<P>
<P>This is exactly as with the <CODE>0.0.127.in-addr.arpa</CODE>, and the
contents are similar:
<P>
<HR>
<PRE>
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; Serial, todays date + todays serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR gw.linux.bogus.
2 PTR ns.linux.bogus.
3 PTR donald.linux.bogus.
4 PTR mail.linux.bogus.
5 PTR ftp.linux.bogus.
</PRE>
<HR>
<P>
<P>Now you reload your named (<CODE>rndc reload</CODE>) and examine your
work with <CODE>dig</CODE> again:
<P>
<HR>
<PRE>
$ dig -x 192.168.196.4
;; Got answer:
;; ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 58451
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;4.196.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus.
;; AUTHORITY SECTION:
196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus.
;; ADDITIONAL SECTION:
ns.linux.bogus. 259200 IN A 192.168.196.2
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:16:05 2001
;; MSG SIZE rcvd: 107
</PRE>
<HR>
<P>
<P>so, it looks OK, dump the whole thing to examine that too:
<P>
<HR>
<PRE>
$ dig 196.168.192.in-addr.arpa. AXFR
; &lt;&lt;>> DiG 9.1.3 &lt;&lt;>> 196.168.192.in-addr.arpa. AXFR
;; global options: printcmd
196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus.
1.196.168.192.in-addr.arpa. 259200 IN PTR gw.linux.bogus.
2.196.168.192.in-addr.arpa. 259200 IN PTR ns.linux.bogus.
3.196.168.192.in-addr.arpa. 259200 IN PTR donald.linux.bogus.
4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus.
5.196.168.192.in-addr.arpa. 259200 IN PTR ftp.linux.bogus.
196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:16:58 2001
;; XFR size: 9 records
</PRE>
<HR>
<P>
<P>Looks good! If your output didn't look like that look for
error-messages in your syslog, I explained how to do that in the first
section under the heading
<A HREF="DNS-HOWTO-3.html#starting">Starting named</A><P>
<H2><A NAME="ss5.4">5.4 Words of caution</A>
</H2>
<P>There are some things I should add here. The IP numbers used in
the examples above are taken from one of the blocks of 'private nets',
i.e., they are not allowed to be used publicly on the Internet. So
they are safe to use in an example in a HOWTO. The second thing is
the <CODE>notify no;</CODE> line. It tells named not to notify its secondary
(slave) servers when it has gotten a update to one of its zone files.
In BIND 8 and later the named can notify the other servers listed in
NS records in the zone file when a zone is updated. This is handy for
ordinary use. But for private experiments with zones this feature
should be off --- we don't want the experiment to pollute the Internet
do we?
<P>
<P>And, of course, this domain is highly bogus, and so are all the
addresses in it. For a real example of a real-life domain see the
next main-section.
<P>
<H2><A NAME="ss5.5">5.5 Why reverse lookups don't work.</A>
</H2>
<P>There are a couple of ``gotchas'' that normally are avoided with
name lookups that are often seen when setting up reverse zones.
Before you go on you need reverse lookups of your machines working on
your own nameserver. If it isn't go back and fix it before
continuing.
<P>
<P>I will discuss two failures of reverse lookups as seen from outside
your network:
<P>
<H3>The reverse zone isn't delegated.</H3>
<P>When you ask a service provider for a network-address range and a
domain name the domain name is normally delegated as a matter of course.
A delegation is the glue NS record that helps you get from one
nameserver to another as explained in the dry theory section above.
You read that, right? If your reverse zone doesn't work go back and
read it. Now.
<P>
<P>The reverse zone also needs to be delegated. If you got the
<CODE>192.168.196</CODE> net with the <CODE>linux.bogus</CODE> domain from your
provider they need to put <CODE>NS</CODE> records in for your reverse zone as
well as for your forward zone. If you follow the chain from
<CODE>in-addr.arpa</CODE> and up to your net you will probably find a break in
the chain, most probably at your service provider. Having found the
break in the chain contact your service-provider and ask them to
correct the error.
<P>
<H3>You've got a classless subnet</H3>
<P>This is a somewhat advanced topic, but classless subnets are very
common these days and you probably have one if you're a small company.
<P>
<P>A classless subnet is what keeps the Internet going these days.
Some years ago there was much ado about the shortage of IP numbers.
The smart people in IETF (the Internet Engineering Task Force, they
keep the Internet working) stuck their heads together and solved the
problem. At a price. The price is in part that you'll get less than
a ``C'' subnet and some things may break. Please see
<A HREF="http://www.acmebw.com/askmrdns/00007.htm">Ask Mr. DNS</A> for an
good explanation of this and how to handle it.
<P>
<P>Did you read it? I'm not going to explain it so please read it.
<P>
<P>The first part of the problem is that your ISP must understand the
technique described by Mr. DNS. Not all small ISPs have a working
understanding of this. If so you might have to explain to them and be
persistent. But be sure you understand it first ;-). They will then
set up a nice reverse zone at their server which you can examine for
correctness with dig.
<P>
<P>The second and last part of the problem is that you must understand
the technique. If you're unsure go back and read about it again.
Then you can set up your own classless reverse zone as described by
Mr. DNS.
<P>
<P>There is another trap lurking here. (Very) Old resolvers will
<EM>not</EM> be able to follow the <CODE>CNAME</CODE> trick in the resolving chain
and will fail to reverse-resolve your machine. This can result in the
service assigning it an incorrect access class, deny access or
something along those lines. If you stumble into such a service the
only solution (that I know of) is for your ISP to insert your PTR
record directly into their trick classless zone file instead of the
trick CNAME record.
<P>
<P>Some ISPs will offer other ways to handle this, like Web based
forms for you to input your reverse-mappings in or other automagical
systems.
<P>
<H2><A NAME="ss5.6">5.6 Slave servers</A>
</H2>
<P>Once you have set up your zones correctly on the master servers you
need to set up at least one slave server. Slave servers are needed
for robustness. If your master goes down the people out there on the
net will still be able to get information about your domain from the
slave. A slave should be as long away from you as possible. Your
master and slave should share as few as possible of these: Power
supply, LAN, ISP, city and country. If all of these things are
different for your master and slave you've found a really good slave.
<P>
<P>A slave is simply a nameserver that copies zone files from a
master. You set it up like this:
<P>
<HR>
<PRE>
zone "linux.bogus" {
type slave;
file "sz/linux.bogus";
masters { 192.168.196.2; };
};
</PRE>
<HR>
<P>
<P>A mechanism called zone-transfer is used to copy the data. The
zone transfer is controlled by your SOA record:
<P>
<HR>
<PRE>
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
</PRE>
<HR>
<P>
<P>A zone is only transferred if the serial number on the master is
larger than on the slave. Every refresh interval the slave will check
if the master has been updated. If the check fails (because the
master is unavailable) it will retry the check every retry interval.
If it continues to fail as long as the expire interval the slave will
remove the zone from it's filesystem and no longer be a server for it.
<P>
<P>
<HR>
<A HREF="DNS-HOWTO-6.html">Next</A>
<A HREF="DNS-HOWTO-4.html">Previous</A>
<A HREF="DNS-HOWTO.html#toc5">Contents</A>
</BODY>
</HTML>
Reference in New Issue View Git Blame Copy Permalink