From charlesreid1

No edit summary
No edit summary
Line 1: Line 1:
This page contains instructions for setting up a DNS server in Linux.
This page contains instructions for setting up a DNS server in Linux.


==DNS Server==
=DNS Server=


DNS stands for domain name system - it turns IP addresses into human-readable host names.
DNS stands for domain name system - it turns IP addresses into human-readable host names.
Line 7: Line 7:
DNS is useful for the wider internet, obviously, but is also useful on a small network. DNS is useful for more than a handful of networked computers.  
DNS is useful for the wider internet, obviously, but is also useful on a small network. DNS is useful for more than a handful of networked computers.  


===Installing/Starting===
==Installing/Starting==


On Debian, use <code>bind9</code> (BIND = Berkeley Internet Name Domain). This is the most popular name server around. Once you install it, Debian should boot it up for you and configure the daemon.  
On Debian, use <code>bind9</code> (BIND = Berkeley Internet Name Domain). This is the most popular name server around. Once you install it, Debian should boot it up for you and configure the daemon.  
Line 45: Line 45:
Until the DNS server is configured, it won't be doing anything for us.
Until the DNS server is configured, it won't be doing anything for us.


===Configuring DNS===
==Configuring DNS==


The configuration file for BIND is located in <code>/etc/bind/named.conf</code>.
The configuration file for BIND is located in <code>/etc/bind/named.conf</code>.
Line 58: Line 58:
Note that we can put those files wherever we want, and create our own layout of configuration files.
Note that we can put those files wherever we want, and create our own layout of configuration files.


===Configure DNS Forwarding===
==Configure DNS Forwarding==


Start by setting up your DNS server to forward DNS requests that it can't handle to another (public) DNS server. Start by editing the BIND configuration options:
Start by setting up your DNS server to forward DNS requests that it can't handle to another (public) DNS server. Start by editing the BIND configuration options:
Line 78: Line 78:
What we are doing here is to create instructions for where to forward DNS requests, if it cannot find what it is looking for. (Note that this is usually done by default, but doing it this way allows us to specify which DNS servers to use.) These two (8.8.8.8 or 8.8.4.4) are both name servers from Google.
What we are doing here is to create instructions for where to forward DNS requests, if it cannot find what it is looking for. (Note that this is usually done by default, but doing it this way allows us to specify which DNS servers to use.) These two (8.8.8.8 or 8.8.4.4) are both name servers from Google.


===Local DNS Configuration===
==Local DNS Configuration==


Now we can set up the DNS configuration for the local network and its subnets. Start by editing the file:
Now we can set up the DNS configuration for the local network and its subnets. Start by editing the file:
Line 116: Line 116:
* Each subnet has its own reverse-lookup file where we can configure things. Each file is stored in <code>/etc/bind</code>.
* Each subnet has its own reverse-lookup file where we can configure things. Each file is stored in <code>/etc/bind</code>.


===DNS Records===
==DNS Records==


Now let's look at the actual DNS records (in the reverse-lookup files listed in the code above).
Now let's look at the actual DNS records (in the reverse-lookup files listed in the code above).
Line 153: Line 153:
* TTL is time to live, set to 1 day - this is how long DNS records are cached (important with multiple DNS servers or dynamic IP addresses)
* TTL is time to live, set to 1 day - this is how long DNS records are cached (important with multiple DNS servers or dynamic IP addresses)
* SOA is start of authority, which defines which comptuer has DNS authority on this local network. The <code>administrator.local.lan</code> is an email address.
* SOA is start of authority, which defines which comptuer has DNS authority on this local network. The <code>administrator.local.lan</code> is an email address.
* 201507261 is the serial number. if you change a zone file in bind, you should change this serial number. It is the first thing the daemon reads and it is how the daemon knows if the DNS records have been changed.
* 201507261 is the serial number. if you change a zone file in bind, you should change this serial number. It is the first thing the daemon reads and it is how the daemon knows if the DNS records have been changed. Always increment the serial number by 1 if you change the file.
* The refresh/retry/expire/maximum settings dictate how often other (non-master) DNS servers will be told to check for updates (H = hours, W = weeks, D = days). Normally there are no non-master DNS servers, so this won't do anything. But if you do add more DNS servers, you'll have to set this stuff.
* <code>@ IN NS hermes.local.lan</code> identifies the name server. The name "hermes" is an arbitrary name for the local computer running the DNS server.
* <code>galaxy IN A 10.10.96.4</code> - there are four sample address records given in the file above. The records map the listed domain name ("galaxy") to a particular host IP address. If someone looks for <code>galaxy.local.lan</code> the DNS server will resolve it to the IP address 10.10.96.4. The letter "A" indicates the type of CNAME record.


