BIND – Quick Reference Notes for De Beast!

Some DRY theory FOR BIND DNS:

BIND can be used to run a caching DNS server or an authoritative name server, and provides features like load balancing, notify, dynamic update, split DNS, DNSSEC, IPv6, and more. Berkeley Internet Name Domain (BIND) is the most popular Domain Name System (DNS) server in use today.

MY NOTES:

Following post contains quick reference notes on howto deploy BIND DNS server as MASTER/SLAVE for LAN/WAN. This post also contains some tweaks / tips to make life little easier for my self. At some of my clients, I deployed BIND (at some placed UNBOUND) & created few custom commands menu so that client uses the webmin gui module of webmin to modify records , service reload , service restart, dns test etc. Webmin panel example for operator. Webmin do contain full module to manage BIND, but to get the minimum to the point panel, I used some commands & bash script & tagged it with webmin menu.

Scenario:

We have a public domain name example.com & we want to host our own authoritative public dns server so that dependency on host provider reduced & we can manage all types of records at our site. All Internal clients can use our DNS to resolve dns related queries & other hosts on  internet can resolve our domain related hosts via our DNS server. In this scenario our clients will use our dns as primary for resolving, and other internet zones resolving will be forwarded to other public DNS.

Assumptions before proceeding …

• This post contains info for BIND with ipv4 Only
• Domain Name: example.com
• We will have two servers which will be designated as our DNS name servers. This guide will refer to these as ns1 and ns2
• We will have two additional client pc’s records that will be using the DNS infrastructure you create, referred to as
• We will configure MASTER/SLAVE configuration so that in case primary goes down, secondary will still be available to fulfill resolving.
  Primary DNS: ns1.example.com – 10.0.0.1
  Secondary DNS : ns1.example.com – 10.0.0.2
• Using your hosting provider CPANEL, goto DNS management section & change the default nameservers pointing to your local DNS (local DNs must have static public ip address & must be accessible/allowed via any firewall u might have), example below
  
• For Reverse PTR records, use APNIC panel, & configure Reverse DNS Delegation, example below
  
• Every time you modify zone records, make sure to reload the bind9 service or use the bash script which can change the records as per date/seconds & reload bind service which will trigger SLAVE server to replicate from Master.

When configured as a recursive server, BIND will first use the zones for which it is authoritative before walking down the entire DNS tree from the root/forwarder. for other ZONES , we have configured forwarders, (and root servers can be used in absence of forwarder). We can even create multiple zones, the only limitation is that you will need to maintain all the records in zones you create and ensure they are up to date.

Once we configure & test our DNS, next step is to change NS records on your hosting provider cpanel so that internet can resolve your domain name using your hosted DNS server.

Housekeeping Stuff !

Before installing Bind, we need to perform some housekeeping Stuff first,

NTP:

Make sure you have correct date time syncing with any NTP server with appropriate Time zone as well.

BIND installation on Ubuntu 16.4:

Force IPV4 Only

• OS Level:

Copy Paste below to disable ipv6

• BIND Level ipv4 config:

Example:

• RESOLV.CONF:

Once BIND is installed, you may want to modify the resolv.conf to look something like below
(For permanent changes, edit  appropriate settings in /etc/network/interfaces file)

** Configuration files for BIND9 – MASTER **

Default installation location folder is /etc/bind9. We will create subfolder named ZONES to hold all zones files separately. Also we will add forwarder/reverse records files location so that BIND should know where our ZONES files are located.

BIND9 DNS Zones Location & Master/Slave Config File

• named.conf.local [It will contain ZONE Files & its parameters]

Edit below file to enter zone name, type, file location etc

• named.conf.options [It will contain ACL , Forwarders & related parameters]

• ZONE FILES Location and FORWARDER Configuration File:

It will contain zone details , all dns related records

First Create a folder named ZONES which will contain our zones files (forwarders/reverse)

FORWARDER Configuration File:

Save & Exit.

REVERSE Configuration File:

It will contain reverse PTR records & also $GENERATE statement for auto generation of unused ips ptr records for 

Example File:

Save & Exit.

BIND ZONE FILES CHECK CMD’s

Every time you edit the zone files, its better to run a checkzone cmd to ensure there are no syntax mistakes.

• a) Main File Syntax Check

If your named configuration files have no syntax errors, there won’t be any error messages and you will return to your shell prompt. If there are problems with your configuration files, review the error message , troubleshoot & fix it, then try named-checkconf again

• b) Zone File Syntax Check

** Configuration files for BIND9 – SLAVE **

Configuring SLAVE is quite simple. Install the BIND on 2nd server (ns2.example.com). set its resolv.conf to its own ip. Edit below files

NOTE: You have to define all Forwarder/Reverse ZONES defined in MASTER ns1 server in this config

Example File:

Save & Exit.

Now edit the /etc/bind/named.conf.options & copy paste all data from master ns1 named.conf.options file. You have to modify just one parameter listen-on to point it to ns2 ip example

• listen-on { 10.0.0.2; };

Save & Exit. & restart BIND

now look at syslog file to check for any errors

BIND Service Related CMD’s

*** Find BIND version CMD

*** BIND Service related CMD's

*** BIND Service Internal STATS

RNDC Result Example: version: BIND 9.10.3-P4-Ubuntu <id:ebd72b3> (syed.jahanzaib) boot time: Wed, 19 Oct 2022 10:18:47 GMT last configured: Wed, 19 Oct 2022 10:18:47 GMT CPUs found: 16 worker threads: 16 UDP listeners per interface: 8 number of zones: 115 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 28/9900/10000 tcp clients: 14/1000 server is up and running [/sourcecode]

NSLOOKUP Test: (Windows)

DIG Test: (Linux)

Perform nslookup/dig on dns server

TIPS:

• SERIAL of SOA

The serial number of the SOA record is very important to the correct operation of slave servers. Each time you edit your zone, the serial number must be increased so that the slave server can detect that the zone has been updated. Whenever the slave server notices that the serial number has changed, it performs a zone transfer and updates its cached zone file.

Every time, you make any changes in MASTER NS zone file, Ensure following

• Change Serial Number , else it will not be replicated to Slave.
• Reload bind by

• Auto Generation of PTR Records pointing to fixed generated IP-Hostname

If we want to reply the reverse PTR records automatically for our unused IP’s, Edit the REVERSE zone & add following line in the end

Save & Exit, & Reload BIND9 service by

now if you do nslookup for any unused ip/record from your user pool, you will get results as below

• BASH Script to change ZONE SERIAL number with YYMMDDnn format 

If you have Master/Slave Setup, then you need to update the serial number in zones every time you make any modifications, else it will not replicate to SLAVE. A bash script is handy to run when you update any record, it will update serial to YYMMDDSS (SS=sequence Serial) number, and will increment the SS every time u run it. so total of 99 changes u can make in single date.

Old Serial Number can be any number but the script will change it to current date like YYYYMMDDSS, example shown afterwards

• /temp/reload.sh

• NOTE: This bash script looks in /etc/bind/zones, and will search text ‘Serial’, So make sure your zone file contains ; Serial word in zone file. Example below

Bash Script named /temp/reload.sh

Result: After modifying any record, run this script. every time you run the script, it will just increment one number in last 2 digits, (it can be max of 99 till the SOA expires, or single day)

I have tagged this file with webmin, so that when user edit the record file and hit save and close, this file runs and do the job, and all data gets replicate to the SLAVE automatically. Also you schedule it to hourly or as per requirements.

• SLAVE ZONE FILES RAW FORMAT

With BIND 9.9.x, the slave zone files are now saved in a default raw binary format. This was done to improve performance, but at the sacrifice of being able to easily view the contents of the files. it can  also make debugging at SLAVE level more difficult.  If you want to see the slave zone files in plain text, just simple add following in the the named.conf files for your slave zones to include the line: (This has to be done at MASTER/NS1 dns)

• REDUCE LOGGING FOR BIND9

BIND uses syslogd before a valid logging clause is available so named.conf parse errors and other information will appear in /var/log/syslog. To separate log from SYSLOG & record them in separate file & fix the log size, you can add following in /etc/bind/named.conf.option at end,

now reload BIND9 service

check the file contents

Once the file size will cross 5 MB, it will reset to 0 auto and will continue to grow till 5 & reset again 🙂 as shown in below image …

For more customized info, Please read below …

Different Types of DNS Records With Syntax and Examples

Types of DNS Records

A
AAAA
CNAME
MX
PTR
NS
SOA
SRV
TXT
NAPTR

The above DNS records are mostly used in all DNS Configurations.

A Record Example

Address Record, assigns an IP address to a host, domain or subdomain name

PTR Record Example

A PTR record or pointer record maps an IPv4 address to the canonical name for that host. This is mostly used as a security and an anti-spam measure wherein most of the webservers or the email servers do a reverse DNS lookup to check if the host is actually coming from where it claims to come from. It is always advisable to have a proper reverse DNS record (PTR) is been setup for your servers especially when you are running a mail / smtp server.

SPF Record Example

The Sender Policy Framework (SPF) is an email-authentication technique which is used to prevent spammers from sending messages on behalf of your domain. With SPF an organization can publish authorized mail servers. Together with the DMARC related information, this gives the receiver (or receiving systems) information on how trustworthy the origin of an email is. SPF is, just like DMARC, an email authentication technique that uses DNS (Domain Name Service). This gives you, as an email sender, the ability to specify which email servers are permitted to send email on behalf of your domain.

DMARC Record Example

DKIM (MultiLine) Record Example