Protect DNS Data from Tampering or Attack

This section discusses DNS configuration options which make it more difficult for attackers to gain access to private DNS data or to modify DNS data.

3.14.4.1 Run Separate DNS Servers for External and Internal Queries if Possible

Is it possible to run external and internal nameservers on separate machines? If so, follow the configuration guidance in this section. If not, see Section3.14.4.2for an alternate approach using BIND9.

On the external nameserver, edit /etc/named.conf. Add or correct the following directives:

options {

allow-query { any; };

recursion no;

...

};

zone "example.com " IN { ...

};

On the internal nameserver, edit /etc/named.conf. Add or correct the following directives, where SUBNET is the numerical IP representation of your organization in the form xxx.xxx.xxx.xxx/xx:

acl internal { SUBNET ; localhost;

};

options {

allow-query { internal; };

...

};

zone "internal.example.com " IN { ...

};

Enterprise nameservers generally serve two functions. One is to provide public information about the machines in a domain for the benefit of outside users who wish to contact those machines, for instance in order to send mail to users in the enterprise, or to visit the enterprise’s external web page. The other is to provide nameservice to client machines within the enterprise. Client machines require both private information about enterprise machines (which may be different from the public information served to the rest of the world) and public information about machines outside the enterprise, which is used to send mail or visit websites outside of the organization.

In order to provide the public nameservice function, it is necessary to share data with untrusted machines which request it — otherwise, the enterprise cannot be conveniently contacted by outside users. However, internal data should be protected from disclosure, and serving irrelevant public name queries for outside domains leaves the DNS server open to cache poisoning and other attacks. Therefore, local network nameservice functions should not be provided to untrusted machines.

Separate machines should be used to fill these two functions whenever possible.

3.14.4.2 Use Views to Partition External and Internal Information if Necessary

If it is not possible to run external and internal nameservers on separate physical machines, run BIND9 and simulate this feature using views.

Edit /etc/named.conf. Add or correct the following directives (where SUBNET is the numerical IP represen-tation of your organization in the form xxx.xxx.xxx.xxx/xx):

acl internal { SUBNET ; localhost;

};

view "internal-view" {

match-clients { internal; };

zone "." IN { type hint;

file "db.cache";

};

zone "internal.example.com " IN { ...

};

};

view "external-view" { match-clients { any; };

recursion no;

zone "example.com " IN { ...

};

};

The view feature is provided by BIND9 as a way to allow a single nameserver to make different sets of data available to different sets of clients. If possible, it is always better to run external and internal nameservers on separate machines, so that even complete compromise of the external server cannot be used to obtain internal data or confuse internal DNS clients. However, this is not always feasible, and use of a feature like views is preferable to leaving internal DNS data entirely unprotected.

Note: As shown in the example, database files which are required for recursion, such as the root hints file, must be available to any clients which are allowed to make recursive queries. Under typical circumstances, this includes only the internal clients which are allowed to use this server as a general-purpose nameserver.

3.14.4.3 Disable Zone Transfers from the Nameserver if Possible

Is it necessary for a secondary nameserver to receive zone data via zone transfer from the primary server?

If not, follow the instructions in this section. If so, see the next section for instructions on protecting zone transfers.

Edit /etc/named.conf. Add or correct the following directive:

options {

allow-transfer { none; };

...

}

If both the primary and secondary nameserver are under your control, or if you have only one nameserver, it may be possible to use an external configuration management mechanism to distribute zone updates. In that case, it is not necessary to allow zone transfers within BIND itself, so they should be disabled to avoid the potential for abuse.

3.14.4.4 Authenticate Zone Transfers if Necessary

If it is necessary for a secondary nameserver to receive zone data via zone transfer from the primary server, follow the instructions here.

Use dnssec-keygen to create a symmetric key file in the current directory:

# cd /tmp

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST dns.example.com Kdns.example.com .+aaa +iiiii

This output is the name of a file containing the new key. Read the file to find the base64-encoded key string:

# cat Kdns.example.com .+NNN +MMMMM .key

dns.example.com IN KEY 512 3 157 base64-key-string Edit /etc/named.conf on the primary nameserver. Add the directives:

key zone-transfer-key {

Edit /etc/named.conf on the secondary nameserver. Add the directives:

key zone-transfer-key {

The BIND transaction signature (TSIG) functionality allows primary and secondary nameservers to use a shared secret to verify authorization to perform zone transfers. This method is more secure than using IP-based limiting to restrict nameserver access, since IP addresses can be easily spoofed.

However, if you cannot configure TSIG between your servers because, for instance, the secondary nameserver is not under your control and its administrators are unwilling to configure TSIG, you can configure an allow-transfer directive with numerical IP addresses or ACLs as a last resort.

Note: The purpose of the dnssec-keygen command is to create the shared secret string base64-key-string . Once this secret has been obtained and inserted into named.conf on the primary and secondary servers, the key

files Kdns.example.com .+NNN +MMMMM .key and Kdns.example.com .+NNN +MMMMM .private are no longer needed, and may safely be deleted.

3.14.4.5 Disable Dynamic Updates if Possible

Is there a mission-critical reason to enable the risky dynamic update functionality? If not:

Edit /etc/named.conf. For each zone specification, correct the following directive if necessary:

zone "example.com " IN { allow-update { none; };

...

}

CCE 4399-2

Dynamic updates allow remote servers to add, delete, or modify any entries in your zone file. Therefore, they should be considered highly risky, and disabled unless there is a very good reason for their use.

If dynamic updates must be allowed, IP-based ACLs are insufficient protection, since they are easily spoofed.

Instead, use TSIG keys (see the previous section for an example), and consider using the update-policy directive to restrict changes to only the precise type of change needed.