==Subnet Configuration==


<!--
The last remaining task is to configure each subnet using the subnet configuration files specified above.  
Each time our bind daemon is restarted, it will reload this file. But when it does, the serial number is the first thing it will look at. If it is the same, it will likely not load in any changes. Thus, every time you change a zone file in bind, you must change this serial number as well. In this example, the current date is being used without hyphens or spaces. The last digit is just a revision number for that day, if the file is changed multiple times in one day. You can use whatever scheme you'd like. But using the date is a very popular approach. Regardless of the format you use, always ensure you increment the serial by 1 with every change you make. You'll save yourself frustration wondering why newly created records aren't taking affect.


8H ; refresh
As an example, the 10.10.96.0 subnet would have the following configuration file:
4H ; retry
4W ; expire
1D ) ; minimum
These values dictate how often slave DNS servers will be told to check for updates. The first value will configure slaves to refresh zone records from the master (this server) every eight hours. In regards to retry, we're letting slaves know that should there be a problem connecting, check back in this amount of time. Finally, we're setting our minimum age of zone records to one day, and the maximum to four weeks. Configuring slave DNS servers is beyond the scope of this book, but having this configuration in place doesn't hurt anything in case you do decide to configure slave DNS servers later on.
 
@ IN NS hermes.local.lan.
Here, we're identifying this name server. In my case, I'm calling it hermes and its full domain name is hermes.local.lan.
 
galaxy        IN    A  10.10.96.4
hermes        IN    A  10.10.96.1
Finally, in this sample configuration, four address records are called out. This basically means that any time someone is looking for one of these hosts, the request is mapped to the listed domain name. These can be among multiple subnets or a single subnet. In my case, these hosts are on different subnets:
 
puppet      CNAME galaxy
The final line of this configuration contains a Canonical Name (CNAME) record. Basically, this allows us to refer to a server by another name. In this example, galaxy is also used for software known as puppet, so a CNAME record has been set up for it. This way, if someone were to try to access galaxy.local.lan or puppet.local.lan, their request would resolve to the same IP address (10.10.96.4). A CNAME records can be very useful if a single server provides more than one service to the network.
 
Earlier, I called out four reverse lookup records, /etc/bind/revp.10.10.96, /etc/bind/revp.10.10.97, /etc/bind/revp.10.10.98, and revp.10.10.99. Next, I'm going to demonstrate one of these files (in this case, for the 10.10.96.0 network):


