View Source: DNSHowto - Waikato Linux Users Group

Edit PageHistory Diff Info LikePages
!!!Client-side notes

!Checking a remote server's software version
Want to find out what version of Named that a server runs? Here is a couple of handy commands that can tell you what version of bind a server is running.

<pre>
 nslookup -q=txt -class=CHAOS version.bind.

 dig @nameservers.name version.bind ch txt
</pre>

!Updating cached errors
Normally, your local [DNS] server will cache queries, whether they are successful or fail. However, sometimes you want to re-perform the query again because you think it should work this time (eg you are modifying a DNS server, or you know that at least one server for a remote site is returning different results than the other name servers). Rather than restarting your local DNS server to forget about all the cached information, you could first try sending certain queries:

<pre>
 host -t ANY remote.host.name.
</pre>

This asks for "any available" information about the hostname, so hopefully if it isn't all cached your server will contain their server(s) again, and hopefully update the cached error. (This works for the dnsutils-derived host(1) command, the bind-derived host(1) command may behave differently.)

!!!Configuring DNS with [BIND] Made Easy.

Setting up DNS with [BIND], no matter what people say, is pretty trivial.  We're going to step through setting up some name servers for "example.com".

The first thing you will need is bind installed on your server.  For RedHat it's on your install CD's as "bind", For [Debian] it's "bind9".

The next step is to configure named.conf, in Red Hat this is /etc/named.conf, in Debian it's /etc/bind/named.conf.

This file is made up of "blocks": we'll start with the "options" block which configure the server itself.
<pre>
 options {
</pre>
This starts the options block
<pre>
  directory "/var/cache/bind";
</pre>
This configures where bind will write it's files, and the relative paths elsewhere in this file
<pre>
  auth-nxdomain no;
</pre>
This means that the server will not answer authoratively for "no such domain", which older versions of bind used to do.  Newer versions default this off but complain about it in syslog if you don't have the option.  Either way, just stick the option in there, it makes named happy :)
<pre>
 allow-transfer { ''slave name servers go here'' };
</pre>
named allows you to do zone transfers where one name server can download the entire zone file from another name server.  You usually only want to allow name servers you control to do this, so you list these here.  You can leave this line out, in which case anyone can download your entire zone files.  an example of this line might be allow-transfer { 1.2.3.4; 2.3.4.5; };
<pre>
 allow-recursion { ''netranges go here'' };
</pre>
This lets you restrict the number of people that can use your nameserver for forwarding.  If your name server isn't on the internet this line can be ommitted.  If your name server is on the internet you probably only want to list IP's that you control here.  Allowing people to forward through your name server can let them exploit any bugs your name server might have.  an example might be allow-recursion { 10.0.0.0/8; 192.168.0.0/16; 127.0.0.0/8; };  See ClasslessInterDomainRouting for information about / prefixes.
<pre>
 };
</pre>
This ends the options block.

Now we need to tell the name server where to look for the root name servers.
<pre>
 zone "." {
</pre>
This says we're declaring a zone for the domain ".".  You mustn't change this.
<pre>
  type hint;
</pre>
This means that this is a hint to get the daemon started finding other name servers.  It's free to sort itself out and do it's own thing later.
<pre>
  file "/etc/bind/db.root";
</pre>
This is where it will read the hints from.  We'll discuss later about how to create this file.
};

<pre>
 zone "127.in-addr.arpa" {
</pre>
This starts declaring a zone for reverse lookups on 127.*.  Now, the way [ReverseLookup]s are handled is by looking up the IP reversed followed by ".in-addr.arpa".  For instance, if you want to look up what name the IP "1.2.3.4" has, you look up "4.3.2.1.in-addr.arpa".  If you think this is messy, don't even ask what they do for [IPv6] :)
<pre>
  type master;
</pre>
We are the master for this zone.  ie: we provide the information to slave zones, and we know all about it.
<pre>
  file "/etc/bind/db.127.x";
</pre>
This is where we read the information from for this zone.  You may optionally have "allow-transfer" blocks in here for this zone.
<pre>
 };
</pre>

Now we'll add out example zone "example.com".

Now, on the primary name server __ONLY__ we add:

<pre>
 zone "example.com" {
</pre>

First we declare a block for it.

<pre>
  type master;
</pre>

This name server is going to be the master for this domain.

<pre>
  file "/etc/bind/db.example.com";
</pre>

Where the information for this zone is stored.  Fairly trivial.

<pre>
 };
</pre>

On the secondary name server __ONLY__ we add:

<pre>
 zone "example.com" {
</pre>

The block again

<pre>
  type slave;
</pre>

Ok, this is new.  This means that the zone will be downloaded using a ZoneTransfer from a primary name server.

<pre>
  masters { ''ip of the primary name server''; };
</pre>

This is where to download this zone from.  An example of this line might be masters { 1.2.3.4; }; if you were going to d/l it from the IP address "1.2.3.4".

<pre>
  file "db.example.com";
</pre>

Here's where we want bind to store the file.  Note that we don't specify a FullPath here, so that it will be put in the default directory (/var).

};

And heres the end.

You can add as many of these two blocks as you need for each zone.  remember, [ReverseLookup]s are done by reversing the network and adding ".in-addr.arpa" on the end.

Now we are finished with /etc/bind/named.conf, and we want to start creating the [ZoneFile]s.

Now we'll move onto the zone files themselves.  We'll start with /etc/bind/db.example.com

