Domain Name System security

DNS, as a critical part of the Internet infrastructure, needs to be protected. There have been, and continue to be, serious attacks against it. DNS software and operations should follow the overall DNS security architecture (DNSSEC).

DNS security scope

Threats to DNS

Domain Name System security (DNSSEC) is intended to solve, or mitigate, known security threats to the Domain Name System. The image, "Conceptual points of vulnerability in DNS" identifies some of the places where threats exist, and for which defensive methods exist, or are in active research.

In the figure "Conceptual points of vulnerability", youwill see that the backgrounds are shaded differently for "Server Security Issues" and "Data Protection Issues". These are one of several ways of breaking out the threat.

Conceptual points of vulnerability in DNS

Threats to the Zone File

1a deals with the problem of a miscreant breaking into the trusted machine, inside the organization, on which the zone file is created, and altering it before it is transferred to the master server. 1b considers both modification to a valid zone file being transferred, as well as a hostile server misrepresenting itself to the primary DNS server as a valid source of zone information.

It is understood that especially in small installations, the DNS zone file creation and primary server are on the same physical computer. This is really undesirable, for reasons beyond security: a primary DNS server is a critical resource, and, for greatest reliability, should run only the minimal DNS and support software. While an administrator is creating a zone file, there are any number of valid reasons why that person might want to access a Web or other public resource, such as the request for comment archive or a root server file. Every time that administrator's machine exposes itself to the public Internet, it opens a potential channel to attack the DNS primary server and all that depends on it.

2a and 2b deal with zone file attacks at sites external to the domain.

Masquerade as the Master

3 is related to the 2 threats in that it involves as DNS server-to-server zone transfer, but inside the organization. A type 3 attack may come from an internal miscreant, who might not need to penetrate firewalls and strong authentication required for an outside domain.

Slave servers also are vulnerable to attacks that corrupt their copy of the zone file.

Fake dynamic updates

4 covers both stateful and stateless sources of updates. When dynamic updates come only from a Dynamic Host Configuration Service server, there can be substantial administrative and technical controls on the DHCP server, whether it is DHCP for Internet Protocol version 4 or Internet Protocol version 6. The situation becomes much more complex when IPv6 stateless address autoconfiguration (SLAAC) is deployed, and any host has a legitimate reason to send a dynamic update into DNS.

Cache attacks

At 5, a caching-only server may masquerade as the real server to the client, and poison the resolver's cache.

Some generic problems in securing DNS

DNS data can be spoofed and corrupted between master server and resolver or forwarder The DNS protocol does not allow you to check the validity of DNS data Exploited by bugs in resolver implementation (predictable transaction ID) Polluted caching forwarders can cause harm for quite some time (TTL) Corrupted DNS data might end up in caches and stay there for a long time How does a slave (secondary) knows it is talking to the proper master (primary)?

Mandates

The U.S. government is requiring DNSSEC for all Federal information systems by December 2009.

Implementation guidance

The European address registry, RIPE, has been presenting excellent training on DNSSEC.