Bind Operations - Set Up DNS Server: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(59 intermediate revisions by the same user not shown)
Line 185: Line 185:
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.
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==
==Configuring Specific Forwarders==
 
If recursion is enabled and the name to be resolved is not in the zone, the DNS server process forwards the request to other DNS servers. By default, it makes the request over UDP on port 53, to root name servers. However, these connections are blocked by some networks, so an alternative is to configure a small set of "forwarders" - like Google's name servers - to query. This is done in the "options" block as follows:


<pre>
<pre>
options {
options {
    ...
    forwarders {
          8.8.8.8;
          8.8.4.4;
    };
    forward only;
    ...
}
</pre>
To configure this server to forward all non-local request and not attempt to resolve requests over the normal protocol, on its own, set the "forward" directive to "only".
==Domain Name System Security Extensions (DNSSEC) Configuration==


options {
     ...
     ...
     dnssec-enable yes;
     dnssec-enable yes;
     dnssec-validation yes;
     dnssec-validation yes;
     dnssec-lookaside auto;
     /* dnssec-lookaside auto; */
 
     /* Path to ISC DLV key */
     /* Path to ISC DLV key */
     bindkeys-file "/etc/named.iscdlv.key";
     bindkeys-file "/etc/named.iscdlv.key";
 
     managed-keys-directory "/var/named/dynamic";
     managed-keys-directory "/var/named/dynamic";
     ...
     ...
}
}
</pre>
 
Note that uncommenting "dnssec-lookaside auto" leads to [[#Broken_Trust_Chain|"broken trust chain" error]].


=Adding a Zone=
=Adding a Zone=
Line 231: Line 250:
         type master;
         type master;
         file "apps.openshift.external.zone";
         file "apps.openshift.external.zone";
};
zone "172.20.2.in-addr.arpa" IN {
        type master;
        file "openshift.local.rzone";
        allow-update { none; };
};
};


Line 254: Line 279:


'''file''' - specifies the name of the file in the named working directory, by default /var/named, which contains the zone's configuration data.
'''file''' - specifies the name of the file in the named working directory, by default /var/named, which contains the zone's configuration data.
A zone has usually an associated reverse zone, which is declared as follows:
<pre>
zone "<first-three-blocks-of-the-ip-address-reversed>.in-addr.arpa" <zone-class> {
        type master;
        file "<file-name>";
        allow-update { node; };
};
</pre>
The reverse name resolution zone requires the first three blocks of the IP address reversed followed by ".in-addr.arpa".


==Zone File==
==Zone File==
Line 259: Line 296:
{{External|https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-bind-zone.html}}
{{External|https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-bind-zone.html}}


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 (;).
Zone files contain information about a domain. The zone files are stored in <tt>/var/named</tt>. Each zone file is named according to the "zone"/"file" option in <tt>/etc/named.conf</tt>. 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 (;).
 
<span id='Directives'></span>
===Zone File Directives===
 
====$ORIGIN====


===Directives===
Appends the domain name to unqualified records in the zone file, such as those with the hostname and nothing more. For example, a zone file may contain the following line:
 
<pre>
$ORIGIN example.com.
</pre>
 
Any names used in resource records that do not end in a trailing period (.) are appended with example.com.
 
The use of the $ORIGIN directive is unnecessary if the zone is specified in <tt>/etc/named.conf</tt> because the zone name declared in <tt>/etc/named.conf</tt> is used as the value for the $ORIGIN directive by default.


====$TTL====
====$TTL====
Line 267: Line 317:
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.
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===
<span id='Resource_Records'></span>
 
===Zone File Resource Records===


====SOA====
====SOA====
Line 274: Line 326:


