<HEAD><TITLE>Authoritative DNS serving</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
</HEAD><BODY>
<!-- Copyright 2005, 2006 Sam Trenholme
TERMS
Redistribution and use, with or without modification, are permitted
provided that the following condition is met:
1. Redistributions must retain the above copyright notice, this
list of conditions and the following disclaimer.
This documentation is provided 'as is' with no guarantees of
correctness or fitness for purpose.
-->
<H1>Using MaraDNS as an authoritative DNS server</H1>
<H2>Table of contents</H2>
<ul>
<li><A href=#needs>Requirements</A>
<li><A href=#what>What is a domain zone?</A>
<li><A href=#marazone>Setting up a domain with MaraDNS</A>
<li><A href=#zonesetup>Setting up a domain zone file</A>
<li><A href=#format>The format of a Domain Zone file</A>
<li><A href=#multiple>A single name can have multiple records</A>
<li><A href=#percent>The % character shortcut</A>
<li><A href=#register>Getting connected to the root name servers</A>
<li><A href=#2ips>Getting two IPs</A>
<li><A href=#network>Names internal to a network</A>
</ul>
<A name=needs>
<H2>Requirements</H2></A>
In order to set up an authoritative DNS server, one needs one or more
<i>static IP addresses</i>.
With most
<i>registries</i>,
two or more
static IP addresses are needed.
<p>
In addition, the machine(s) with the static IP addresses need to be
running an authoritative DNS server, such as MaraDNS.
<A name=what>
<H2>What is a domain zone?</H2></A>
A name like www.example.com is part of the
<A href="glossary.html#zone">
<i>domain zone</i></A>
example.com. The name www.yahoo.com, as another example, is part of the
<A href="glossary.html#zone">
<i>domain zone</i></A>
yahoo.com. www.maradns.org is part of the
<A href="glossary.html#zone">
<i>domain zone</i></A>
maradns.org.
<A name=marazone>
<H2>Setting up a domain with MaraDNS</H2></A>
<A href=compile.html>Compile and install</A> MaraDNS on the system which
will act as an authoritative DNS server.
<p>
After doing this, the <A href=man.mararc.html><tt>mararc</tt></A> file
needs to be changed before MaraDNS will function as an authoritative DNS
server.
<p>
A mararc file which can be used to
<A href="glossary.html#serve">
<i>serve</i></A>
the
<A href="glossary.html#zone">
<i>domain zones</i></A>
that one wishes to have control over needs to only be four lines long:
<pre>
ipv4_bind_addresses = "10.3.28.79"
chroot_dir = "/etc/maradns"
csv2 = {}
csv2["example.com."] = "db.example.com"
</pre>
Lets look at these four lines. The first line, <tt>ipv4_bind_addresses</tt>,
is the IP address (or addresses) this DNS server will have. Since we're
running an authoritative DNS server, it is important that this IP
address be a <i>routable</i> IP address--an IP address that can be accessed
by anyone on the internet. It is also important that any firewall between
this machine and the internet at large is able to connect to UDP port
53 of this machine.
<p>
The <tt>chroot_dir</tt> value is the directory that contains all of the files
with information for the domain zones (these files are normally called
"zone files" by DNS administrators). Here, we place the zone files
in the directory <tt>/etc/maradns</tt>.
<p>
The third line, <tt>csv2 = {}</tt>, tells MaraDNS that we will be
acting as an authoritative DNS server. This line must be placed
before telling MaraDNS where any zone files are located.
<p>
The fourth line, <tt>csv2["example.com."] = "db.example.com"</tt> tells
MaraDNS that, for the domain zone "example.com.", the zone file is called
"db.example.com".
<p>
In other words, <b>example.com.</b> is the name of the domain zone that the
file <b>db.example.com</b> has data for. Change <b>example.com.</b> to the
name of the domain zone you wish to serve, and <b>db.example.com</b> to
the filename to be used to serve that domain zone. <b>Important</b>: the
domain zone name (e.g. <b>example.com.</b>) requires a trailing dot.
<p>
It is possible to server multiple domain zones, of course. For example:
<blockquote>
<pre>
csv2["example.com."] = "db.example.com"
csv2["example.org."] = "db.example.org"
csv2["heaven.af.mil."] = "db.heaven.af.mil"
</pre>
</blockquote>
It is also possible to bind MaraDNS to multiple IP addresses, e.g:
<pre>
ipv4_bind_addresses = "10.3.28.79, 10.9.87.23"
</pre>
<A name=zonesetup>
<H2>Setting up a domain zone file</H2></A>
Let us suppose that we are setting up a domain for example.com, where we
have the following services:
<UL>
<LI>We are running a web server for example.com and www.example.com on the
IP 10.10.10.12. In other words, people can view web pages on this
machine.
<LI>We have a mail server, or
<A href="glossary.html#mta">
<i>mail transport agent</i></A>
for
example.com with the IP 10.10.10.15. In other words, the machine with the
IP 10.10.10.15 is set up to handle mail addressed to name@example.com,
where "name" is any string preceding the '@' sign.
<LI>Both 10.10.10.11 and 10.10.10.17 are running MaraDNS in authoritative
mode to serve DNS requests for example.com.
</UL>
The zone file for this setup would be as follows. Note that lines
which start with the <tt>#</tt> symbol are comments (lines ignored by
MaraDNS), allowing one to add human-readable notes
in the file in question.
<pre>
# This is an example zone file for the imaginary domain example.com.
# We have two records which handle the serving of web pages. These
# are simple name-to-ip translations. In other words, we have one
# record which states "The IP for example.com. is 10.10.10.12" and
# another that states "The IP for www.example.com. is 10.10.10.12"
example.com. 10.10.10.12 ~
www.example.com. 10.10.10.12 ~
# We also need to set up an IP for the machine that serves email for
# example.com. Because of how DNS is designed, we both need
# a record which states "The machine which handles mail for
# example.com is called mail1.example.com" and a record which states
# "The IP address for mail1.example.com is 10.10.10.15":
example.com. MX 10 mail1.example.com. ~
mail1.example.com. 10.10.10.15 ~
</pre>
Now, to adapt this file to another zone, we need to simply make the
following changes:
<ul>
<li>Substitute the name <b>example.com</b> with the name of the domain
one wishes to administer.
<li>Substitute the IP 10.10.10.12 with the IP of the machine running the
web server for the domain.
<li>Substitute the IP 10.10.10.15 with the IP of the machine running the
mail server for the domain.
</ul>
Note that the <tt>chroot_dir</tt> mararc variable tells MaraDNS which
directory contains domain zone files.
<A name=format>
<H2>The format of a Domain Zone file</H2></A>
Here are some example lines in a domain zone file, which is an example of
someone using the same IP multiple times. For example, if one is using
10.10.10.19 as one of the DNS servers, the mail server, and the web
server, one would have records like this:
<pre>
example.com. NS ns1.example.com. ~
ns1.example.com. 10.10.10.19 ~
example.com. 10.10.10.19 ~
www.example.com. 10.10.10.19 ~
example.com. MX 10 mail1.example.com. ~
mail1.example.com. 10.10.10.19 ~
</pre>
Translated into English, the above lines say:
<ul>
<li>One name server for example.com
is called ns1.example.com.
<li>The IP for ns1.example.com
is 10.10.10.19
<li>The IP for example.com (in other words, the machine a web browser
should hit if one selects http://example.com/)
is 10.10.10.19
<li>The IP for www.example.com is 10.10.10.19
<li>The name of the machine which processes incoming mail, which
has a priority of ten
(lower priority numbers are more important), is called mail1.example.com.
<li>The IP for mail1.example.com
is 10.10.10.19
</ul>
<p>
A line in a domain zone file contains a single <i>DNS record</i>. The
data has multiple fields separated by a whitespace or the <TT>|</TT>
character, and is in this format:
<UL>
<LI>The first portion of the DNS record, is the DNS node that this record is
attached to.
<LI>The next portion of a DNS record, which is optional, tells MaraDNS
what kind of DNS
record this is. A list of DNS records which MaraDNS supports is described
<A href=recordtypes.html>here</A>. If this field is absent, MaraDNS
assumes that the record is an "A" (32-bit IP address) record, and that the
second portion is the IP address in question.
<LI>If the record is not an "A" record, the subsequent fields describe
the DNS record in question. The format
for this data depends on the DNS record type being used, and is described <A
href=recordtypes.html>here</A>.
</UL>
The reason to use different names for different functions is to minimize
the number of problems one will encounter, should one need to change their
IPs at a later time.
<A name=multiple>
<H2>A single name can have multiple records</H2></A>
A single name can have multiple records. This is useful when one wishes
to have, for example, multiple machines processing requests for
<tt>www.example.com</tt>.
<p>
For example:
<pre>
www.example.com. 10.10.10.10 ~
www.example.com. 10.10.10.11 ~
www.example.com. 10.10.10.12 ~
</pre>
In this example, a query to <tt>www.example.com</tt> will return a list of
three IPs. MaraDNS rotates the records so that the first IP given to
a client changes each time a query for <tt>www.example.com</tt> is made.
This can be used as a primitive kind of load balancing.
<A name=percent>
<H2>The % character shortcut</H2></A>
<p>
If one is setting up multiple domain zones, all of which have more or less
the same data, it is convenient to have a template domain file which
different zones can use without needing to modify the file in question.
<p>
MaraDNS has support for this by using the <tt>%</tt> symbol. Whenever
MaraDNS sees a <tt>%</tt> in a csv2 zone file, MaraDNS knows to replace
the percent symbol with the name of the zone in question. For example, if
the file in question is the zone file for example.com, the % is expanded
out to "example.com.". If the zone file in question is for maradns.org,
the % is expanded out to "maradns.org.". Hence, we could, provided that
the zone file is for example.com, have a zone file like this:
<pre>
# We have two records which handle the serving of web pages. These
# are simple name-to-ip translations.
% 10.10.10.12 ~
www.% 10.10.10.12 ~
# We also need to set up an IP for the machine that serves email for
# our zone. Because of how DNS is designed, we both need
# a record which states "The machine which handles mail for
# out zone is called mail1.<zone name>" and a record which states
# "The IP address for mail1.<zone name> is 10.10.10.15":
% MX 10 mail1.example.com. ~
mail1.% 10.10.10.15 ~
</pre>
This zone file would function identically to the first example zone file
above.
<A name=register>
<H2>Getting connected to the root name servers</H2></A>
An authoritative DNS server will not effectively serve a domain unless the
root name servers are aware that a given DNS server serves a given domain
name.
<p>
When a recursive DNS server attempts to find the IP for, say,
www.example.com, it firsts asks the root nameservers for this IP. The
root name servers send out a reply which says "We do not know that answer
to this question, but you may contact the DNS server at 10.1.2.3 for the
answer". At this point, the recursive DNS server contacts 10.1.2.3,
asking it for the IP for www.example.com. (Actually, the root nameservers
give out the .com nameservers, which in turn give out the example.com
nameservers, but the principle is the same)
<p>
In order that the entire internet community may be aware of a domain, the
domain must be registered with the root name servers, so that the root
name servers know that IPs of the machines which are authoritative DNS
servers for the domain in question. (Again, you're really registering
with, say, the .com servers)
<p>
The exact policies which one needs to confirm to to register their domain
depend on the register in question. To register a domain under the
generic domain names (presently .com, .net, .org, and .info) one simply
needs to register their name with a register, and follow some guidelines
when designing the zone files for their domain.
<p>
There are a number of competing registrars which server domain names. One
which I have extremely happy with is Net Wizards; domains can be
registered at <A
href=http://domains.netwiz.net/>http://domains.netwiz.net/</A>. In order
to register a domain, you will need to know the zone servers for your
domain. You can either set these up yourself (see <A href=#network>below</A>
for an example), or use the <tt>askmara</tt> tutorial to find out the
name servers for your domain.
<p>
To use the <tt>askmara</tt> tool, make an askmara query like this:
<blockquote><tt>askmara Nexample.com. 127.0.0.1</tt></blockquote>
Replace <tt>example.com</tt> with the name of the domain to be registered,
and <tt>127.0.0.1</tt> with the IP of the DNS server. The output of the
query will look something like this:
<pre>
# Querying the server with the IP 127.0.0.1
# Question: Nexample.com.
example.com. +86400 ns <b>synth-ip-0a010203.example.com.</b> ~
example.com. +86400 ns <b>synth-ip-0a040506.example.com.</b> ~
# NS replies:
# AR replies:
#synth-ip-0a010203.example.com. +86400 a <b>10.1.2.3</b> ~
#synth-ip-0a040506.example.com. +86400 a <b>10.4.5.6</b> ~
</pre>
The names for the name servers we wish to submit to the registrar are the
<tt>synth-ip-0a010203.example.com</tt> and
<tt>synth-ip-0a040506.example.com</tt> names above. These somewhat long
names are the names for the nameservers for the (in the above example)
<tt>example.com.</tt> domain. At the end of the <tt>askmara</tt> output,
you can see the IPs for these name servers; place these IPs in the field
where they ask for the IP of the name servers for your domain.
<p>
For example, if the registrar's form looks like this:
<pre>
Domain name: _________________
Nameserver 1 name: ____________________________________
Nameserver 1 IP: ____________________________________
Nameserver 2 name: ____________________________________
Nameserver 2 IP: ____________________________________
Nameserver 3 name: ____________________________________
Nameserver 3 IP: ____________________________________
Nameserver 4 name: ____________________________________
Nameserver 4 IP: ____________________________________
</pre>
Based on the above <tt>askmara</tt> output, we would fill out the above
form thusly:
<pre>
Domain name: example.com
Nameserver 1 name: synth-ip-0a010203.example.com.
Nameserver 1 IP: 10.1.2.3
Nameserver 2 name: synth-ip-0a040506.example.com.
Nameserver 2 IP: 10.4.5.6
Nameserver 3 name: ____________________________________
Nameserver 3 IP: ____________________________________
Nameserver 4 name: ____________________________________
Nameserver 4 IP: ____________________________________
</pre>
<p>
If you only have one NS server, you may need to get a second one to
register a domain. The procedure for doing this is described in the
following section.
<A name=2ips>
<h2>Getting two IPs</h2></A>
As stated near the beginning of this document, many registries require
that one has two IPs to register a domain. If one has a computer with
two or more routable IPs assigned to it, it is simple enough to have
MaraDNS bind to these IPs. Change the variable
<tt>ipv4_bind_addresses</tt> to include all of the IPs one wishes MaraDNS
to have, like the following example:
<blockquote>
<tt>ipv4_bind_addresses = "10.1.2.3, 10.5.6.7"</tt>
</blockquote>
Naturally, replace "10.1.2.3" and "10.5.6.7" with the IPs your machine
has.
<p>
If you have but a single IP, it is necessary to find someone who will
provide secondary DNS service for your domain, and set up MaraDNS to
be a zoneserver. Information on how
to do this is provided in the <A href=dnsmaster.html>DNS master</A>
document.
<A name=network>
<h2>Names internal to a network</h2></A>
Sometimes one will have a number of computers in an office, or other small
network, with a number
of different names. It is desirable to use DNS to give these office
machines IP addresses. Let us suppose that we have a company with
computers named "Mascota", "Paloma", and "Vela". If we want to have
computers in the office be accessible with just the name (such as
just "Vela"), we set up what is known as a <i>default domain
suffix</i>. Let us suppose that the company in question is a company
that sells examples of hard work. Hence, the company is called
"example.com". We then give our computers the names "mascota.example.com",
"paloma.example.com", and "vela.example.com". We then tell computers
in the office that, when given a name without a suffix, to append the
"example.com" suffix when looking for host names.
<p>
It is possible to do this in MaraDNS 1.3 in two different ways.
<p>
One way is to set up MaraDNS' recursive resolver to use a custom
nameserver for a subset of the DNS space. For example, the recursor can be
told to go to "192.168.0.7" to look up all names that end in ".office". More
information about this is in the
<A href=recursive.html#privateroot>recursive DNS document</A>.
<p>
The other method takes advantage of the fact that MaraDNS first looks up
authoritative names before performing recursion. For example, if
<tt>www.google.com</tt> is defined in a MaraDNS zone file, MaraDNS
will use the value in the zone file instead of contacting nameservers
on the internet to get the IP for <tt>www.google.com</tt>.
<p>
On UNIX, BSD, and Linux machines in an office, this is done by adding
a line like this to the file <tt>/etc/resolv.conf</tt>:
<p>
<blockquote><tt>search example.com</tt></blockquote>
<p>
In Windows XP, go to Control Panel -> Network Connections -> Local Area
Connection (or whatever connection the computer uses to get on the LAN) ->
Properties -> Internet Protocol (TCP/IP) (this is under "The connection uses
the following items" and you may have to scroll down to see it) ->
Advanced -> DNS -> "Append these DNS suffixes (in order)" -> Add
and type in "example.com" (or whatever) as the Domain suffix.
<p>
Once this is done, create a zone for example.com. Since we're just giving
three computers IPs, the zone file for example.com is added to the mararc
file with this line:
<blockquote><tt>csv2["example.com."] = "db.example.com"</tt></blockquote>
We then place, in the directory pointed to by <tt>chroot_dir</tt> in the
mararc file, the file <tt>db.example.com</tt>, which looks like this:
<pre>
mascota.% 10.1.2.3 ~
paloma.% 10.5.6.7 ~
vela.% 10.9.8.4 ~
</pre>
See <A href=#percent>above</A> for an explanation of what the <tt>%</tt>
symbol does.
<p>
The above three lines, which is a complete csv2 zone file, is a shorthand
for the following:
<pre>
# The SOA record. If a zone doesn't have a SOA record, MaraDNS will
# synthesize an appropriate one for a given zone. This is information
# about who is in charge of the example.com zone; basically the zone
# name "example.com.", SOA "It's a Start of Authority record",
# "example.com." (this is the name of the machine in charge of
# example.com), "hostmaster@example.com." (the email address of the
# person in charge of example.com.)
example.com. SOA example.com. hostmaster@example.com. ~
# The following numbers, part of the SOA record, give some technical
# information about transferring information about this zone to other
# DNS servers. If you use rsync to share zone files, these numbers
# do not need to be worried about.
1 7200 3600 604800 1800 ~
# NS records. If a zone doesn't have NS record, MaraDNS will, again
# synthesize appropriate NS records for a given zone. This is a list
# of all of the DNS servers that have the example.com zone file.
example.com. NS ns1.example.com. ~
example.com. NS ns2.example.com. ~
# The NS records above need IPs. Note that "A" (this is an IP) is
# optional
ns1.example.com. A 10.1.2.3 ~
ns2.example.com. A 10.4.5.6 ~
# Now that we have the SOA and NS records taken care of (again, MaraDNS
# will automatically take care of these records if they are not in a
# zone), we can add the records for the zone in question
# mascota.example.com. has the IP address 10.1.2.3
mascota.example.com. A 10.1.2.3 ~
# mascota.example.com. has the IP address 10.5.6.7
paloma.example.com. A 10.5.6.7 ~
# mascota.example.com. has the IP address 10.9.8.4
vela.example.com. A 10.9.8.4 ~
</pre>
Information on setting up a recursive server so that these names are private
network-specific hostnames is available in the
<A href=recursive.html#private>private hostname section of the
recursive server document</A>.
</body>
distrib
>
Mageia
>
4
>
i586
>
media
>
core-release
>
by-pkgid
>
07a81589bb2c4aa5e88f35a4a345a184
>
files
>
230
