Domain Name System security

Template:TOC-right 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).

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", 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.

Conceptual points of vulnerability in DNS

Another threat model starts with some basic assumptions.

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. 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. This does not preclude the additional use of client and server authentication, probably based on some features of IPSec.
• 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. 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)?

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.

Security implementation

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. 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).

New Resource Records for DNSSEC

DNSSEC requires several new Resource Records, 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. For most of the

    decade that DNSSEC has been under development these issues were
    poorly understood.  At various times there have been questions as
    to whether the authenticated denial mechanism is completely
    airtight and whether it would be worthwhile to optimize the
    authenticated denial mechanism for the common case in which
    wildcards are not present in a zone.  However, the main problem is
    just the inherent complexity of the wildcard mechanism itself.
    This complexity probably makes the code for generating and checking
    authenticated denial attestations somewhat fragile, but since the
    alternative of giving up wildcards entirely is not practical due to
    widespread use, we are going to have to live with wildcards. The
    question just becomes one of whether or not the proposed
    optimizations would make DNSSEC's mechanisms more or less fragile.

  - Even with DNSSEC, the class of attacks discussed in section 2.4 is
    not easy to defeat.  In order for DNSSEC to be effective in this
    case, it must be possible to configure the resolver to expect
    certain categories of DNS records to be signed.  This may require
    manual configuration of the resolver, especially during the initial
    DNSSEC rollout period when the resolver cannot reasonably expect
    the root and TLD zones to be signed.

Time synchronization issues

DNSSEC creates a requirement of loose time synchronization between
    the validating resolver and the entity creating the DNSSEC
    signatures.  Prior to DNSSEC, all time-related actions in DNS could
    be performed by a machine that only knew about "elapsed" or
    "relative" time.  Because the validity period of a DNSSEC signature
    is based on "absolute" time, a validating resolver must have the
    same concept of absolute time as the zone signer in order to
    determine whether the signature is within its validity period or
    has expired.  An attacker that can change a resolver's opinion of
    the current absolute time can fool the resolver using expired
    signatures.  An attacker that can change the zone signer's opinion
    of the current absolute time can fool the zone signer into
    generating signatures whose validity period does not match what the
    signer intended.

Key management issues

 - Key rollover at the root is really hard.  Work to date has not even
    come close to adequately specifying how the root key rolls over, or
    even how it's configured in the first place.

TKEY

TSIG/SIG0: provides mechanisms to authenticate communication between servers

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.