<pre>
<pre>
@                      IN SOA <primary-name-server> <hostmaster-email> (
@                      IN SOA <primary-name-server>. <hostmaster-email>. (
                        <serial-number>
                        <serial-number>
                        <time-to-refresh>
                        <time-to-refresh>
Line 284: Line 336:
The @ symbol places the [[#zone-name|zone name]], as defined in the "[[#.22zone.22_Statement_Syntax|zone]]" named.conf statement, 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. Both elements must end in "."
The @ symbol places the [[#zone-name|zone name]], as defined in the "[[#.22zone.22_Statement_Syntax|zone]]" named.conf statement, 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. Both elements must end in "."


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 <serial-number> directive is a numerical value incremented every time the zone file is changed. This indicates 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 slave servers use <serial-number> to determine if they are 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 <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.
Line 290: Line 342:
The <minimum-TTL> directive is the amount of time other nameservers cache the zone's information.
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.
All times are specified in seconds, unless M (minutes), H (hours), D (days) or W (weeks) are specified.
 
====NS====
 
Is the NameServer record, which announces the authoritative nameservers for this zone.
 
<pre>
      IN    NS    <nameserver-name-1>.
      IN    NS    <nameserver-name-2>.
</pre>
 
<nameserver-name> should be an FQDN.


===Example===
====A====
 
Defines an Address record, which specifies an IP address to assign to a name.
 
<pre>
<host> IN A <IP-address>
</pre>
 
If the <host> value is omitted, then an A record points to a default IP address for the top of the namespace. This system is the target for all non-FQDN requests.
 
====CNAME====
 
Defines a Canonical Name record, which maps one name to another. This type of record can also be referred to as an alias record.
 
<pre>
<alias-name> IN CNAME <real-name>
</pre>
 
Example:
 
<pre>
server1 IN A 10.0.1.5
www IN CNAME server1
</pre>
 
====MX====


Start with <tt>named.localhost</tt> as a model.
This refers to the Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.


<pre>
<pre>
cd /var/named
  IN MX <preference-value> <email-server-name>
cp named.localhost openshift.local.zone
</pre>
</pre>


Make sure the file has the same ownership as the rest of the files in the directory:
====PTR====
 
This refers to a pointer record, which is designed to point to another part of the namespace. It is primarily used for [[#PTR_.28Inverse_Record.29_File|reverse name resolution]], pointing IP addresses back to a particular name.
 
===Example===
 
Make sure the file has the same ownership and permissions as the rest of the files in the directory:


<pre>
<pre>
Line 309: Line 402:
{{Warn|Assigning the ownership is critical. The file won't be read and names from the file will not be resolved otherwise.}}
{{Warn|Assigning the ownership is critical. The file won't be read and names from the file will not be resolved otherwise.}}


<tt>/var/named/openshift.local.zone</tt>:
<tt>/var/named/openshift.local.zone</tt> example:


<pre>
<pre>
$TTL 3600
$TTL 3600
@                      IN SOA  openshift.local. root (
@                      IN SOA  ns.openshift.local. root. (
                                         2015092101      ; serial
                                         2015092101      ; serial
                                         3600            ; refresh
                                         3600            ; refresh
Line 319: Line 412:
                                         1W              ; expire
                                         1W              ; expire
                                         1D )            ; minimum
                                         1D )            ; minimum
                         IN NS  localhost
 
localhost              IN A    127.0.0.1
                         IN NS  ns.openshift.local.
 
ns                      IN A    172.20.2.10
ns                      IN A    172.20.2.10
openshift-master1      IN A    172.20.2.1
openshift-master1      IN A    172.20.2.1
openshift-node1        IN A    172.20.2.2
openshift-node1        IN A    172.20.2.2
openshift-node2        IN A    172.20.2.3
openshift-node2        IN A    172.20.2.3
nfs                    IN CNAME ns
ansible                IN CNAME ns
</pre>
</pre>
===Zone File Syntax===


==PTR (Inverse Record) File==
==PTR (Inverse Record) File==


<font color=red>TODO: not tested.</font>
A reverse name resolution zone file is used to translate an IP address in a particular namespace into an FQDN. It looks very similar to a standard zone file, except that [[#PTR|PTR]] resource records are used to link the IP addresses to a fully qualified domain name.


<tt>/var/named/openshift.local.rzone</tt>:
===Example===
 
<pre>
$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.
</pre>


Make sure the file has the same ownership as the rest of the files in the directory:
Make sure the file has the same ownership as the rest of the files in the directory:
Line 356: Line 440:
{{Warn|Assigning the ownership is critical. The file won't be read and names from the file will not be resolved otherwise.}}
{{Warn|Assigning the ownership is critical. The file won't be read and names from the file will not be resolved otherwise.}}


<font color=red>
<pre>
$TTL 3600
@                      IN SOA  ns.openshift.local. root. (
                                        2015092101      ; serial
                                        3600            ; refresh
                                        15M            ; retry
                                        1W              ; expire
                                        1D )            ; minimum
 
                        IN NS  ns.openshift.local.


I think the reverse resolution is not fully enabled until I add something like the following in /etc/named.conf:</font>
1                IN PTR openshift-master1.openshift.local.
2                IN PTR  openshift-node1.openshift.local.
3                IN PTR  openshift-node2.openshift.local.


<pre>
10              IN PTR ns.openshift.local.
zone"0.168.192.in-addr.arpa" IN {
type master;
file "reverse.linuxzadmin";
allow-update { none; };
};
</pre>
</pre>


=Verify Configuration Files=
=Verify Configuration Files=


<pre>
named-checkconf /etc/named.conf  
named-checkconf /etc/named.conf  


named-checkzone  <zone-name> <zone-file>
named-checkzone  <zone-name> <zone-file>
named-checkzone  openshift.local.zone /var/named/openshift.local.zone  
named-checkzone  openshift.local /var/named/openshift.local.zone  
</pre>
named-checkzone 122.168.192.in-addr.arpa  /var/named/ocp36.local.rzone


=Configure iptables=
=Configure iptables=


Add the following rules to your iptables configuration:
Add the following rules to your iptables configuration <tt>/etc/sysconfig/iptables</tt>:


<pre>
...
...
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
...
...
</pre>
 
systemctl restart iptables
systemctl status iptables


For more details on the iptables configuration, see {{Internal|Iptables_Command_Line_Tool_Examples#Base_Configuration|iptables IPv4 Base Configuration}}
For more details on the iptables configuration, see {{Internal|Iptables_Command_Line_Tool_Examples#Base_Configuration|iptables IPv4 Base Configuration}}
Line 394: Line 485:
Also see {{Internal|Iptables_Troubleshooting#ping_and_ssh_succeed_but_telnet_fails|ping and ssh succeed but telnet fails}}
Also see {{Internal|Iptables_Troubleshooting#ping_and_ssh_succeed_but_telnet_fails|ping and ssh succeed but telnet fails}}


=Declared a Wildcard DNS Domain=
=Declare a Wildcard DNS Domain=


A [[DNS_Concepts#Wildcard_Sub-Domain|wildcard DNS sub-domain]] is a domain that resolves all the host and subdomains under it to the same IP address.  
A [[DNS_Concepts#Wildcard_Sub-Domain|wildcard DNS sub-domain]] is a domain that resolves all the host and subdomains under it to the same IP address.  
Line 404: Line 495:
<pre>
<pre>
$TTL 3600
$TTL 3600
@   IN SOA apps.openshift35.external. root (
@   IN SOA ns.openshift35.external. root. (
2017052401 ; serial
2017052401 ; serial
3600 ; refresh
3600 ; refresh
Line 410: Line 501:
1W ; expire
1W ; expire
1D ) ; minimum
1D ) ; minimum
  IN NS localhost
  IN    A  172.23.0.12


localhost IN A  127.0.0.1
  IN NS ns.openshift35.external.


*   IN A  172.23.0.12
  IN  A  172.23.0.12
*   IN   A  172.23.0.12
</pre>
</pre>


Line 472: Line 562:
==Local Tests==
==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:
Configure the local resolver to the name server that has just been configured.
 
<pre>
# nslookup ns
Server: 172.20.2.10
Address: 172.20.2.10#53


Name: ns.openshift.local
For each of the names in your zone file:
Address: 172.20.2.10
</pre>


<pre>
<pre>
# nslookup ns.openshift.local
nslookup <name>
Server: 172.20.2.10
nslookup <name>.<domain>
Address: 172.20.2.10#53
 
Name: ns.openshift.local
Address: 172.20.2.10
</pre>
 
<pre>
# nslookup openshift-master1
Server: 172.20.2.10
Address: 172.20.2.10#53
 
Name: openshift-master1.openshift.local
Address: 172.20.2.1
</pre>
 
<pre>
# 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
</pre>
</pre>


Line 513: Line 574:


<pre>
<pre>
# nslookup www.cnn.com
nslookup www.google.com
Server: 172.20.2.10
Server: 172.20.2.10
Address: 172.20.2.10#53
Address: 172.20.2.10#53


Non-authoritative answer:
Non-authoritative answer:
www.cnn.com canonical name = turner.map.fastly.net.
Name: www.google.com
Name: turner.map.fastly.net
Address: 172.217.5.100
Address: 23.235.47.73
</pre>
</pre>


Line 576: Line 636:
===Network Unreachable===
===Network Unreachable===


<pre>
error (network unreachable) resolving 'www.cnn.com/A/IN': 2001:7fe::53#53
error (network unreachable) resolving 'www.cnn.com/A/IN': 2001:7fe::53#53
</pre>


Got this on a network that prevented UDP DNS traffic. The server resumed working find immediately after I connected to a different network.
Got this on a network that prevented UDP DNS traffic. The server resumed working find immediately after I connected to a different network.
===Broken Trust Chain===
Got these in the server log trying to resolve external names:
validating @0x7f347c10b3c0: www.cnn.com A: bad cache hit (www.cnn.com.dlv.isc.org/DLV)
error (broken trust chain) resolving 'www.cnn.com/A/IN': 8.8.8.8#53
Worked around by commenting "dnssec-lookaside auto". See [[#Domain_Name_System_Security_Extensions_.28DNSSEC.29_Configuration|Domain Name System Security Extensions (DNSSEC) Configuration]].

Latest revision as of 05:24, 9 November 2017

External

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.

Configuring Specific Forwarders

If recursion is enabled and the name to be resolved is not in the zone, the DNS server process forwards the request to other DNS servers. By default, it makes the request over UDP on port 53, to root name servers. However, these connections are blocked by some networks, so an alternative is to configure a small set of "forwarders" - like Google's name servers - to query. This is done in the "options" block as follows:

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

    forward only;
    ...
}

To configure this server to forward all non-local request and not attempt to resolve requests over the normal protocol, on its own, set the "forward" directive to "only".

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";
    ...
}

Note that uncommenting "dnssec-lookaside auto" leads to "broken trust chain" error.

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";
};

zone "172.20.2.in-addr.arpa" IN {
        type master;
        file "openshift.local.rzone";
        allow-update { none; };
};

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.

A zone has usually an associated reverse zone, which is declared as follows:

zone "<first-three-blocks-of-the-ip-address-reversed>.in-addr.arpa" <zone-class> {
        type master;
        file "<file-name>";
        allow-update { node; };
};

The reverse name resolution zone requires the first three blocks of the IP address reversed followed by ".in-addr.arpa".

Zone File

https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-bind-zone.html

Zone files contain information about a domain. The zone files are stored in /var/named. Each zone file is named according to the "zone"/"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 (;).

Zone File Directives

$ORIGIN

Appends the domain name to unqualified records in the zone file, such as those with the hostname and nothing more. For example, a zone file may contain the following line:

$ORIGIN example.com.

Any names used in resource records that do not end in a trailing period (.) are appended with example.com.

The use of the $ORIGIN directive is unnecessary if the zone is specified in /etc/named.conf because the zone name declared in /etc/named.conf is used as the value for the $ORIGIN directive by default.

$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.

Zone File 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 zone name, as defined in the "zone" named.conf statement, 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. Both elements must end in "."

The <serial-number> directive is a numerical value incremented every time the zone file is changed. This indicates 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 slave servers use <serial-number> to determine if they are 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.

All times are specified in seconds, unless M (minutes), H (hours), D (days) or W (weeks) are specified.

NS

Is the NameServer record, which announces the authoritative nameservers for this zone.

      IN     NS     <nameserver-name-1>.
      IN     NS     <nameserver-name-2>.

<nameserver-name> should be an FQDN.

A

Defines an Address record, which specifies an IP address to assign to a name.

<host>	IN	A	<IP-address>

If the <host> value is omitted, then an A record points to a default IP address for the top of the namespace. This system is the target for all non-FQDN requests.

CNAME

Defines a Canonical Name record, which maps one name to another. This type of record can also be referred to as an alias record.

<alias-name>	IN	CNAME	<real-name>

Example:

server1	IN	A	10.0.1.5 
www	IN	CNAME	server1

MX

This refers to the Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go.

   IN	MX	<preference-value>	<email-server-name>

PTR

This refers to a pointer record, which is designed to point to another part of the namespace. It is primarily used for reverse name resolution, pointing IP addresses back to a particular name.

Example

Make sure the file has the same ownership and permissions 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 example:

$TTL 3600
@                       IN SOA  ns.openshift.local. root. (
                                        2015092101      ; serial
                                        3600            ; refresh
                                        15M             ; retry
                                        1W              ; expire
                                        1D )            ; minimum

                        IN NS   ns.openshift.local.

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

nfs                     IN CNAME ns
ansible                 IN CNAME ns

PTR (Inverse Record) File

A reverse name resolution zone file is used to translate an IP address in a particular namespace into an FQDN. It looks very similar to a standard zone file, except that PTR resource records are used to link the IP addresses to a fully qualified domain name.

Example

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.

$TTL 3600
@                       IN SOA  ns.openshift.local. root. (
                                        2015092101      ; serial
                                        3600            ; refresh
                                        15M             ; retry
                                        1W              ; expire
                                        1D )            ; minimum

                        IN NS   ns.openshift.local.

1                IN PTR openshift-master1.openshift.local.
2                IN PTR  openshift-node1.openshift.local.
3                IN PTR  openshift-node2.openshift.local.

10              IN PTR ns.openshift.local.

Verify Configuration Files

named-checkconf /etc/named.conf 
named-checkzone  <zone-name> <zone-file>
named-checkzone  openshift.local /var/named/openshift.local.zone 
named-checkzone 122.168.192.in-addr.arpa  /var/named/ocp36.local.rzone

Configure iptables

Add the following rules to your iptables configuration /etc/sysconfig/iptables:

...
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
...
systemctl restart iptables
systemctl status iptables

For more details on the iptables configuration, see

iptables IPv4 Base Configuration

Make sure the correct rules are in place with iptables -F:

Also see

ping and ssh succeed but telnet fails

Declare 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

Domains and Sub-domains

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	ns.openshift35.external. root. (
					2017052401	; serial
					3600		; refresh
					15M		; retry
					1W		; expire
					1D )		; minimum

	  IN 	NS ns.openshift35.external.

	  IN   A  172.23.0.12
*	  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:

Set Up DNS Client

Configure DNS Resolver on Other Hosts

Set Up DNS Client

Reboot and Test

Local Tests

Configure the local resolver to the name server that has just been configured.

For each of the names in your zone file:

nslookup <name>
nslookup <name>.<domain>

Also a random (but valid) name must be resolved

nslookup www.google.com
Server:		172.20.2.10
Address:	172.20.2.10#53

Non-authoritative answer:
Name:	www.google.com
Address: 172.217.5.100

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.

Broken Trust Chain

Got these in the server log trying to resolve external names:

validating @0x7f347c10b3c0: www.cnn.com A: bad cache hit (www.cnn.com.dlv.isc.org/DLV)
error (broken trust chain) resolving 'www.cnn.com/A/IN': 8.8.8.8#53

Worked around by commenting "dnssec-lookaside auto". See Domain Name System Security Extensions (DNSSEC) Configuration.