BIND: Konfigurasi sebagai private DNS

From OnnoWiki
Revision as of 09:39, 10 October 2018 by Onnowpurbo (talk | contribs)
Jump to navigation Jump to search

Sumber: https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-private-network-dns-server-on-ubuntu-14-04


Install BIND

install BIND

sudo su
apt update
apt install bind9 bind9utils bind9-doc

Setup hanya untuk IPv4 (-4) jika dibutuhkan

vi /etc/default/bind9

Tambahkan (-4)

OPTIONS="-4 -u bind"

Konfigurasi Primary DNS Server

Edit

sudo vi /etc/bind/named.conf.options

Jika dibutuhkan kita bisa menambahkan trusted client

acl "trusted" {
        10.128.10.11;    # ns1 - can be set to localhost
        10.128.20.12;    # ns2
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

Ubah ns1 IP address yang benar, misalnya,

options {
        directory "/var/cache/bind";

        recursion yes;                 # enables resursive queries
        allow-recursion { trusted; };  # allows recursive queries from "trusted" clients
        listen-on { 10.128.10.11; };   # ns1 private IP address - listen on private network only
        allow-transfer { none; };      # disable zone transfers by default

        forwarders {
                8.8.8.8;
                8.8.4.4;
         };
...
};

Konfigurasi Local File

Edit

sudo vi /etc/bind/named.conf.local

Di file ini kita bisa tambahkan forward dan revese zone dari sebuah domain, contoh

zone "nyc3.example.com" {
    type master;
    file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
    allow-transfer { 10.128.20.12; };         # ns2 private IP address - secondary
};

Asumsi private subnet 10.128.0.0/16, reverse zone- adalah,

zone "128.10.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.10.128";  # 10.128.0.0/16 subnet
    allow-transfer { 10.128.20.12; };  # ns2 private IP address - secondary
};


Buat Forward Zone File

Buat dan edit

sudo mkdir /etc/bind/zones
cd /etc/bind/zones
sudo cp ../db.local ./db.nyc3.example.com
sudo vi /etc/bind/zones/db.nyc3.example.com

Isi awalnya kira-kira

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.      ; delete this line
@       IN      A       127.0.0.1       ; delete this line
@       IN      AAAA    ::1             ; delete this line

Dapat kita ubah menjadi, misalnya,

$TTL    604800
@       IN      SOA     ns1.nyc3.example.com. admin.nyc3.example.com. (
                  3       ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800 )   ; Negative Cache TTL
;
; name servers - NS records
     IN      NS      ns1.nyc3.example.com.
     IN      NS      ns2.nyc3.example.com. 

; name servers - A records
ns1.nyc3.example.com.          IN      A       10.128.10.11
ns2.nyc3.example.com.          IN      A       10.128.20.12

; 10.128.0.0/16 - A records
host1.nyc3.example.com.        IN      A      10.128.100.101
host2.nyc3.example.com.        IN      A      10.128.200.102


Create Reverse Zone File(s)

Reverse zone file are where we define DNS PTR records for reverse DNS lookups. That is, when the DNS receives a query by IP address, "10.128.100.101" for example, it will look in the reverse zone file(s) to resolve the corresponding FQDN, "host1.nyc3.example.com" in this case.

On ns1, for each reverse zone specified in the named.conf.local file, create a reverse zone file. We will base our reverse zone file(s) on the sample db.127 zone file. Copy it to the proper location with the following commands (substituting the destination filename so it matches your reverse zone definition):

   cd /etc/bind/zones
   sudo cp ../db.127 ./db.10.128

Edit the reverse zone file that corresponds to the reverse zone(s) defined in named.conf.local:

   sudo vi /etc/bind/zones/db.10.128

Initially, it will look something like the following: /etc/bind/zones/db.10.128 — original

$TTL 604800 @ IN SOA localhost. root.localhost. (

                             1         ; Serial
                        604800         ; Refresh
                         86400         ; Retry
                       2419200         ; Expire
                        604800 )       ; Negative Cache TTL

@ IN NS localhost. ; delete this line 1.0.0 IN PTR localhost. ; delete this line

In the same manner as the forward zone file, you will want to edit the SOA record and increment the serial value. It should look something like this: /etc/bind/zones/db.10.128 — updated 1 of 3

