How to set up your own domain.
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 skimming when you get to what should go in your
named.conf
file.
DNS is a hierarchical system. The top is written `.
' 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 more.
When looking for a machine the query proceeds recursively into the
hierarchy starting at the top. If you want to find out the address of
prep.ai.mit.edu
your name server has to find a name server that
serves edu. It asks a .
server (it already knows the .
servers, that's what the root.hints
file is for), the .
server gives a list of edu servers:
$ nslookup
Default Server: localhost
Address: 127.0.0.1
Start asking a root server:
> server c.root-servers.net.
Default Server: c.root-servers.net
Address: 192.33.4.12
Set the Query type to NS (name server records):
> set q=ns
Ask about edu:
> edu.
The trailing . here is significant, it tells the server we're asking that edu is right under . (this narrows the search somewhat).
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
edu nameserver = E.ROOT-SERVERS.NET
edu nameserver = I.ROOT-SERVERS.NET
edu nameserver = F.ROOT-SERVERS.NET
edu nameserver = G.ROOT-SERVERS.NET
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
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 = 192.5.5.241
G.ROOT-SERVERS.NET internet address = 192.112.36.4
This tells us that *.root-servers.net
serves edu.
, so we
can go on asking c
. Now we want to know who serves the next
level of the domain name: mit.edu.
:
> mit.edu.
Server: c.root-servers.net
Address: 192.33.4.12
Non-authoritative answer:
mit.edu nameserver = W20NS.mit.edu
mit.edu nameserver = BITSY.mit.edu
mit.edu nameserver = STRAWB.mit.edu
Authoritative answers can be found from:
W20NS.mit.edu internet address = 18.70.0.160
BITSY.mit.edu internet address = 18.72.0.3
STRAWB.mit.edu internet address = 18.71.0.151
steawb
, w20ns
and bitsy
serves mit
, select one and
inquire about ai.mit.edu
:
> server W20NS.mit.edu.
Host names are not case sensitive, but I use my mouse to cut and paste so it gets copied as-is from the screen.
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 = 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
ai.mit.edu nameserver = LIFE.AI.MIT.EDU
ai.mit.edu nameserver = BEET-CHEX.AI.MIT.EDU
ai.mit.edu nameserver = MINI-WHEATS.AI.MIT.EDU
ai.mit.edu nameserver = COUNT-CHOCULA.AI.MIT.EDU
ai.mit.edu nameserver = MINTAKA.LCS.MIT.EDU
Authoritative answers can be found from:
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
AI.MIT.EDU nameserver = LIFE.AI.MIT.EDU
AI.MIT.EDU nameserver = BEET-CHEX.AI.MIT.EDU
AI.MIT.EDU nameserver = MINI-WHEATS.AI.MIT.EDU
AI.MIT.EDU nameserver = COUNT-CHOCULA.AI.MIT.EDU
AI.MIT.EDU nameserver = MINTAKA.LCS.MIT.EDU
ALPHA-BITS.AI.MIT.EDU internet address = 128.52.32.5
GRAPE-NUTS.AI.MIT.EDU internet address = 128.52.36.4
TRIX.AI.MIT.EDU internet address = 128.52.37.6
MUESLI.AI.MIT.EDU internet address = 128.52.39.7
LIFE.AI.MIT.EDU internet address = 128.52.32.80
BEET-CHEX.AI.MIT.EDU internet address = 128.52.32.22
MINI-WHEATS.AI.MIT.EDU internet address = 128.52.54.11
COUNT-CHOCULA.AI.MIT.EDU internet address = 128.52.38.22
MINTAKA.LCS.MIT.EDU internet address = 18.26.0.36
So museli.ai.mit.edu
is a nameserver for ai.mit.edu
:
> server MUESLI.AI.MIT.EDU
Default Server: MUESLI.AI.MIT.EDU
Address: 128.52.39.7
Now I change query type, we've found the name server so now we're
going to ask about everything wheaties knows about
prep.ai.mit.edu
.
> set q=any
> prep.ai.mit.edu.
Server: MUESLI.AI.MIT.EDU
Address: 128.52.39.7
prep.ai.mit.edu CPU = dec/decstation-5000.25 OS = unix
prep.ai.mit.edu
inet address = 18.159.0.42, protocol = tcp
ftp telnet smtp finger
prep.ai.mit.edu preference = 1, mail exchanger = gnu-life.ai.mit.edu
prep.ai.mit.edu internet address = 18.159.0.42
ai.mit.edu nameserver = beet-chex.ai.mit.edu
ai.mit.edu nameserver = alpha-bits.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 = mintaka.lcs.mit.edu
ai.mit.edu nameserver = life.ai.mit.edu
gnu-life.ai.mit.edu internet address = 128.52.32.60
beet-chex.ai.mit.edu internet address = 128.52.32.22
alpha-bits.ai.mit.edu internet address = 128.52.32.5
mini-wheats.ai.mit.edu internet address = 128.52.54.11
trix.ai.mit.edu internet address = 128.52.37.6
muesli.ai.mit.edu internet address = 128.52.39.7
count-chocula.ai.mit.edu internet address = 128.52.38.22
mintaka.lcs.mit.edu internet address = 18.26.0.36
life.ai.mit.edu internet address = 128.52.32.80
So starting at .
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 digging this out for you, and
it would not have to ask again for a while.
A much less talked about, but just as important domain is
in-addr.arpa
. It too is nested like the `normal' domains.
in-addr.arpa
allows us to get the hosts name when we have it's
address. A important thing here is to note that ip#s are written
in reverse order in the in-addr.arpa domain. If you have the address
of a machine: 192.128.52.43 named proceeds just like for the
prep.ai.mit.edu
example: find arpa.
servers. Find
in-addr.arpa.
servers, find 192.in-addr.arpa.
servers, find
128.192.in-addr.arpa.
servers, find 52.128.192.in-addr.arpa.
servers. Find needed records for 43.52.128.192.in-addr.arpa.
Clever huh? (Say `yes'.) The reversion of the numbers can be
confusing the first 2 years though.
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.
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. Upper and lower-case characters are the same for
DNS, so pat.uio.no
is identical to Pat.UiO.No
.
We've already started this part with this line in named.conf
:
zone "0.0.127.in-addr.arpa" { type master; file "pz/127.0.0"; };
Please note the lack of `.
' at the end of the domain names in
this file. This says that now we will define the zone
0.0.127.in-addr.arpa
, that we're the master server for it and
that it is stored in a file called pz/127.0.0
. We've already
set up this file, it reads:
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 1 ; Serial 8H ; Refresh 2H ; Retry 1W ; Expire 1D) ; Minimum TTL NS ns.linux.bogus. 1 PTR localhost.
Please note the `.
' at the end of all the full domain names in
this file, in contrast to the named.conf
file above. Some people
like to start each zone file with a $ORIGIN
directive, but
this is superfluous. The origin (where in the DNS hierarchy it
belongs) of a zone file is specified on the zone section of the
named.conf
file, in this case it's 0.0.127.in-addr.arpa
.
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
0.0.127.in-addr.arpa. IN SOA ...
NS is the Name Server RR. There is no '@' at the start of this line, it is implicit since the last line started with a '@'. Saves some typing that. So the NS line really reads
0.0.127.in-addr.arpa. IN NS ns.linux.bogus
It tells DNS what machine is the name server of the domain
0.0.127.in-addr.arpa
, it is ns.linux.bogus
. 'ns' is a
customary name for name-servers, but as with web servers who are
customarily named www.
something the name may be anything.
And finally the PTR record says that the host at address 1 in the
subnet 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
ns.linux.bogus
), who is responsible for its contents
(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.
Now restart your named (the command is ndc restart
) and use
nslookup to examine what you've done:
$ 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
so it manages to get localhost
from 127.0.0.1, good. Now for our
main task, the linux.bogus
domain, insert a new 'zone' section in
named.conf
:
zone "linux.bogus" { notify no; type master; file "pz/linux.bogus"; };
Note the continued lack of ending `.
' on the domain name in the
named.conf
file.
In the linux.bogus zone file we'll put some totally bogus data:
; ; Zone file for linux.bogus ; ; The full zone file ; @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 1W ; 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
Two things must be noted about the SOA record. ns.linux.bogus must be a actual machine with a A record. It is not legal to have a CNAME record for he machine mentioned in the SOA record. It's name need not be `ns', it could be any legal host name. Next, hostmaster.linux.bogus 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 any legal e-mail address, but the e-mail address `hostmaster' is expected to work as well.
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
someone@linux.bogus
, namely too mail.linux.bogus
or
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.,
mail.friend.bogus
which has priority 20 here.
Restart named by running ndc restart
. Examine the results
with nslookup:
$ nslookup
> set q=any
> linux.bogus
Server: localhost
Address: 127.0.0.1
linux.bogus
origin = ns.linux.bogus
mail addr = hostmaster.linux.bogus
serial = 199802151
refresh = 28800 (8 hours)
retry = 7200 (2 hours)
expire = 604800 (7 days)
minimum ttl = 86400 (1 day)
linux.bogus nameserver = ns.linux.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
ns.linux.bogus internet address = 192.168.196.2
mail.linux.bogus internet address = 192.168.196.4
Upon careful examination you will discover a bug. The line
linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus
is all wrong. It should be
linux.bogus preference = 10, mail exchanger = mail.linux.bogus
I deliberately made a mistake so you could learn from it :-) Looking in the zone file we find that the line
MX 10 mail.linux.bogus ; Primary Mail Exchanger
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 linux.bogus.linux.bogus
. So either
MX 10 mail.linux.bogus. ; Primary Mail Exchanger
or
MX 10 mail ; Primary Mail Exchanger
is correct. I prefer the latter form, it's less to type. There are
some, knowledgable, bind users that disagree, and some that agree with
this. In a zone file the domain should either be written out and
ended with a `.
' or it should not be included at all, in which
case it defaults to the origin.
I must stress that in the named.conf file there should not be
`.
's after the domain names. You have no idea how many times a
`.
' 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 as well:
; ; Zone file for linux.bogus ; ; The full zone file ; @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 1W ; 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 HINFO "Cisco" "IOS" TXT "The router" ns A 192.168.196.2 MX 10 mail MX 20 mail.friend.bogus. HINFO "Pentium" "Linux 2.0" www CNAME ns donald A 192.168.196.3 MX 10 mail MX 20 mail.friend.bogus. HINFO "i486" "Linux 2.0" TXT "DEK" mail A 192.168.196.4 MX 10 mail MX 20 mail.friend.bogus. HINFO "386sx" "Linux 1.2" ftp A 192.168.196.5 MX 10 mail MX 20 mail.friend.bogus. HINFO "P6" "Linux 2.1.86"
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. The machine called 'ns' has a Pentium CPU and runs Linux 2.0. 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 never refer to a CNAME record, they should only refer to something with a A record, so it would wrong to have
foobar CNAME www ; NO!
but correct to have
foobar CNAME ns ; Yes!
It's also safe to assume that a CNAME is not a legal host name for
a e-mail address: webmaster@www.linux.bogus
is an ilegal e-mail
address given the setup above. You can expect quite a few mail admins
Out There to enforce this rule even if it works for you. The way to
avoid this is to use A records (and perhaps some others too, like a MX
record) instead:
www A 192.168.196.2
A number of the arch-bind-wizards, recommends not using CNAME. So consider not using it very seriously.
But as you see, this HOWTO and many sites does not follow this rule.
Load the new database by running ndc reload
, this causes named
to read its files again.
$ nslookup
Default Server: localhost
Address: 127.0.0.1
> ls -d linux.bogus
This means that all records should be listed. It results in this:
[localhost]
$ORIGIN linux.bogus.
@ 1D IN SOA ns hostmaster (
199802151 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum
1D IN NS ns
1D IN NS ns.friend.bogus.
1D IN TXT "Linux.Bogus, your DNS consultants"
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
gw 1D IN A 192.168.196.1
1D IN HINFO "Cisco" "IOS"
1D IN TXT "The router"
mail 1D IN A 192.168.196.4
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "386sx" "Linux 1.0.9"
localhost 1D IN A 127.0.0.1
www 1D IN CNAME ns
donald 1D IN A 192.168.196.3
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "i486" "Linux 1.2"
1D IN TXT "DEK"
ftp 1D IN A 192.168.196.5
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "P6" "Linux 1.3.59"
ns 1D IN A 192.168.196.2
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "Pentium" "Linux 1.2"
@ 1D IN SOA ns hostmaster (
199802151 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum
That's good. As you see it looks a lot like the zone file itself. Let's check what it says for www alone:
> set q=any
> www.linux.bogus.
Server: localhost
Address: 127.0.0.1
www.linux.bogus canonical name = ns.linux.bogus
linux.bogus nameserver = ns.linux.bogus
linux.bogus nameserver = ns.friend.bogus
ns.linux.bogus internet address = 192.168.196.2
In other words, the real name of www.linux.bogus
is
ns.linux.bogus
, and it gives you some of the information it has
about ns as well, enough to connect to it if you were a program.
Now we're halfway.
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 buy 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.
Put this in named.conf
:
zone "196.168.192.in-addr.arpa" { notify no; type master; file "pz/192.168.196"; };
This is exactly as with the 0.0.127.in-addr.arpa
, and the
contents are similar:
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; Serial, todays date + todays serial 8H ; Refresh 2H ; Retry 1W ; 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.
Now you restart your named (ndc restart
) and examine your
work with nslookup again:
> 192.168.196.4 Server: localhost Address: 127.0.0.1 Name: mail.linux.bogus Address: 192.168.196.4
so, it looks OK, dump the whole thing to examine that too:
> ls -d 196.168.192.in-addr.arpa [localhost] $ORIGIN 196.168.192.in-addr.arpa. @ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial 8H ; refresh 2H ; retry 1W ; expiry 1D ) ; minimum 1D IN NS ns.linux.bogus. 1 1D IN PTR gw.linux.bogus. 2 1D IN PTR ns.linux.bogus. 3 1D IN PTR donald.linux.bogus. 4 1D IN PTR mail.linux.bogus. 5 1D IN PTR ftp.linux.bogus. @ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial 8H ; refresh 2H ; retry 1W ; expiry 1D ) ; minimum
Looks good!
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 notify no;
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 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?
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 section.