Domain Name System security

	Main Article	Discussion	Related Articles  [?]	Bibliography  [?]	External Links  [?]	Citable Version  [?]
	This editable Main Article is under development and subject to a disclaimer. [edit intro]

This is a draft for which collaboration would be very, very appreciated. See talk page for some of the problem areas

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 is becoming more, not less, critical as it becomes involved in more functions than the name-to-address mapping for which it was designed. Internet Protocol version 6 address management demands dynamic DNS update even more than did IPv4 dynamic addressing, but DNS security features are needed to secure the updates. With convergence of communications involving telephone number mapping to Internet names and numbers (e.g., IETF ENUM), DNS is critical in other areas. Another aspect of Internet Protocol version 6 deployment may be increased use of IPsec, which, in turn, needs a secure DNS as a trusted repository for public keys and certificate revocations.

DNS software and operations should follow the overall DNS security architecture (DNSSEC).^[1] Image:Security scope.png|thumb|left|DNS security scope

Threats to DNS[edit]

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.

In the figure "Conceptual points of vulnerability", you will 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. Image:Points of DNS Vulnerability.png|thumb|Conceptual points of vulnerability in DNS Another threat model starts with some basic assumptions.^[3]

An IETF working group on DNS Security started in 1993. It produced the broad outlines from which DNSSEC would emerge, DNSSEC being a combination of threat analysis and countermeasures to those threats. First, some basic assumptions were made.

• "DNS data is "public", and ruled all threats of data disclosure explicitly out of scope for DNSSEC.^[4] This does not mean, however, that DNS data inside the namespace of a virtual private network, "inside the firewall", etc., needs to be available to the public Internet. It means that the data must be available, possibly in read-only format alone, throughout that namespace.
• While some participants in the meeting were interested in authentication of DNS clients and servers as a basis for access control, this work was also ruled out of scope for DNSSEC per se.^[5] This does not preclude the additional use of client and server authentication, probably based on some features of IPsec.^[6]
• Backwards compatibility and co-existence with "insecure DNS" was listed as an explicit requirement.
• The resulting list of desired security services was
  • data integrity, and
  • data origin authentication.
• The design team noted that a digital signature mechanism would support the desired services.^[7] While digital signature mechanisms do not require a full Public Key Infrastructure, such mechanisms do require a certain amount of trusted infrastructure.

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)? ^[8]

Threats to the Zone File[edit]

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[edit]

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[edit]

4 covers both stateful and stateless sources of updates. When dynamic updates come only from a Dynamic Host Configuration Protocol(DHCP) 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[edit]

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

Security implementation[edit]

DNSSEC specifically refers to the core digital signature mechanisms used to validate secure DNS records. Three of its RRs, DNSKEY, RRSIG and NSEC work together to establish the authenticity and integrity of DNS data. DS is a supplemental feature by which the signing authority can delegate trust to the public keys of third parties.

TSIG and TKEY are mechanisms that can be used with, or independently of, DNSSEC; they are intended to be used for the specific function of authenticating TSIG here defines a function of transaction authentication; the original TSIG RR mechanism uses secret keys and is more expensive to implement than its descendant, SIG(0), which uses public keys but a smaller set of functionality than

DNSSEC is limited to providing origin authentication (i.e., the record provided is authentic, or, if DNSSEC returns a null response, the record does not exist).

None of these mechanisms secure the request, as opposed to the response. If that is needed, use IPSec authentication. They do not secure the message headers, or the response in its entirety.

Resource Records for TSIG/SIG(0)[edit]

TSIG differs from the new DNSSEC function in being based on symmetric, and presumably preshared, session keys, rather than asymmetric public keys. TKEY sets up the key; SIG(0) authenticates the exchange.

Newest Resource Records for DNSSEC[edit]

DNSSEC requires several new Resource Records,^[9] as well as some changes to the DNS header flag and a "pseudo-RR", which is a workaround to the standard limitation of DNS datagrams to 512 bytes, so longer keys and other cryptographic information can be passed.

An otherwise obsolete RFC makes it clear which old types are replaced or not. ^[10]

Known issues with DNSSEC[edit]

DNS itself is hierarchical, and DNSSEC follows its hierarchy. This means that a problem at one level of zone propagates to the zones hierarchically below it.

DNSSEC implementation will take significant programming skills, and not all error handling is well-defined in the specifications. #Key management issues|Expired keys and slight zone file configuration errors can cause significant problems for a DNSSEC-aware resolver, and the reporting and recover mechanisms may be inadequage.

When DNSSEC is used, it will produce considerably more data than with conventional DNS. It could, therefore, provide even more amplification, so a denial of service attack aimed at DNS servers than with conventional DNS.

A DNSSEC-aware resolver has to do much more processing, both for basic signature validation and for additional queries that may be required. With non-DNSSEC aware resolvers today, there is already a problem with timeouts and unneeded queries. This was deemed more of a general DNS operations problem than a DNSSEC-specific problem.

Authenticated denial becomes considerably more complex due to the existence of DNS wildcards. ^[11] While not supporting wildcards in DNSSEC was considered, the IETF consensus was that wildcards are operationally necessary. Authenticated denial, therefore, may be fragile.

Time synchronization issues[edit]

Before DNSSEC, DNS could operate using "relative" or "elapsed" time. Since DNSSEC signature validity is based on "absolute" time, DNSSEC requires at least loose time synchronization between the resolver and the signing entity. Without it, the resolver may accept expired signatures. If the signer does not have a trusted time reference, a miscreant that can feed inaccurate time to the signer can cause it to sign things valid for a period different than it intended to have valid.

Key management issues[edit]

Key rollover at the root remains unsolved. There is no agreement even how to configure it.

Mandates[edit]

The U.S. government is requiring DNSSEC for all Federal information systems by December 2009.^[12] The requirement, however, is essentially limited to signing the agency roots.

Implementation guidance[edit]

The European address registry, RIPE, has been presenting excellent training on DNSSEC.^[8]

References[edit]