at the top of the zone file we specify the default TTL of all the records in the zone.  This specifies how frequently information will be checked to see if it's been updated, a good value is 24 hours.  If you are expecting to change the zone file sometime in the future you might want to turn this number down lower, alternatively, if you are expecting it to change, you can increase it.

<pre>
 $TTL 24h
</pre>

Then we put a "~StartOfAuthority" record which explains a bit about who owns the zone, and how often the secondaries should check for updates etc.

<pre>
 @ IN SOA ''primary.name.server.'' ''email.address.for.contact.information'' (
  ''Serial Number''  ; Serial Number
  ''Refresh Time''   ; Refresh Time
  ''Retry Time''     ; Retry Time
  ''Expire Time''    ; Expire Time
  ''Negative Cache TTL'' ; Negative Cache TTL
  )
</pre>

This will take some explaination.  The "@" in the first column means that it refers to the current zone (example.com.)  You could replace this with "example.com.", but most people just use "@" instead.  It's easier to remember and much easier to type :)  The "IN" means that this is for the InterNet.  There are other values that can go here, noone ever uses them.  The "SOA" means this is a StartOfAuthority record.

The next one is the "primary name server".  So, for instance you might use "ns1.example.com." here.  Note that you must have a "." at the end of the domain name.  If you don't, the named will add the domain on again, giving you "ns1.example.com.example.com" which is definately not what you want.  The #1 problem with zone files is that someone forgot to put the "." on the end of a domain name.  Don't let this happen to you, check it all twice.

The email address for contact information is an email address of someone to contact if you have problems with this zone, except the usual "@" is replaced with a "." for some bizarre reason.  Don't ask me why.  So "domains@example.com." becomes "domains.example.com." as you would expect.

The serial number is which "version" of the zone file this is.  This only requirement for this is that every time you change the zone you increment this number by 1.  Almost everyone uses the format "YYYYMMDD00" for the serial number, eg, for today (2002-10-09) I would use 2002100900, and if I made a change later today I would use 2002100901 etc...

The Refresh time is how often secondary name servers check the primary to see if it has updated information.  8h is an often used value.

The Retry time is how often secondary's should retry if they couldn't fetch it when they tried to do a refresh. 30m is an often used value.

The Expire time is when they give up.  If after this time the name server couldn't reach the primary name server it will give up and become a "LameServer".  1 month is an often used value.

The Negative Cache TTL is how long entries that don't exist should be cached for on other name servers around the Internet.  30 minutes is an often used value.

<pre>
 @ IN NS ns1.example.com.
</pre>

Now we list the name servers for example.com.  ns1.example.com __must not__ be a CNAME.  A general policy that works well is to have one "aurhorative name" for a name server and use that for all zones.  eg: if example.com and example.org are both hosted on the site, then they both use "ns1.example.com." as their primary NS, thus changing the IP of "ns1.example.com" when the name server moves, it moves all the domains, and you don't have to move them all.

<pre>
 @ IN NS ns2.example.com.
</pre>

And a secondary nameserver, remember to add the "." at the end, and remember that ns2.example.com can't be a CNAME.

<pre>
 @ IN MX 10 smtp.example.com.
</pre>

This lists a "mail exchange" record for "example.com."  You can list multiple MX records.  It will use the records with the lowest number in preference to ones with higher numbers.  Note, you can't have a MX to a CNAME, and you can't have a MX to an IP address.

<pre>
 @ IN MX 20 smtp2.example.com.
</pre>

This would be an example of a backup mail server.  It won't ever get used unless the primary one (above) is down.  It's a secondary since this preference number is greater.

<pre>
 ns1.example.com. IN A 1.2.3.4
</pre>

This lists a name (ns1.example.com) and gives it an address (1.2.3.4).  Remember you can't have a CNAME for a nameserver.

<pre>
 ns2.example.com. IN A 2.3.4.5
</pre>

This lists the secondary name server, as above. :)

<pre>
 smtp.example.com. IN A 1.2.3.4
</pre>

Mail server for example.com, like before :)

<pre>
 smtp2.example.com. IN A 2.3.4.5
</pre>

Mail server for example.com, as above :)  Note that these have the same address as ns1.example.com and ns2.example.com, they don't have to, but they can.

<pre>
 snargle.example.com. IN A 1.2.3.4
</pre>

This is a host called snargle.example.com.

<pre>
 www.example.com. IN CNAME snargle.example.com.
</pre>

This is an alias for snargle.example.com.  people looking up www.example.com will get snargle.example.com.  Note, you can't send mail to a CNAME, nor can you use it as a namserver.  You cannot have one name have a CNAME and any other records (including other CNAMEs).  In general (and as you may have guessed by now), CNAME's are pretty limited, and infact should probably be ignored.

<pre>
 narf.example.com. IN A 2.3.4.5
</pre>

This is a hostname for narf.example.com.

You can have multiple records for one name, for example:

<pre>
 blargh.example.com IN A 3.4.5.6
 blargh.example.com IN MX 10 narf.example.com.
</pre>

This lists a host "blargh.example.com" that doesn't accept mail, instead it's sent to narf.example.com.

You can also have multiple of the same record:
<pre>
 secure.example.com. IN A 1.2.3.4
 secure.example.com. IN A 2.3.4.5
 secure.example.com  IN A 3.4.5.6
</pre>
This will be round-robined, thus giving you simplistic load balancing between these servers.

----
CategoryDns, CategoryHowto
3 pages link to DNSHowto:
Last edited on Friday, February 23, 2007 2:47:19 pm by AlastairPorter
Edit PageHistory Diff Info LikePages