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 is not correct. There are at least three types of DNS security, two of which are - relatively - painless and 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!
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 (beware you may not sleep tonight):
|(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.|
The first phase of getting a handle on the problem is to figure (audit) what threats are applicable and how seriously do YOU rate them or do they even apply. As an example; if you don't do Dynamic Updates (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, we would always recommend that you start from the Master and work out.
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 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) 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.
(3) 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.
(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) We understand that certain groups are already looking at the implications for secure Resolvers but as of early 2004 this was not standardised. This is classified as a Server-Client threat.
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.
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 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 i.e. both 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 (monthly or more) changing of shared secrets will become a fact of life. What works once may not work monthly or weekly. TKEY allows automation of key-exchange using a Diffie-Hellman algorithm but seems to start with a shared secret!
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 you can use a shared secret. Instead the mechanism relies on public/private key authentication. The DNSSEC specifications (RFC 2535 augmented with others) attempt to answer three questions:
3 reverse map
4 dns types
5 install bind
8 dns records
12 bind api's
13 dns security
bits & bytes
notes & tips