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).[1]
Threats to DNS
Domain Name System security (DNSSEC) is intended to solve, or mitigate, known security threats to the Domain Name System. [2] 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.
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.
Mandates
The U.S. government is requiring DNSSEC for all Federal information systems by December 2009.[3]
Implementation guidance
The European address registry, RIPE, has been presenting excellent training on DNSSEC. [4]
References
- ↑ R. Arends, R. Austein, M. Larson, D. Massey, S. Rose (March 2005), DNS Security Introduction and Requirements, RFC4033
- ↑ D. Atkins, R. Austein (August 2004), Threat Analysis of the Domain Name System (DNS), RFC 3833
- ↑ Evans, Karen (August 22, 2008), Securing the Federal Government’s Domain Name System Infrastructure (Submission of Draft Agency Plans Due by September 5, 2008)
- ↑ RIPE NCC Training Course