Chapter 13. Security

13.1 DNS Security Overview

13.1 Security Overview

DNS Security is a huge and complex topic. It is made worse by the fact that almost all the documentation dives right in and you fail to see the forest for all the d@!mned trees.

The critical point is to first understand what you want to secure - or rather what threat level you want to secure against. This will be very different if you run a root server vs running a modest in-house DNS serving a couple of low volume web sites.

The term DNSSEC is thrown around as a blanket term in a lot of documentation. This greatly over simplifies the range of security solutions that are available. There are at least three types of DNS security, two of which are - relatively - painless and what is increasing just called DNSSEC which is - relatively - painful.

Security is always an injudicious blend of real threat and paranoia - but remember just because you are naturally paranoid does not mean that they are not after you!

13.1.1 Security Threats

In order to be able to assess the potential threats and the possible counter-measures it is first and foremost necessary to understand the normal data flows in a DNS system. Diagram 1-3 below shows this flow.

Diagram 1-3 DNS Data Flow

Every data flow (each RED line above) is a potential source of threat!. Using the numbers from the above diagram here is what can happen at each flow:

Number	Area	Threat
(1)	Zone Files	File Corruption (malicious or accidental). Reading private zone files, configuration files and logs to expose hidden devices. Local threat. Mitigated by good System Administration practices.
(2)	Zone Transfers	IP address spoofing (impersonating update source), DDoS attacks (persistent requests for transfer). Server to Server threat. Mitigated by either IP address limits or cryptographic solutions using TSIG (shared secret MAC).
(3)	Dynamic Updates	Unauthorized Updates, malicious updates, IP address spoofing (impersonating update source). Server to Server Threat. Mitigated by either IP address limits or cryptographic solutions using either TSIG (symmetric-like MAC)or SIG(0) (an asymmetric).
(4)	Remote Queries	Cache Poisoning/Pollution by IP spoofing, data interception or a subverted Master or Slave. DDoS attacks based on Open Resolvers and other configuration errors. Zombied or virus compromised PC or server. Server to Client threat. Mitigated by either IP address limits or cryptographic solutions using DNSSEC (asymmetric cryptography).
(5)	Resolver Queries	Data interception, Poisoned/Polluted Cache, subverted Master or Slave, local IP spoofing. Increasingly remote devices use a DNS proxy which can either be compromised, badly configured or poorly implemented. Remote Client-Client threat. Mitigated by end-to-end cryptographic solutions using DNSSEC (asymmetric cryptography).

The first phase of getting a handle on the problem is to figure (audit) what threats are applicable and how seriously they are rated, or determining if they even apply. As an example: if Dynamic Updates are not permitted (BIND's default mode) - there is no Dynamic Update threat. Finally, in this section a warning: the further you go from the Master the more complicated the solution and implementation. Unless there is a very good reason for not doing so, it is always recommend that you start from the Master and work out. It would be a little disappointing, after implementing a complex DNSSEC solution, to discover that zone files are all world-readable or that zone transfers are accepted from any source.

13.1.2 Security Types

We classify each threat type below. This classification simply allows us select appropriate remedies and strategies for avoiding or securing our system. The numbering used below relates to diagram 1-3.

(1) The primary source of Zone data is normally the Zone Files (and don't forget the named.conf file and even logs which can contain lots of interesting data as well). This data should be secure and securely backed up. This threat is classified as Local and is typically handled by good system administration practices (minimal permissions, appropriate access control).

(2) If you run slave servers you will do zone transfers. Note: You do not have to run with slave servers, you can run with multiple masters and eliminate the transfer threat entirely. This is classified as a Server-Server (Transaction) threat and there are multiple configuration techniques available from simple IP based ACLs to TSIG based cryptographic solutions.

(3) The BIND default is to deny Dynamic Zone Updates. If this service is enabled or is required, it poses a serious threat to the integrity of your Zone files and should be protected. There is a significant difference in complexity when moving from allowing on-server (localhost only) Dynamic Updates to provisioning of remote access. This is classified as a Server-Server (Transaction) threat and there are multiple configuration techniques available from simple IP based ACLs to TSIG or SIG (0) based cryptographic solutions.

(4) The possibility of Remote Cache Poisoning due to IP spoofing, data interception and other hacks is a judgement call. If running a simple, non-controversial, non-revenue earning web site the threat is probably verging on the non-existent and the effect, in the unlikely event it does happen, is merely annoying. If the site is high profile, open to competitive threat or is a high revenue earner the threat is both significant and the effects potentially ranging from embarassment to loss of earnings or repution. This is classified as a Server-Client threat and there are complex configuration techniques available using DNSSEC based cryptographic solutions.

(5) The current standards do allow for end-to-end DNSSEC implementation. As of 2013 this was at best in the embryonic phase and would involve major upgrades to all PC/Server based stub resolvers. This is classified as a Server-Client and Client-Client threat.

13.1.3 Security - Local

Normal system administration practices such as ensuring that files (configuration and zone files) are securely backed-up, proper read and write permissions applied and sensible physical access control to servers may be sufficient.

Implementing a Stealth (or Split) DNS server provides a more serious solution depending on available resources.

Finally, you can run BIND (named) in a chroot jail.

13.1.4 Server-Server (TSIG Transactions)

Zone transfers. If you have slave servers you will do zone transfers. BIND provides Access Control Lists (ACLs) which allow simple IP address protection. While IP based ACLs are relatively easy to subvert they are a significantly better than doing nothing and require very little work. It is possible to run with multiple masters (no slaves) and eliminate the threat entirely. Zone files will require manual synchronization but this may be a simpler solution if changes are not frequent.

Dynamic Updates. If you must run with this service it should be secured. BIND provides Access Control Lists (ACLs) which allow simple IP address protection but this is probably not adequate unless you can secure the IP addresses, for example, all systems are behind a firewall/DMZ/NAT or the updating host is using a private IP address.

TSIG/TKEY If all other solutions fail DNS specifications (RFCs 2845 - TSIG and RFC 2930 - TKEY) provide authentication protocol enhancements to secure these Server-Server transactions.

TSIG and TKEY implementations are messy but not too complicated - simply because of the scope of the problem. With Server-Server transactions there is a finite and normally small number of hosts involved. The protocols depend on a shared secret between the master and the slave(s) or updater(s). It is further assumed that you can get the shared secret securely to the peer server by some means not covered in the protocol itself. This process, known as key exchange, may not be trivial (typically long random strings of base64 characters are involved) but you can use the telephone(!), mail, fax or PGP email amongst other methods.

The shared-secret is open to brute-force attacks so frequent changing of shared secrets may become a fact of life. Sample configurations for securing Dynamic Updates when using DHCP to update either or both of the forward and reverse zone files are provided.

13.1.5 Server-Client (DNSSEC)

The classic Remote Poisoned cache problem is not trivial to solve simply because there may an infinitely large number of Remote Caches involved. It is not reasonable to assume that it can use a shared secret. Instead the mechanism relies on public/private key (asymmetric) cryptography. The DNSSEC specifications (RFC 4033, RFC 4034 and RFC 4035) attempt to answer three questions:

Authentication - the DNS responding really is the DNS that the request was sent to.
Integrity - the response is complete and nothing is missing.
Integrity - If a DNS record is not available it can be verified (Proof-of-non-existence - PNE).

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.