[Network Administration]: DNS

The first part of this new network is a DNS (Domain Name Service) Server. Probably it’s not really needed, but there are some advantages setting one up, and it wasn’t really all that difficult. Some of the reasons are:

  • Ability to centralize machine names into a single location – This was a pretty big one. I have a NAS that I use, and I’m setting up some servers, so to be able to reference them by name, I would have to keep a list of machines and IP addresses on every machine’s local /etc/hosts file to be able to use address by name. If a machine had an IP address change, then each of the /etc/hosts files would have to be updated to keep them all in sync. There are not a lot of files to keep up to date, but I liked the idea of a single reference point where I can have all of the information.
  • Ability to use aliases to refer to machines based on what services they provide – This is a pretty significant advantage also. By creating a CNAME entry for the different services that I use, I can easily point at different physical machines and modify them as needed. For example, I can reference my LDAP directory by using the hostname ldap.example.com, and have a CNAME entry point this at an actual machine, say hopper.example.com which runs the LDAP server. In the future, if I wanted to move this to a different machine, for example cerf.example.com, I just have to update the CNAME record on the DNS server, and all of the clients will route to the proper machine without having to make any local changes. The same can be done for the Kerberos KDC, a web server, a NAS filer containing specific data, etc.

Setup:
I’m using an Ubuntu machine for my DNS server, and BIND9 from Internet Systems Consortium as by DNS. It’s open source, and widely used. There is documentation to configure this under Ubuntu and information in the BIND9 Ubuntu community page. I also read through Pro DNS and BIND 10. The package to install is bind9 and I also install dnsutils. I have machines on the local network with IP addresses as 192.168.1.XXX (or specified as 192.168.1.0/24). I’m going to give these domain names as >something<.internal.example.com. This way, I can by name tell which are inside and which are outside. ( I don’t have anything outside necessarily, but I have an external DNS entry that points at my gateway from the internet and this will be without the internal portion of the name.

I want to configure my server as a master. Master just means that the zone file is located on the local filesystem, as opposed to a slave which gets the zone entries from a different machine – the master. It’s going to be authoritative for some zones that I specify (the ones on my local network). The configuration files for BIND9 are located in /etc/bind. The configuration is in /etc/bind/named.conf which calls out to other files for options, and zones to configure. The first part is to set forward external DNS requests out. In my case, this is crappy Comcast, so I set the DNS server IP addresses in the forwarders portion of /etc/bind/named.conf.options. I also disallow any zone transfers. I don’t see any reason why someone would transfer zones from me.

options {
...
        forwarders {
             75.75.75.75;
             75.75.76.76;
        };
...
       // Disable zone transfers
        allow-transfer { none; } ;
...
}

I’ve got my local network on 192.168.1.XXX. So, this is essentially the zone that my server will be master for. I want to remove this from the /etc/bind/named.conf.local file which currently lists this as an empty zone.

//zone "168.192.in-addr.arpa" { type master; file "/etc/bind/master/master.empty"; };

We’ll declare that we’re the authoritative master for this subnet in /etc/bind/named.conf.default-zones

acl internals { 192.168.1.0/24; };

zone "internal.example.com" in {
        type master;
        file "/etc/bind/master/master.internal.example.com";
        forwarders { };
        allow-query { internals; };
        allow-update { none; };
};

zone "1.168.192.in-addr.arpa" in {
        type master;
        file "/etc/bind/master/master.1.168.192.in-addr.arpa";
        forwarders { };
        allow-query { internals; };
        allow-update { none; };
};

There are two zone entries that I’ve added. The first is the forward lookup – from a name to an IP address. The second is the reverse lookup from the IP address to the machine name. I am specifying that this is the master for both of these zones, the files that the zone entries are found in, and that I’m not allowing any updates to the zone entries (No dynamic DNS, and no one can update the entries).

Zone Files:
These are pretty straight forward. Here is a forward zone file. It specifies a resource record for my domain.

;
; BIND data file for example.com domain
;
$TTL    2d ; 2 days
$ORIGIN internal.example.com. ; base domain name
; Start of Authority RR
@       IN      SOA     ns1.internal.example.com. hostmaster (
                        2015050601 ; Serial
                        12h        ; Refresh
                        15m        ; Retry
                        3w         ; Expire
                        2h         ; Negative Cache TTL
                        )
;
; Nameserver for the domain
        IN      NS      ns1.internal.example.com.
; Primary internal mailserver for the domain
        IN      MX       5 smtp.internal.example.com.
        IN      MX      10 smtp.example.com.
; Secondary (relay) mailserver for the domain
        IN      MX      20 mail.example.com.
; Define hosts for the domain
ns1             IN      A       192.168.1.10
server1         IN      A       192.168.1.11
nas-01          IN      A       192.168.1.12
linux           IN      A       192.168.1.13
smtp            IN      A       192.168.1.14

; External hosts
mail            IN      A       xxx.xxx.xxx.xxx

; Aliases
kdc1            IN      CNAME   server1
ldap            IN      CNAME   server1

; Add KRB5 realm information
_kerberos          IN   TXT     "EXAMPLE.COM"
_kerberos._udp     IN   SRV     1 0 88 server1
_kerberos._tcp     IN   SRV     1 0 88 server1
_kerberos-adm._tcp IN   SRV     1 0 749 server1
_kpasswd._udp      IN   SRV     1 0 464 server1

It should be obvious by now that my network is not called “example.com”, but we’ll work with this as our domain name. It would need to be replaced with whatever is appropriate. Also, not the trailing “.”(period) at the end of the domain names in the zone file. This represents the root of the DNS hierarchy under which sit the top level domains, such as .net, .org, .com, etc… The zone file and the resource records are documented in the BIND9 Server documentation. Here’s some relevant information for the zone file.

Every line that starts with “;” is a comment.

$TTL    2d ; 2 days
$ORIGIN internal.example.com. ; base domain name

The next two lines are some defaults that we set.
The first line specifies the default TTL (time to live) for the records, after which they are no longer assumed to be valid. The second one specifies the default origin domain (which is our domain that we’re defining). Again, note that the “.”(period) at the end to specify that it’s a fully qualified domain name. The $ORIGIN directive will replace any instances of “@” that follow the directive. Such as the in the SOA resource record that immediately follows it. Also, the $ORIGIN will be used as the domain for any hostname that is not fully qualified that follows the directive. For example in the SOA record that immediately follows it, the hostname “ns1.internal.example.com.” could be replaced with just “ns1” and the $ORIGIN directive will be appended to it to create “ns1.internal.example.com.”. Again, not the trailing “.”(period) at the end to signify a fully-qualified name vs not.

; Start of Authority RR
@       IN      SOA     ns1.internal.example.com. hostmaster (
                        2015050601 ; Serial
                        12h        ; Refresh
                        15m        ; Retry
                        3w         ; Expire
                        2h         ; Negative Cache TTL
                        )

This is our start of authority resource record. The “@” at the beginning of the line will be replaced by the origin that is specified above. It’s the same as if we started the line with “internal.example.com.”. “IN” means that the record class is internet. “SOA” specifies that it’s Start of Authority resource record. The next field specifies the master for the domain. In our case, this is “ns1.internal.example.com.”, or the machine that this zone file resides — and which we are currently setting up. The last field here before the open parenthesis is the email address of an administrator of the zone. In our case, this administrative email address is “hostmaster@internal.example.com.” The records in the parentheses can be split across lines. The first is a serial number for the record. I use {year,month,day,2-digit incremented number} for my serial number. It just has the be increasing. It lets slave DNS servers know when the master record is updated and needs to be propagated. The last four records are pretty straight forward and mainly deal with how the slave DNS servers update their records. The negative cache TTL is how long slave DNS servers keep negative responses about the domain.

;
; Nameserver for the domain
        IN      NS      ns1.internal.example.com.

The “NS” record defines the nameservers for our domain. Since there is no origin domain specified, it’s taken to be the value that is set in the $ORIGIN directive. We just have a single nameserver. If we had a backup server, then it would also be listed here.

; Primary internal mailserver for the domain
        IN      MX       5 smtp.internal.example.com.
        IN      MX      10 smtp.example.com.
; Secondary (relay) mailserver for the domain
        IN      MX      20 mail.example.com.

These “MX” records are used in the delivery of mail for the domain. The third field listed (not counting the implicit origin domain at the beginning of the record) describe the priority of mail delivery. Lower numbers are attempted first. In this record, first mail is attempted to be delivered to “smtp.internal.example.com.”, then “smtp.example.com.”, and finally to “mail.example.com.”. The first machine is on my local network, and the other two are outside (since they are no longer in the “internal.example.com.” domain that we are describing in this zone. They will attempted to be resolve like all records that are outside our authoritative zone. The hosts listed here must have an “A” record. They cannot simply have a “CNAME” record.

; Define hosts for the domain
ns1             IN      A       192.168.1.10
server1         IN      A       192.168.1.11
nas-01          IN      A       192.168.1.12
linux           IN      A       192.168.1.13
smtp            IN      A       192.168.1.14

; External hosts
mail            IN      A       xxx.xxx.xxx.xxx

These are our “A” or host address records. This is the translation between the names of machines and their IPv4 addresses. For IPv6 addresses, these would be “AAAA” records. The last one is an address record for one of the MX hosts that are specified above. On the external DNS server, this host defined through a CNAME record, so we give an “A” address record for this machine from the point of view of of queries to this domain server.

; Aliases
kdc1            IN      CNAME   server1
ldap            IN      CNAME   server1

These are our “CNAME” or canonical names of alias records. This allows us to reference hosts with other names. This is where we can reference machines by the services that each provides. This record will enable lookups of “kdc1.internal.example.com” and having them resolve to “server1.internal.example.com” and then to “192.168.2.11” as the IP address. These records will allow a single point of change to move a service from one host to another. For example, if I wanted to change the LDAP server from server1 to server2, I can make a change here and the LDAP clients configured to connect to “ldap.internal.example.com” will communicate with server2 instead of server1.

; Add KRB5 realm information
_kerberos          IN   TXT     "EXAMPLE.COM"
_kerberos._udp     IN   SRV     1 0 88 server1
_kerberos._tcp     IN   SRV     1 0 88 server1
_kerberos-adm._tcp IN   SRV     1 0 749 server1
_kpasswd._udp      IN   SRV     1 0 464 server1

Finally, I add some kerberos information to be broadcast by the DNS server. These are specific to kerberos.

In addition to the forward zone file, there is also a reverse lookup zone file.

; BIND reverse data file for local ipv4 loopback interface
;
$TTL    2d ;
$ORIGIN 1.168.192.in-addr.arpa. ; base domain name
@       IN      SOA     ns1.internal.example.com. hostmaster (
                        2015050601 ; Serial
                        12h        ; Refresh
                        15m        ; Retry
                        3w         ; Expire
                        2h         ; Negative Cache TTL
                        )
;
@       IN      NS      ns1.internal.example.com.
10      IN      PTR     ns1
11      IN      PTR     server1
12      IN      PTR     nas-01
13      IN      PTR     linux
14      IN      PTR     smtp

Most of the information here is similar to the forward zone file, except for the “PTR” records. These will remap the IP address, the concatenation of the value in the first field of the record with the subnet in the SOA record, to a host name. For example, this will map 192.168.1.10 to ns1.internal.example.com
Configuration and Data Backup
I backup the directory /etc/bind. The configuration files are stored there. I should be able to fully recreate my server with the configuration directory in the backup once the binaries are installed.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s