DNS Data Flow Diagram
| Number | Area | Threat |
| (1) | Zone Files | File Corruption (malicious or accidental). Local threat. |
| (2) | Dynamic Updates | Unauthorized Updates, IP address spoofing (impersonating update source). Server to Server (TSIG Transaction) threat. |
| (3) | Zone Transfers | IP address spoofing (impersonating update source). Server to Server (TSIG Transaction) threat. |
| (4) | Remote Queries | Cache Poisoning by IP spoofing, data interception, or a subverted Master or Slave. Server to Client (DNSSEC) threat. |
| (5) | Resolver Queries | Data interception, Poisoned Cache, subverted Master or Slave, local IP spoofing. Remote Client-client (DNSSEC) threat. |
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 the diagram.
(1) The primary source of Zone data is normally the Zone Files (and don't forget the named.conf file which contains 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.
(2) The BIND default is to deny Dynamic Zone Updates. If you have enabled this service or require to it poses a serious threat to the integrity of your Zone files and should be protected. This is classified as a Server-Server (Transaction) threat.
(3) 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.
(4) The possibility of Remote Cache Poisoning due to IP spoofing, data interception and other hacks is a judgement call if you are running a simple web site. If the site is high profile, open to competitive threat or is a high revenue earner you have probably implemented solutions already. This is classified as a Server-Client threat.
(5) The current DNSSEC standards define a security aware resolver and this concept is under active development by an number of groups round the world. This is classified as a Server-Client threat.
Local Security
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.
Server-Server Security (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 using IP addreess spoofing they are a lot better than nothing and require very little work. You can run with multiple masters (no slaves) and eliminate the threat entirely. You will have to manually synchronise zone file updates 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, that is, all systems are behind a firewall/DMZ/NAT or the updating hosts are using private IP addresses.
TSIG/TKEY If all other solutions fail DNS specifications (RFC 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 among other methods.
The shared-secret is open to brute-force attacks so frequent (monthly or more) changing of shared secrets will become a fact of life. TKEY allows automation of key-exchange using a Diffie-Hellman algorithm but starts with a shared secret! TKEY appears to have very limited, if any, usage.
Server-Client Security (DNSSEC)
The classic Remote Poisoned cache problem is not trivial to solve simply because there may be an infinitely large number of Remote Caches involved. It is not reasonable to assume that you can use a shared secret.
Instead DNSSEC relies on public/private key authentication. The DNSSEC specifications (RFC 4033, RFC 4034 and RFC 4035 augmented with others) 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 or changed.
- Proof of non-existance - if the DNS returns a status that the name does not exist (NXDOMAIN) this response can be proven to have come from the authoritative server.
