The DELEGATION_ONLY DNSKEY flag
Red Hat
pwouters@redhat.com
USC/ISI
P.O. Box 382
Davis, CA
95617
US
ietf@hardakers.net
ops
DNSOP
DNSOP
DNSSEC
Binding DNSSEC keys to delegation-only
This document introduces a new DNSKEY flag called DELEGATION_ONLY that
indicates that this zone will only produce delegation responses
for data outside of its own apex (or _underscore labels). That is, the
Answer Section for queries that do not involve the apex (or _underscore
labels) of the zone is empty, and only glue records in the Authority
Section and Additional Section will be acceptable data in the response
message. Additionally, it indicates that it is not expected that the
parent of this delegation-only zone bypasses or removes the delegation
to this zone. DNSSEC Validating Resolvers can use this flag to mark
any data that violates the DELEGATION_ONLY policy as Bogus.
The DNS Security Extensions [DNSSEC] use public key cryptography to
create an hierarchical trust base with the DNSSEC root public
keys at the top, followed by Top Level domain (TLD) keys one
level underneath. While the root and most TLD zones are assumed to
be exclusively delegation-only zones, there is
currently no interoperable and automatable mechanism
for auditing these zones to ensure they behave
as a delegation-only zone. This creates a target
for malicious use of these zones - either by their owners or
through coercion.
This document defines a mechanism for delegation-only zone owners to create
a DNSKEY that indicates it will only delegate the remainder of
the DNS tree to lower-level zones. This allows for easier
delegation policy verification and logging and auditing of DNS
responses served by their infrastructure.
Specifically, this document introduces a new DNSKEY flag
allowing zone owners to commit to only signing records relating
to delegation. If a DNSSEC validator discovers any
non-delegation zone data signed by a flagged key, this data
can be interpreted as Bogus.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they appear in all
capitals, as shown here.
The hierarchical model of DNS and DNSSEC (, , , and ) comes with the property that a zone at one point
in the hierarchy can define, and therefor override, everything below
it in the DNS tree. And this is possible to achieve on a per-client
basis.
For example, the owner of the DNSSEC root key could generate a
specially crafted zone file that ignores the intended NS records for
".org" and "example.org". It could place an AAAA record for
"www.example.org" directly into the specially crafted root zone, with a
corresponding RRSIG signed by the root DNSKEY itself. Validating
resolvers would find this record perfectly acceptable, as it was
signed by a key within the proper chain of trust (in this case, a
root DNSKEY). This specially crafted zone could then even be served
to specific clients in an effort to subvert a portion of the DNS
ecosystem for a portion of the Internet.
Similarly, the TLD "example" could circumvent
company.example for certain clients. It is important to note that
this can be done without changing the upstream DS record or trust
anchor -- the DNSKEY is (again) already in the trust path and is merely
signing deeper DNS records than the zone owner's clients may have
expected it to sign.
It is important to note that this "feature" has always been
present. Since the creation of the DNS, it has always been possible
to serve different "views" of the same zone name to different clients.
Specifically, it is not a problem created by DNSSEC
-- DNSSEC was not designed to protect against this use case.
Exposing such targeted attacks requires a transparency audit
infrastructure similar to what is deployed for PKIX (). However, a DNSSEC version would need to log significantly
more data, as all signed DNS data signed by a DNSKEY must be recorded in
order to prove that data signed by a parent zone's DNSKEY was out of
expected policy. The very distributed nature of the DNS combined with the
typically frequent zone resigning rate makes such
transparency logs prohibitively expensive and nearly impossible to
operate.
Furthermore, there is no signalling mechanism that lets validating
resolvers know which zones are supposedly delegation-only and what
zones can be logged. Today there are over 1500 TLDs in
the root zone, some of which may be considered delegation-only while
others may not be. At the time of this writing, the list of entries
in the public suffix list contains over 8800 entries as well, with 73
wild-card entries (prefixed with a "*") indicating that all of their
(unknown number of) children are public registration points. In the
absence of an interoperable mechanism (like this draft provides),
it is infeasible that a validating resolver or auditing log could know
which of these zones are delegation-only without individual policy
statements from each of them. [todo: xref psl]
Upon deployment of this specification, the following parties would be
potentially benefit or be affected by:
Authoritative parent: If (and only if) an authoritative parent is
a "delegation only" zone, it could generate a DNSKEY with the
DELEGATION_ONLY flag set, indicating a verifiable promise to the world
that will not sign any records other than delegation records.
Authoritative Child / Delegated Zone: child zones existing
underneath a marked delegation-only zone get the added benefit of
knowing their parent will not (and cannot) sign DNS records within the
child's portion of the DNS tree using the marked DNSKEY.
Validating Resolver: A validating resolver that supports verifying the
DELEGATION_ONLY flag is capable of rejecting or discarding any data
from an authoritative parent that incorrectly signs non-delegation
records too low in the DNS tree. If the validating resolver supports
a (future-defined) DNSSEC transparency audit log as well, it may
submit the appropriate data to a DNSSEC transparency log that
appropriately tracks DNSSEC signatures.
DNSSEC Transparency Log (optional future): a DNSSEC transparency
log would create a non-modifiable trace of log entries submitted to
it, for public verification, similar to .
What it chooses to accept into its log might be only certain zone
data, or any zone with a marked DNSKEY.
Note that without a DNSSEC Log, the DELEGATION_ONLY flag is still
useful per the discussion in the Validating Resolvers role: the
resolver will reject incorrectly signed, non-delegation data.
However, malicious parent zones are still capable of creating two (or
more) DNSKEYs, one with the DELEGATION_ONLY flag and one without.
However, they would also have to publish those DS records as well,
which is detectable by DNSSEC monitoring platforms, regardless of the
existence of a DNSSEC Transparency Log. Any zone with multiple DS
records that link to both a DELEGATION_ONLY marked and an unmarked
DNSKEY would be considered suspicious (or at least in transition).
Circumventing this through obfuscation would require the collusion of
their parent as well.
This document introduces a new DNSKEY flag called DELEGATION_ONLY. When
this flag is set on a DNSKEY that is a trust anchor with a corresponding
DS record at its parent, the zone commits to only produce Authoritative
Answers for the apex (and _underscore label) records. Note that DS
records and its DNSSEC signatures are still allowed as this data is
authoritative at the parent, not the child. This commits a parent in
the DNS hierarchy to only publish signed DS records and unsigned glue
records (NS and A/AAAA) for its child zones. It will no longer be able
to ignore (or briefly delete, see below) a child delegation and publish
authoritative data in its place.
For such a parent to take over data that belongs to its child zone, it has
two choices. It can (temporarily) remove its own DNSKEY DELEGATION_ONLY
flag or it can replace the NS and DS records of its child zone with its
own data (destinations and key references) so it can sign DNS data that
belongs to its own child zone. However, both of these actions cannot be
hidden, thus exposing such malicious behaviour when combined with DNSSEC
Transparency logs.
A zone that publishes a DNSKEY with the DELEGATION_ONLY flag also
signifies that it is not expecting its own parent to skip it, thereby
bypassing its DELEGATION_ONLY flag.
Some protocols, such as the DANE protocol use a number of labels that start with an
underscore (_) prefix to publish information about the zone
itself. For example, the TLSA record for www.example.com is published
at the location _443._tcp.www.example.com. These records are
semantically part of the zone itself and are not delegated child
zones. Any chain of labels that each start with an underscore (_) is not
considered to violate the DELEGATION_ONLY flag limitation of
being DELEGATION_ONLY, as this data is logically part of the zone
itself and is never meant to be interpreted as an independent
delegated child zone.
A parent zone, such as the root zone, a TLD or any public suffix list
delegation point, that has published a key with the DELEGATION_ONLY
flag can no longer make an exception for a single delegated zone without
removing the DELEGATION_ONLY flag, switching off its published policy.
This action would be highly visible, and for some domains such as the
root or TLDs, require human interaction to notify the stake holders to
prevent loss of trust.
Removing the DELEGATION_ONLY flag from a DNSKEY requires that the zone
first publishes an additional updated DS record to its parent.
In the case of the root key, it would require updating out-of-band root
key meta information and/or perform an style
rollover for the same key with updated DNSKEY flags. Due to the timings of
such a rollover, it would take at least 30 days for the first validating resolvers
to pick up this policy change. It would also be a highly visible event.
Replacing the NS and DS records of a child zone can still
be done in a targeted attack mode, but these events
are something that can be easily tracked by a transparency
infrastructure similar to what is now in use for the WebPKI using
(bis). With client implementations of
transparency, all DELEGATION_ONLY flag changes would be logged and
become visible to the owner of attacked child zones, exposing a
parent's malicious behaviour.
Even before a parent DNSKEY (or the root key) has set the
DELEGATION_ONLY flag, zones can already signal their own willingness
to commit to being DELEGATION_ONLY zones. Any changes of that state
in a zone DNSKEY will require those zones to submit a new DS record
to their parent. Setting the DELEGATION_ONLY flag would trigger
DNSSEC Transparency clients to start monitoring for actions by the
zone or its parents that would be bypassing the DELEGATION_ONLY
policy of the zone. Validating resolvers would mark any data in
violation of the DELEGATION_ONLY policy as Bogus.
Once the Root DNSKEY is marked with a DELEGATION_ONLY flag and
deployed resolvers are configured with the new DNSKEY, all TLDs
will be ensured that the Root DNSKEY can no longer be abused to
override child zone data. Until the Root KSK DNSKEY sets this flag,
software SHOULD imply this flag is always set, as this is the current
expectation of the Root Zone.
There might be multiple DNSKEY records that are suitable to act as
a trustanchor for a zone. For the purpose of declaring a zone as DELEGATION_ONLY,
only those DNSKEY's that have a corresponding DS record at the
parent MUST be considered. If multiple DS records appear at the
parent, some of which point to DNSKEYs with and some of which point to DNSKEYs without the
DELEGATION_ONLY flag set, the zone MUST be considered
DELEGATION_ONLY. This situation will occur when a zone is
rolling its DNSKEY key at the same time as it is committing to a
DELEGATION_ONLY zone (or the reverse).
Setting or unsetting the DELEGATION_ONLY flag must be handled like any
other Key Signing Key rollover procedure, with the appropriate wait
times to give resolvers the chance to update their caches.
Some TLDs offer a service where small domains can be hosted in-zone at the
TLD zone itself. In that case, the TLD MUST NOT set the DELEGATION_ONLY
flag. Another solution for such TLDs is to create delegations for these
child zones with the same or different DNSKEY as used in the parent
zone itself.
If a zone is publishing glue records for a number of zones, and the
zone that contains the authoritative records for this glue is deleted,
a resigning of the zone will make this orphaned glue authoritative within
the zone. However, with the DELEGATION_ONLY flag set, this (signed) DNSSEC
data will be considered Bogus as it violations the commitment to only
delegate. This may impact domains that depended on this unsigned glue. Note
that glue handling differs per zone. Some TLDs already remove the glue records
if no authoritative child is left in its zone that matches these glue
records.
For example, if "example.com" and "example.net" use NS records pointing to
"ns.example.net", then if "example.net" is deleted from the ".net" zone,
and the previously unsigned glue of "ns.example.net" is now signed by the
".net" zone, the "example.com" zone will lose its NS records and fail
to resolve.
The use of Empty Non Terminals (ENT) is fine, as long as the ENT's ends in
a proper delegation with NS (and hopefully DS) records.
Some TLDs publish their nameserver (NS) records straight within their
TLD (eg "ns1.example") which makes these names indistinguishable from
real delegations with respect to the DELEGATION_ONLY flag. These NS
entries would have to be moved to their own delegation zone (eg "ns1.nic.example")
which in itself cannot be a DELEGATION_ONLY zone.
Some TLDs have a requirement for certain Fully Qualified Domain Names (FQDN)
within their TLD, such as "whois.example" or "nic.example". These usually
appear as signed data of the TLD and not as a delegated child zone. These
names would have to be converted to delegated zones before enabling the
DELEGATION_ONLY flag.
The bind DNS software has an option called "delegation_only zones"
which is an option that means something completely different. It
refers to ignoring wildcard records in specified zones that are deemed
delegation-only zones.
Some parental attacks cannot be detected when the validating resolver's
cache is empty. Care should be taken by resolvers to not unnecessarily
empty their cache. This is specifically important for roaming clients
that re-connect frequently to different wireless or mobile data networks.
Resolvers should be aware of DELEGATION_ONLY status of a parental domain
and not consume Authoritative or Additional sections with data that is placed
to attempt to bypass the DELEGATION_ONLY restriction. If "example.org" is a
DELEGATION_ONLY zone, and a query for "www.example.org" results in non-authoritative
data for A records for "www.example.org" or "mail.example.org", these records should
be rejected as Bogus, irrespective of whether these were signed by the appropriate
"example.org" DNSSEC key.
This DELEGATION_ONLY mechanism is not designed to completely foil
attacks (since parent's can simply change a child's referral data),
but rather to empower transparency logging mechanisms.
Some of the protection offered by the DELEGATION_ONLY flag is only
available when DNS resolvers report changes in the signing depth of high
level (root or TLD) DNSKEYs to gain DNSSEC Transparency. This reporting
can reveal that a particular node is trying to access a certain DNS
name. Defensive measures to prevent exposing users should be taken when
implementing DNSSEC Transparency. It is expected that DNSSEC Transparency
behaviour will be written up in a separate document.
The DNS protocol's hierarchy limits zones authority to themselves and
their child zones only. While this provides a finer grained trust model
compared to a simple list of trusted entities, such as used in the WebPKI,
it consolidates a lot of power in the top of the DNS hierarchy. With
the increased reliance on DNSSEC for securely identifying resources,
such as DANE records, it becomes very important to audit those entities high up in
the hierarchy to not abuse or be co-erced into abusing control of the independent
child zones. The protocol extension specifically aims at increasing
parental transparency and blocks some parental attacks from those
parents who have publicly claimed to never override their child zone
data.
Parents using the DELEGATION_ONLY flag publication to increase their public trust
are still able to remove child zones from their zone, for example in
cases of legal compliance or to prevent malicious activity happening
in its child zone. But these parents can only do so publicly and
can no longer surreptitiously take control of their own child zones.
This document defines a new DNSKEY flag, the DELEGATION_ONLY flag, whose
value [TBD] has been allocated by IANA from the DNSKEY FLAGS Registry.
The authors wishes to thank Thomas H. Ptacek for his insistence on this matter.
Thanks to the following IETF participants: Viktor Dukhovni, Shumon Huque, Geoff Huston,
Rick Lamb Sam Weiler and Paul Vixie.