<pre>
$TTL 1D
$TTL 1D
@ IN SOA hermes.local.lan. hostmaster.local.lan. (
@ IN SOA hermes.local.lan. administrator.local.lan. (
201507261 ; serial
201507261 ; serial
28800 ; refresh (8 hours)
28800 ; refresh (8 hours)
Line 190: Line 178:
3    PTR    nagios.local.lan.
3    PTR    nagios.local.lan.
4    PTR    galaxy.local.lan.
4    PTR    galaxy.local.lan.
With this configuration, you'll notice we have a start of authority record as with our master zone, and we also have a serial number. The same idea applies here. Whenever you update any record (including reverse lookup records), you should update the serial number of the file. The start of authority entry works the same as earlier, no surprises here. Where the file differs is how the hosts are called out. Rather than calling out an entire IP address, we only need to identify the last octet since the entire file is dedicated to reverse IP address lookups from the 10.10.96.0 network. For each of your subnets, you'll need to create a similar file. Again, in our sample configuration there are four subnets, but you don't need that many. It was only provided in this way in order to provide an example of how to handle separate subnets, should you need to do so.
</pre>
 
A few things to note about this file:
* As before, we set the time to live, and the SOA (start of authority)
* This file also has a serial number - like before, change the serial number any time you change the file.
* The name records that are listed (1, 3, and 4) are pointers to particular IP addresses. In this case, we only identify the last octet of the IP address, since the remaining 10.10.96 portion is already set.
* Each subnet should have its own configuration file that looks like the above


With our configuration in place, feel free to restart the bind service on your DNS server and test it out. We can restart bind with the systemctl command, as before.
==Restart Bind Service==


For Debian, use the following command:
<pre>
$ systemctl restart bind9
</pre>


# systemctl restart bind9
==Test DNS Server==
For CentOS, use the following command:


# systemctl restart named
Test your DNS server using the dig utility. Dig stands for Domain Information Groper. It can request information from a DNS server.
One way we can test our DNS server is via the dig command. With Debian, you should already have this package installed. CentOS requires the installation of the bind-utils package. dig (domain information groper) is a utility that allows us to request information from a DNS server. To give it a shot, try it out with an internal hostname:


dig myhostname.local.lan
Try it with an internal host name:
If your DNS server comes up under SERVER in the output, then your DNS server is functioning properly. If for some reason it doesn't, verify what you've typed, your serial number, and whether or not you have restarted bind since your last configuration change.


Feel free to practice setting up additional nodes and records within your DNS server. Setting up bind can be frustrating at first, but stick with it and you'll be a pro in no time. Using examples from this section, you should have a working skeleton you can use to set up a DNS server within your environment. Make sure that you change the hostnames and IP addresses contained within the configuration files to those that match your network. In addition, make sure you set up bind to match your subnets, or remove mentions of other subnets if you don't have any. To be safe, instead of copying the configuration directly from this book, it's usually better to type everything manually just in case.
<pre>
-->
$ dig nagios.local.lan
</pre>


Your DNS server should come up under SERVER in the output - this will ensure the DNS is functioning properly. If not, verify that your config file is correct, that your serial number was incremented, and whether you have restarted BIND since your last configuration change.


Use these as a working skeleton to set up a working DNS server. Change hostnames, IP addresses, and subnets to match your case.





Revision as of 23:22, 14 March 2016

This page contains instructions for setting up a DNS server in Linux.

DNS Server

DNS stands for domain name system - it turns IP addresses into human-readable host names.

DNS is useful for the wider internet, obviously, but is also useful on a small network. DNS is useful for more than a handful of networked computers.

Installing/Starting

On Debian, use bind9 (BIND = Berkeley Internet Name Domain). This is the most popular name server around. Once you install it, Debian should boot it up for you and configure the daemon.

First, install it:

$ apt-get install bind9

Check that it is running:

$ systemctl status bind9
● bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; disabled)
  Drop-In: /run/systemd/generator/bind9.service.d
           └─50-insserv.conf-$named.conf
   Active: active (running) since Mon 2016-03-14 15:00:06 PDT; 18s ago
     Docs: man:named(8)
 Main PID: 16356 (named)
   CGroup: /system.slice/bind9.service
           └─16356 /usr/sbin/named -f -u bind

Mar 14 15:00:06 basilisk named[16356]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
Mar 14 15:00:06 basilisk named[16356]: command channel listening on 127.0.0.1#953
Mar 14 15:00:06 basilisk named[16356]: couldn't add command channel ::1#953: address not available
Mar 14 15:00:06 basilisk named[16356]: managed-keys-zone: loaded serial 0
Mar 14 15:00:06 basilisk named[16356]: zone 0.in-addr.arpa/IN: loaded serial 1
Mar 14 15:00:06 basilisk named[16356]: zone 127.in-addr.arpa/IN: loaded serial 1
Mar 14 15:00:06 basilisk named[16356]: zone 255.in-addr.arpa/IN: loaded serial 1
Mar 14 15:00:06 basilisk named[16356]: zone localhost/IN: loaded serial 2
Mar 14 15:00:06 basilisk named[16356]: all zones loaded
Mar 14 15:00:06 basilisk named[16356]: running

Until the DNS server is configured, it won't be doing anything for us.

Configuring DNS

The configuration file for BIND is located in /etc/bind/named.conf.

If the file has text in it already, back it up and clear it out. Now what we'll do is include two additional configuration files, to make our lives easier:

include "/etc/bind/named.conf.options"
include "/etc/bind/named.conf.local"

Note that we can put those files wherever we want, and create our own layout of configuration files.

Configure DNS Forwarding

Start by setting up your DNS server to forward DNS requests that it can't handle to another (public) DNS server. Start by editing the BIND configuration options:

$ vim /etc/bind/named.conf.options

Edit this file and add the following contents:

options {
    forwarders {
        8.8.8.8; 8.8.4.4;
    };
};

What we are doing here is to create instructions for where to forward DNS requests, if it cannot find what it is looking for. (Note that this is usually done by default, but doing it this way allows us to specify which DNS servers to use.) These two (8.8.8.8 or 8.8.4.4) are both name servers from Google.

Local DNS Configuration

Now we can set up the DNS configuration for the local network and its subnets. Start by editing the file:

$ vim /etc/bind/named.conf.local

Add the following contents to that file:

zone "local.lan" IN {
    type master; file "/etc/bind/net.local.lan";
};

zone "96.10.10.in-appr.arpa" {
    type master; notify no; file "etc/bind/revp.10.10.96";
};

zone "97.10.10.in-appr.arpa" {
    type master; notify no; file "etc/bind/revp.10.10.97";
};

zone "98.10.10.in-appr.arpa" {
    type master; notify no; file "etc/bind/revp.10.10.98";
};

zone "99.10.10.in-appr.arpa" {
    type master; notify no; file "etc/bind/revp.10.10.99";
};

Here is an explanation of the pieces:

  • The first line defines our local domain name. We picked the very boring name of "local.lan"
  • This block calls out another file, "/etc/bind/net.local.lan"
  • The remaining four blocks create configurations for reverse lookups on the four subnets we are creating. If you only have one subnet on your network, you will only include one block for the one subnet.
  • Each subnet has its own reverse-lookup file where we can configure things. Each file is stored in /etc/bind.

DNS Records

Now let's look at the actual DNS records (in the reverse-lookup files listed in the code above).

Starting with /etc/bind/net.local.lan:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; dns zone for for local.lan network
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

$TTL 1D

@ IN SOA local.lan. administrator.local.lan. (

201507261 ; serial

8H ; refresh
4H ; retry
4W ; expire
1D ) ; minimum
IN A 10.10.96.1
;
@ IN NS hermes.local.lan.
ceres           IN      A   10.10.98.1
euphoria        IN      A   10.10.97.4
galaxy          IN      A   10.10.96.4
hermes          IN      A   10.10.96.1
puppet      CNAME galaxy
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; end dns zone for for local.lan network
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Going through this line by line:

  • TTL is time to live, set to 1 day - this is how long DNS records are cached (important with multiple DNS servers or dynamic IP addresses)
  • SOA is start of authority, which defines which comptuer has DNS authority on this local network. The administrator.local.lan is an email address.
  • 201507261 is the serial number. if you change a zone file in bind, you should change this serial number. It is the first thing the daemon reads and it is how the daemon knows if the DNS records have been changed. Always increment the serial number by 1 if you change the file.
  • The refresh/retry/expire/maximum settings dictate how often other (non-master) DNS servers will be told to check for updates (H = hours, W = weeks, D = days). Normally there are no non-master DNS servers, so this won't do anything. But if you do add more DNS servers, you'll have to set this stuff.
  • @ IN NS hermes.local.lan identifies the name server. The name "hermes" is an arbitrary name for the local computer running the DNS server.
  • galaxy IN A 10.10.96.4 - there are four sample address records given in the file above. The records map the listed domain name ("galaxy") to a particular host IP address. If someone looks for galaxy.local.lan the DNS server will resolve it to the IP address 10.10.96.4. The letter "A" indicates the type of CNAME record.

Subnet Configuration

The last remaining task is to configure each subnet using the subnet configuration files specified above.

As an example, the 10.10.96.0 subnet would have the following configuration file:

$TTL 1D
@ IN SOA hermes.local.lan. administrator.local.lan. (
201507261 ; serial
28800 ; refresh (8 hours)
14400 ; retry (4 hours)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
;
@ NS hermes.local.lan.
1    PTR    hermes.local.lan.
3    PTR    nagios.local.lan.
4    PTR    galaxy.local.lan.

A few things to note about this file:

  • As before, we set the time to live, and the SOA (start of authority)
  • This file also has a serial number - like before, change the serial number any time you change the file.
  • The name records that are listed (1, 3, and 4) are pointers to particular IP addresses. In this case, we only identify the last octet of the IP address, since the remaining 10.10.96 portion is already set.
  • Each subnet should have its own configuration file that looks like the above

Restart Bind Service

$ systemctl restart bind9

Test DNS Server

Test your DNS server using the dig utility. Dig stands for Domain Information Groper. It can request information from a DNS server.

Try it with an internal host name:

$ dig nagios.local.lan

Your DNS server should come up under SERVER in the output - this will ensure the DNS is functioning properly. If not, verify that your config file is correct, that your serial number was incremented, and whether you have restarted BIND since your last configuration change.

Use these as a working skeleton to set up a working DNS server. Change hostnames, IP addresses, and subnets to match your case.


Related

See the Template:LinuxNetworkingFlag for more related pages.