@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (

                             3         ; Serial

Now delete the two records at the end of the file (after the SOA record). If you're not sure which lines to delete, they are marked with a "delete this line" comment above.

At the end of the file, add your nameserver records with the following lines (replace the names with your own). Note that the second column specifies that these are "NS" records: /etc/bind/zones/db.10.128 — updated 2 of 3

name servers - NS records
     IN      NS      ns1.nyc3.example.com.
     IN      NS      ns2.nyc3.example.com.

Then add PTR records for all of your servers whose IP addresses are on the subnet of the zone file that you are editing. In our example, this includes all of our hosts because they are all on the 10.128.0.0/16 subnet. Note that the first column consists of the last two octets of your servers' private IP addresses in reversed order. Be sure to substitute names and private IP addresses to match your servers: /etc/bind/zones/db.10.128 — updated 3 of 3

PTR Records

11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11 12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12 101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101 102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102

Save and exit the reverse zone file (repeat this section if you need to add more reverse zone files).

Our final example reverse zone file looks like the following: /etc/bind/zones/db.10.128 — updated

$TTL 604800 @ IN SOA nyc3.example.com. admin.nyc3.example.com. (

                             3         ; Serial
                        604800         ; Refresh
                         86400         ; Retry
                       2419200         ; Expire
                        604800 )       ; Negative Cache TTL
name servers
     IN      NS      ns1.nyc3.example.com.
     IN      NS      ns2.nyc3.example.com.
PTR Records

11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11 12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12 101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101 102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102

Check BIND Configuration Syntax

Run the following command to check the syntax of the named.conf* files:

   sudo named-checkconf

If your named configuration files have no syntax errors, you will return to your shell prompt and see no error messages. If there are problems with your configuration files, review the error message and the Configure Primary DNS Server section, then try named-checkconf again.

The named-checkzone command can be used to check the correctness of your zone files. Its first argument specifies a zone name, and the second argument specifies the corresponding zone file, which are both defined in named.conf.local.

For example, to check the "nyc3.example.com" forward zone configuration, run the following command (change the names to match your forward zone and file):

   sudo named-checkzone nyc3.example.com db.nyc3.example.com

And to check the "128.10.in-addr.arpa" reverse zone configuration, run the following command (change the numbers to match your reverse zone and file):

   sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

When all of your configuration and zone files have no errors in them, you should be ready to restart the BIND service. Restart BIND

Restart BIND:

   sudo service bind9 restart

Your primary DNS server is now setup and ready to respond to DNS queries. Let's move on to creating the secondary DNS server. Configure Secondary DNS Server

In most environments, it is a good idea to set up a secondary DNS server that will respond to requests if the primary becomes unavailable. Luckily, the secondary DNS server is much easier to configure.

On ns2, edit the named.conf.options file:

   sudo vi /etc/bind/named.conf.options

At the top of the file, add the ACL with the private IP addresses of all of your trusted servers: /etc/bind/named.conf.options — updated 1 of 2 (secondary)

acl "trusted" {

       10.128.10.11;   # ns1
       10.128.20.12;   # ns2 - can be set to localhost
       10.128.100.101;  # host1
       10.128.200.102;  # host2

};

Below the directory directive, add the following lines: /etc/bind/named.conf.options — updated 2 of 2 (secondary)

       recursion yes;
       allow-recursion { trusted; };
       listen-on { 10.128.20.12; };      # ns2 private IP address
       allow-transfer { none; };          # disable zone transfers by default
       forwarders {
               8.8.8.8;
               8.8.4.4;
       };

Save and exit named.conf.options. This file should look exactly like ns1's named.conf.options file except it should be configured to listen on ns2's private IP address.

Now edit the named.conf.local file:

   sudo vi /etc/bind/named.conf.local

Define slave zones that correspond to the master zones on the primary DNS server. Note that the type is "slave", the file does not contain a path, and there is a masters directive which should be set to the primary DNS server's private IP. If you defined multiple reverse zones in the primary DNS server, make sure to add them all here: /etc/bind/named.conf.local — updated (secondary)

zone "nyc3.example.com" {

   type slave;
   file "slaves/db.nyc3.example.com";
   masters { 10.128.10.11; };  # ns1 private IP

};

zone "128.10.in-addr.arpa" {

   type slave;
   file "slaves/db.10.128";
   masters { 10.128.10.11; };  # ns1 private IP

};

Now save and exit named.conf.local.

Run the following command to check the validity of your configuration files:

   sudo named-checkconf

Once that checks out, restart bind

   sudo service bind9 restart

Now you have primary and secondary DNS servers for private network name and IP address resolution. Now you must configure your servers to use your private DNS servers. Configure DNS Clients

Before all of your servers in the "trusted" ACL can query your DNS servers, you must configure each of them to use ns1 and ns2 as nameservers. This process varies depending on OS, but for most Linux distributions it involves adding your name servers to the /etc/resolv.conf file. Ubuntu Clients

On Ubuntu and Debian Linux VPS, you can edit the head file, which is prepended to resolv.conf on boot:

   sudo vi /etc/resolvconf/resolv.conf.d/head

Add the following lines to the file (substitute your private domain, and ns1 and ns2 private IP addresses): /etc/resolvconf/resolv.conf.d/head

search nyc3.example.com # your private domain nameserver 10.128.10.11 # ns1 private IP address nameserver 10.128.20.12 # ns2 private IP address

Now run resolvconf to generate a new resolv.conf file:

   sudo resolvconf -u

Your client is now configured to use your DNS servers. CentOS Clients

On CentOS, RedHat, and Fedora Linux VPS, simply edit the resolv.conf file:

   sudo vi /etc/resolv.conf

Then add the following lines to the TOP of the file (substitute your private domain, and ns1 and ns2 private IP addresses): /etc/resolv.conf

search nyc3.example.com # your private domain nameserver 10.128.10.11 # ns1 private IP address nameserver 10.128.20.12 # ns2 private IP address

Now save and exit. Your client is now configured to use your DNS servers. Test Clients

Use nslookup to test if your clients can query your name servers. You should be able to do this on all of the clients that you have configured and are in the "trusted" ACL. Forward Lookup

For example, we can perform a forward lookup to retrieve the IP address of host1.nyc3.example.com by running the following command:

   nslookup host1

Querying "host1" expands to "host1.nyc3.example.com because of the search option is set to your private subdomain, and DNS queries will attempt to look on that subdomain before looking for the host elsewhere. The output of the command above would look like the following:

Output: Server: 10.128.10.11 Address: 10.128.10.11#53

Name: host1.nyc3.example.com Address: 10.128.100.101

Reverse Lookup

To test the reverse lookup, query the DNS server with host1's private IP address:

   nslookup 10.128.100.101

You should see output that looks like the following:

Output: Server: 10.128.10.11 Address: 10.128.10.11#53

11.10.128.10.in-addr.arpa name = host1.nyc3.example.com.

If all of the names and IP addresses resolve to the correct values, that means that your zone files are configured properly. If you receive unexpected values, be sure to review the zone files on your primary DNS server (e.g. db.nyc3.example.com and db.10.128).

Congratulations! Your internal DNS servers are now set up properly! Now we will cover maintaining your zone records. Maintaining DNS Records

Now that you have a working internal DNS, you need to maintain your DNS records so they accurately reflect your server environment. Adding Host to DNS

Whenever you add a host to your environment (in the same datacenter), you will want to add it to DNS. Here is a list of steps that you need to take: Primary Nameserver

   Forward zone file: Add an "A" record for the new host, increment the value of "Serial"
   Reverse zone file: Add a "PTR" record for the new host, increment the value of "Serial"
   Add your new host's private IP address to the "trusted" ACL (named.conf.options)

Then reload BIND:

   sudo service bind9 reload

Secondary Nameserver

   Add your new host's private IP address to the "trusted" ACL (named.conf.options)

Then reload BIND:

   sudo service bind9 reload

Configure New Host to Use Your DNS

   Configure resolv.conf to use your DNS servers
   Test using nslookup

Removing Host from DNS

If you remove a host from your environment or want to just take it out of DNS, just remove all the things that were added when you added the server to DNS (i.e. the reverse of the steps above). Conclusion

Now you may refer to your servers' private network interfaces by name, rather than by IP address. This makes configuration of services and applications easier because you no longer have to remember the private IP addresses, and the files will be easier to read and understand. Also, now you can change your configurations to point to a new servers in a single place, your primary DNS server, instead of having to edit a variety of distributed configuration files, which eases maintenance.

Once you have your internal DNS set up, and your configuration files are using private FQDNs to specify network connections, it is critical that your DNS servers are properly maintained. If they both become unavailable, your services and applications that rely on them will cease to function properly. This is why it is recommended to set up your DNS with at least one secondary server, and to maintain working backups of all of them.


Referensi