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

 this note uses the term "DNSSEC" to refer
  to the core hierarchical public key and signature mechanism specified
  in the DNSSEC documents, and refers to TKEY and TSIG as separate
  mechanisms

DNSSEC proper

DNSKEY/RRSIG/NSEC: provides mechanisms to establish authenticity and integrity of data
DS: provides a mechanism to delegate trust to public keys of third parties

Known issues with DNSSEC

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 is complex to implement and includes some special cases that can be handled only by very

skilled programmers. 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.

DNSSEC significantly enlarges the amount of data produced in a DNS response, so a denial of service attack aimed at DNSSEC-aware DNS servers will cause even more amplification 

than would result from existing 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.

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

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.

  - The possible existence of wildcard RRs in a zone complicates the
    authenticated denial mechanism considerably.  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.

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.