How To: DNS with BIND9 on Debian – Part 2/2

This is the second part of my two part series aimed at giving prospective DNS owners a kick start with BIND9. If you haven’t already head over to Part 1 and take a look.

NOTICE: I’m presuming that BIND is already setup and working on your Debian installation. So following part 1 will be necessary if it isn’t.

Part 2 will be a tutorial on how to create and setup your own DNS zone. A DNS zone will allow you to administer your domain name or an internal domain. A zone consists of a Forward Lookup Zone and a Reverse Lookup Zone.

Forward Lookup Zone: This file will tell BIND which IP-address is associated with which DNS name. s an example, when you type in yahoo.com the forward lookup zone will provide you with the IP address of that domain.

Reverse Lookup Zone: The Reverse Lookup Zone is the opposite. It will return the DNS name of any given IP-Address.

Together these zones will create your DNS zone. For the sake of keeping this as simple as possible i’ll be working with the domain name: test.local

Setting up a Master DNS zone with BIND 9

Creating a Forward Lookup Zone

Let start by configuring our Forward Lookup Zone configuration file. First we take the example file and rename it. Then we populate it with our own data. Remember to give the Zone file a name that represents the domain it will be representing. In my case I called it db.test.local

Now open the Zone file in your favourite text editor.

The file should look like this:

Lets configure this file to represent out own domain (Remember to replace test.local with your domain name).

You will need to change the following lines:

Line 5:
localhost. to test.local.
root.localhost. to root.test.local.

Line 6:
Change the ;Serial value: It’s common practice to change the Serial value to the date the change was made followed by a value. Personally I use the following formula; DDMMYYYV. Where V is a value that starts at 0 and changes for each change made on the same day.

So the first change today would be:
170420130
Consecutive changes on the same day would be
170420131
170420132
170420133
170420134
170420135
170420136

Of course you will want to update the date month and year if you update the Zone sometime in the future.

Line 12:
localhost. to ns.test.local.

Line 13:
Change 127.0.0.1 to the IP-Address of the DNS server, in my case 192.168.1.27

Line 14: we can delete the AAA record which has to do with IPv6

It should eventually look like this:

On line 14 I’ve added an MX record for my mail server:@       IN      MX      10      mail.test.local.

As you can see on line 15 I’ve added my own computer to the DNS list. This will allow me to access my personal computer by using it’s DNS name – pc.test.local

You can have as many entries as you like. You could build a DNS list for every machine on your local network, so you don’t have to remember the IP address of each machine.

On line 16 to 18 I’ve written the following:

These are simple A records to designate an IP address for the various machines in the domain. These machines will now be able to be reached via their DNS name as well as their IP address.

Creating a Reverse Lookup Zone

As with the Forward lookup Zone we have an example configuration file to use as a template. So make a copy and remane the file to db.<insert the first octet of your internal network here>

As I’m on the 192.168.1.0 network the first octet of my network is 192, so I named the file db.192

In its default state it will look like this:

Now lets configure it (It’s more or less the same as the Forward Lookup Zone):

Line 5
localhost. to test.local.
root.localhost. to root.test.local.

Line 6
Change the ;serial value as explained above.

Line 12
localhost. to ns.

Line 13
1.0.0 to 10
localhost. to test.local.

We must also add a record for our machine we added in the Forward Lookup Zone at the end of this file.

21         IN            PTR          pc.test.local

The configuration file should now look like this:

Configure BIND as the primary DNS Master for the Zone
Now that our zones are configured we can make BIND aware that they exist as well as set BIND as the primary master DNS server for this zone.

Open the following file

It will look like this:

Now add the following lines to the configuration file. Remember to change test.local with your domain name:

The final file should look something like this:

I’ll explain what each of these lines mean:

Line 11:
Here we are declaring the name of the DNS zone, which is test.local.

Line 12
We define this DNS server as the primary DNS server for this zone.

Line 13
We let BIND know where the Forward Lookup Zone file is located.

Line 16
This is specifically to do with reverse lookup within the Zone (IP to Domain name). A good explanation is below: Source: http://www.freesoft.org/CIE/Course/Section2/15.htm

DNS has a few special cases you need to be aware of. Probably the most important of these is the in-addr.arpa domain, which is used to convert 32-bit numeric IP addresses back into domain names. This is used, for example, by Internet web servers, which receive connections from IP addresses and wish to obtain domain names to record in log files. Remember that IP addresses are written as four decimal numbers (one for each byte), separated by periods.

Line 18
notify no: Turns off the DNS NOTIFY function. I have limited understanding of this at the moment as it seems this can be disabled on newer versions of BIND. However more information can be found here which is worthwhile reading. http://docstore.mik.ua/orelly/networking/dnsbind/ch10_02.htm

Line 19
We let bind know where is can find the Reverse Lookup Zone file

Restart and test BIND

/etc/init.d/bind9 restart

Now lets see if it works. Try to ping the machine we set up in the Zone – pc.test.local

Ping from the DNS server.

Ping from a Windows machine on my network using the DNS server we just created.

If you are trying to ping a Windows machine you will need to disable the Windows firewall otherwise your ping request will be dropped and you won’t receive an answer.

If the ping is successful then your DNS zone is most likely setup correctly :).

Top job!

Comments

  1. sohrab says

    I am iranian and i can’t good speak English but VERY VERY VERY VERY VERY VERY VERY Tank you

    Good Luck My frind….!

  2. mpb says

    I’m normally not the guy to comment on tutorials, but after struggling with setting up a simple local dns server and going crazy with other tutorials I just wanted to thank you for writing this comprehensible tutorial!

  3. Mark Botner says

    Thanks for the article! It was very helpful. I found what I think are a couple of problems with the reverse maps.

    1) I had put the last octet in the db.128 map for each host, this wasn’t really explained above
    2) My local network is 192.168.2 and in the /etc/bind/named.conf.local file I had to have an entry like this:
    zone “2.168.192.in-addr.arpa” {
    type master;
    notify no;
    file “/etc/bind/db.192″;
    };

    You had a ’0′ instead of a ’2′ and maybe that was correct for your network?

    Thanks again, a very helpful article! I now have bind working and can move away from dnsmasq which was conflicting with the network manager in Ubuntu.

    Mark

  4. Morten Abildgaard says

    With regards to the zone serial: DDMMYYYV makes little sence compared to what most others use: YYYYMMDDVV.
    Otherwise, nice write up.

    • Jack Brennan says

      Hi Morten,

      Thanks for the reply.

      As i stated in the paragraph concerning the serial number, that is my personal formula for it. I find it quicker on the eye to read a date the way we would print it on a letter. I see i have written DDMMYYYV, but you will notice all the serial numbers in the sequence i list up as an example are DDMMYYYYV.

      Some places like the Red Hat Documentation only use a single number to reflect a change (i.e 1/2/3/4). Debian documentation will use YYYYMMDDVV. It’s not a critical value in the configuration file apart from letting slave nameservers know that a change had been made.

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *