Bind Operations - Set Up DNS Server
External
- Red Hat Support Solution (used to write the procedure below) https://access.redhat.com/solutions/40683
- Red Hat Enterprise Linux 7 Networking Guide - Chapter 11 DNS Servers https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-DNS_Servers.html
- Red Hat Enterprise Linux 6 Deployment Guide - DNS Servers https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-DNS_Servers.html
- Step by Step how to setup a DNS Server in RHEL 6 Using Bind https://github.com/blackyboy/RedHat-Centos-Common-Stuffs/blob/master/Step-by-Step-how-to-setup-a-DNS-Server-in-RHEL-6.2-6.4-6.5-Using-Bind.md
Internal
Overview
This is a step by step guide on installing and configuring a bind DNS server. We needed it during the deployment of an OpenShift environment. During this procedure, we will create a new "openshift35.local" zone file and all OpenShift hosts will get names within the "*.openshift35.local" DNS domain. Additional zone files/local domains can be added later.
Relevance
- RHEL 7.1
- Centos 7.3
Binary Installation
Intall bind binaries:
yum install bind* -y
DO NOT yum remove bind*, it will remove dhclient and related libraries, and that might render your host inoperable.
Starting and Stopping the Server
Installing binaries will deploy a bind server with a basic configuration that can be started and stopped.
Starting the Server
You can start the server right away, it should start fine. See Troubleshooting the Server.
systemctl start named
Stopping the Server
systemctl stop named
Startup Options
named startup options are specified in /etc/sysconfig/named as follows:
OPTIONS="-4 -d 10"
where:
-4
Instructs the server to use IPv4 only even if the host machine is capable of IPv6. -4 and -6 are mutually exclusive.
-6
Instructs the server to use IPv6 only even if the host machine is capable of IPv4. -4 and -6 are mutually exclusive.
-d <debug-level>
Specifies the debug level. Usually 10l.
Edit /etc/named.conf
/etc/named.conf is the main configuration file.
Use the default and modify the following:
listen-on
Specifies the IPv4 network interface on which to listen for queries.
On a DNS server that acts as a gateway, you can use this option to answer queries originating from a single network only. All IPv4 interfaces are used by default.
options {
...
listen-on port 53 { any; };
...
}
Alternatively, to specify a single interface:
listen-on port 53 { 172.30.0.3; };
or several:
listen-on port 53 { 127.0.0.1;172.30.0.3; };
listen-on-v6
Specifies the IPv6 network interface on which to listen for queries.
On a DNS server that also acts as a gateway, you can use this option to answer queries originating from a single network only. All IPv6 interfaces are used by default.
options {
...
listen-on-v6 port 53 { any; };
...
}
To prevent listening on IPv6 ports:
listen-on-v6 port 53 { none; };
}
allow-query
Specifies which hosts are allowed to query the nameserver for authoritative resource records.
It accepts an access control list, a collection of IP addresses, or networks in the CIDR notation. All hosts are allowed by default.
options {
...
allow-query { any; };
...
}
Alternatively, an "acl" can be specified as follows:
...
acl allowed-to-query {
172.30.0.0/16;
localhost;
localnets;
};
options {
...
allow-query { allowed-to-query; };
...
}
Configuring Recursive Resolution
If a name cannot be resolved by the current bind server, the query is forwarded to parent DNS servers. This makes the DNS server a recursive DNS server.
Recursion is enabled by using "recursion" keyword:
options {
...
recursion yes;
...
}
If the recursive DNS server has a public IP address, then access control MUST be enabled to limit queries to legitimate users. Failing to do so will cause the server to become part of large scale DNS amplification attacks.
Domain Name System Security Extensions (DNSSEC) Configuration
options {
...
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
...
}
Adding a Zone
Add a zone in /etc/named.conf, as follows. Conventionally, place it between the zone "." declaration and "include", as shown below.
More than one zone file can be declared.
In case of sub-domains, a separate zone file should be added for each sub-domain, as shown below for "openshift.external" and "apps.openshift.external".
...
zone "." IN {
type hint;
file "named.ca";
};
zone "openshift.local" IN {
type master;
file "openshift.local.zone";
};
zone "openshift.external" IN {
type master;
file "openshift.external.zone";
};
zone "apps.openshift.external" IN {
type master;
file "apps.openshift.external.zone";
};
include "/etc/named.rfc1912.zones";
...
"zone" Statement Syntax
zone "<zone-name>" <zone-class> {
type master;
file "<file-name>";
};
- <zone-name> - is the name of the zone. The named daemon appends the name of the zone to any non-fully qualified domain name listed in the associated zone file. If the result matches the name in the query, the associated address is returned. If the zone file contains "*", then any name in the query that ends in <zone-name> matches and the address associated to "*" in the zone file is returned. This is how wildcard DNS domains are configured.
- <zone-class> is optional and if not mentioned, IN is assumed. IN refers to 'Internet' while the only other option in common use is CH for 'CHAOS'.
- type master - designates this name server as authoritative for this zone. A zone should be set as the master if the zone's configuration files reside on the system.
- file - specifies the name of the file in the named working directory, by default /var/named, which contains the zone's configuration data.
Zone File
Zone files contain information about a domain. The zone files are stored in /var/named. Each zone file is named according to the "file" option in /etc/named.conf. Each zone file contains directives and resource records. Directives tell the nameserver to perform tasks or apply special settings to the zone. Resource records define the parameters of the zone and assign identities to individual hosts. All directives and resource records should be entered on individual lines. Comments can be placed after semicolon characters (;).
Directives
$TTL
Sets the default Time to Live (TTL) value for the zone. This is the length of time, in seconds, that a zone resource record is valid. Each resource record can contain its own TTL value, which overrides this directive. Increasing this value allows remote nameservers to cache the zone information for a longer period of time, reducing the number of queries for the zone.
Resource Records
SOA
The Start Of Authority resource record, which contains authoritative information about the namespace. The SOA resource record is the first resource record in a zone file.
@ IN SOA <primary-name-server> <hostmaster-email> ( <serial-number> <time-to-refresh> <time-to-retry> <time-to-expire> <minimum-TTL> )
The @ symbol places the $ORIGIN directive (or the zone's name, if the $ORIGIN directive is not set) as the namespace being defined by this SOA resource record. The hostname of the primary nameserver that is authoritative for this domain is the <primary-name-server> directive, and the email of the person to contact about this namespace is the <hostmaster-email> directive.
The <serial-number> directive is a numerical value incremented every time the zone file is altered to indicate it is time for named to reload the zone. The <time-to-refresh> directive is the numerical value slave servers use to determine how long to wait before asking the master nameserver if any changes have been made to the zone. The <serial-number> directive is a numerical value used by the slave servers to determine if it is using outdated zone data and should therefore refresh it.
The <time-to-retry> directive is a numerical value used by slave servers to determine the length of time to wait before issuing a refresh request in the event that the master nameserver is not answering. If the master has not replied to a refresh request before the amount of time specified in the <time-to-expire> directive elapses, the slave servers stop responding as an authority for requests concerning that namespace.
The <minimum-TTL> directive is the amount of time other nameservers cache the zone's information.
When configuring BIND, all times are specified in seconds.
Example
Start with named.localhost as a model.
cd /var/named cp named.localhost openshift.local.zone
Make sure the file has the same ownership as the rest of the files in the directory:
chown root:named openshift.local.zone
Assigning the ownership is critical. The file won't be read and names from the file will not be resolved otherwise.
/var/named/openshift.local.zone:
$TTL 3600
@ IN SOA openshift.local. root (
2015092101 ; serial
3600 ; refresh
15M ; retry
1W ; expire
1D ) ; minimum
IN NS localhost
localhost IN A 127.0.0.1
ns IN A 172.20.2.10
openshift-master1 IN A 172.20.2.1
openshift-node1 IN A 172.20.2.2
openshift-node2 IN A 172.20.2.3
Zone File Syntax
PTR (Inverse Record) File
TODO: not tested.
/var/named/openshift.local.rzone:
$TTL 3600 @ IN SOA openshift.local. root.openshift.local. ( 2015092101 ; serial 3600 ; refresh 15M ; retry 1W ; expire 1D ) ; minimum IN NS localhost. 172.20.2.1 IN PTR openshift-master1.openshift.local. 172.20.2.2 IN PTR openshift-node1.openshift.local.
Make sure the file has the same ownership as the rest of the files in the directory:
chown root:named openshift.local.rzone
Assigning the ownership is critical. The file won't be read and names from the file will not be resolved otherwise.
I think the reverse resolution is not fully enabled until I add something like the following in /etc/named.conf:
zone"0.168.192.in-addr.arpa" IN {
type master;
file "reverse.linuxzadmin";
allow-update { none; };
};
Verify Configuration Files
named-checkconf /etc/named.conf named-checkzone <zone-name> <zone-file> named-checkzone openshift.local.zone /var/named/openshift.local.zone
Configure iptables
Add the following rules to your iptables configuration:
... iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT iptables -A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT ...
For more details on the iptables configuration, see
Make sure the correct rules are in place with iptables -F:
Also see
Declared a Wildcard DNS Domain
A wildcard DNS sub-domain is a domain that resolves all the host and subdomains under it to the same IP address.
Note that the sub-domains are logically hierarchical, a different zone file is required for each sub-domain. The zone files are separate entities and do not have a hierarchical structure. For more details see
This is an example of a zone file for the "apps.openshift35.external" wildcard subdomain. The content goes to /var/named/apps.openshift35.external.zone:
$TTL 3600 @ IN SOA apps.openshift35.external. root ( 2017052401 ; serial 3600 ; refresh 15M ; retry 1W ; expire 1D ) ; minimum IN NS localhost IN A 172.23.0.12 localhost IN A 127.0.0.1 * IN A 172.23.0.12
Make sure the file has a "root:named" ownership:
chown root:named apps.openshift35.external.zone
Assigning the ownership is critical. The file won't be read and names from the file will not be resolved otherwise.
The /etc/named.conf declaration of the zone file:
...
zone "apps.openshift35.external" IN {
type master;
file "apps.openshift35.external.zone";
};
...
An untested alternative is to declare an A record, as shown below:
*.apps.openshift35.external. 300 IN A 1.2.3.4
Starting at Boot
systemctl enable named
Test:
systemctl is-enabled named enabled
Configure The Local DNS Resolver
Same as configuring clients on other machines in the network. See:
Configure DNS Resolver on Other Hosts
Reboot and Test
Local Tests
Assuming that the name of the name server is "ns.openshift.local", and "openshift-master1.openshift.local" is a valid host in domain, after reboot, the following must be successful:
# nslookup ns Server: 172.20.2.10 Address: 172.20.2.10#53 Name: ns.openshift.local Address: 172.20.2.10
# nslookup ns.openshift.local Server: 172.20.2.10 Address: 172.20.2.10#53 Name: ns.openshift.local Address: 172.20.2.10
# nslookup openshift-master1 Server: 172.20.2.10 Address: 172.20.2.10#53 Name: openshift-master1.openshift.local Address: 172.20.2.1
# nslookup openshift-master1.openshift.local Server: 172.20.2.10 Address: 172.20.2.10#53 Name: openshift-master1.openshift.local Address: 172.20.2.1
Also a random (but valid) name must be resolved
# nslookup www.cnn.com Server: 172.20.2.10 Address: 172.20.2.10#53 Non-authoritative answer: www.cnn.com canonical name = turner.map.fastly.net. Name: turner.map.fastly.net Address: 23.235.47.73
Remote Tests
Adding a New Host to the Zone File
Go to the corresponding zone file (example if the domain is openshift.local, the zone file is /var/named/openshift.local.zone)
... master31-1 IN A 172.20.2.11
Also modify the inverse record file /var/named/openshift.local.rzone (if exists)
172.20.2.11 IN PTR master31-1.openshift.local.
Then reboot the name server.
After reboot, run nslookup from the name server itself, an old host and the newly setup host:
[openshift@ns ~]$ nslookup master31-1.openshift.local Server: 172.20.2.10 Address: 172.20.2.10#53 Name: master31-1.openshift.local Address: 172.20.2.11
Troubleshooting the Server
systemctl status named
Logs are generated in two places, and the content is different:
journalctl -f -u named tail -f /var/named/data/named.run
Debug verbosity can be changed by adding the following in /etc/sysconfig/named:
OPTIONS="-d 10"
Troubleshooting Situations
Network Unreachable
error (network unreachable) resolving 'www.cnn.com/A/IN': 2001:7fe::53#53
Got this on a network that prevented UDP DNS traffic. The server resumed working find immediately after I connected to a different network.