The Delegation_Only DNSKEY flag
Red Hat
pwouters@redhat.com
Huawei
frank.xialiang@huawei.com
USC/ISI
P.O. Box 382
Davis, CA
95617
US
ietf@hardakers.net
Security
DNSOP
DNSOP
DNSSEC
Binding DNSSEC keys to delegation-only
This document introduces a new DNSKEY flag called DELEGATION_ONLY that
indicates that the particular zone will never sign zone data across a label.
That is, every dot is considered a zone cut and must have its own (signed)
delegation.
The DNS Security Extensions [DNSSEC] use public key cryptography to
create an hierarchical trust base with the DNSSEC root public key at
the top, followed by TLD keys one level underneath. While the root
and TLD zones are asumed to be almost exclusively delegation-only
zones, there is currently no method to force these zones to actually
behave as a delegation-only zone. This creates an attractive target
for malicious use of these zones - either by their owners or through
coercion. For example, the DNSSEC root key could remove a delegation
for "example.com" and sign an A record and TLSA record for "example.com",
overriding the authority of "com" and "example.com". If such a change
is done in a targetted attack, such an attack is near impossible to
detect and log in any kind of transparency audit log.
A new DNSKEY flag is introduced to signify a public commitment
by the zone to state that the zone will never sign any DNS data
that traverses a single label and if any such signed data is
encountered by validating resolvers, that this data should be
interpreted as BOGUS. All delegations in the zone will have at
most one added label. Any data found that does not comply to this
commitment MUST be interpreted as BOGUS.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
The hierarchical model of DNSSEC (,
and comes with the property that a zone at one
point in the hierarchy can define, and therefor override, everything in
the DNS tree from their level and below. The DNSSEC root key could ignore
the NS records for ".org" and "example.org" and could place a record
"www.example.org" directly into its own zone, with the corresponding RRSIG
signed by the root key itself. Even if resolvers would defend against this
attack by not allowing RRSIG's to span across a zone cut, the root zone
operator (or any level higher in the hierarchy than the target victim)
could briefly remove the NS and DS records, and create a "legitimate" DNS
entry for "www.example.org" that traverses a label, but has no zonecuts.
The attacker could then publish DNS records such as A/AAAA records, but also
records used for authentication, such as TLSA, SMIME. OPENPGPKEY, SSHP or
IPSECKEY records.
Exposing such targetted attacks requires a transparency audit setup that needs to
log all signed DNS data to prove that data signed by a parental DNSKEY was out of
the ordinary. The very distributed nature of DNS makes such transparency logs
prohibitively expensive and near impossible to operate. Additionally, it would
expose all zone data to any public log operators, thereby exposing all DNS data
to a public archive. This data could then be used for other malicious purposes.
This document introduces a new DNSKEY flag called DELEGATION_ONLY. When
this flag is set on the DNSKEY with SEP bit set (KSK), the zone commits
to not sign any data that crosses a label down in the hierarchy. This
forces the parent in the hierarchy to only sign NS and DS records for
all (non-glue) records regarding its child zones. It will no longer be
able to ignore (or briefly delete, see below) the child delegation and publish
data across the label by pretending the next label is not a zone cut.
For such a parent to take over data that belongs to its child zone, it has
two choices. It can (temporarilly) remove its own DNSKEY DELEGATION_ONLY
flag or it can replace the NS and DS records of its child zone with its
own keys for which it has the private key so it can sign DNS data that
belongs to its child zone. Both of these actions cannot be hidden,
thus exposing such malicious behaviour.
A parent zone, such as the root zone or a TLD, that has commited to the
DELEGATION_ONLY flag can no longer make an exception for a single delegated
zone without switching its entire zone by removing the DELEGATION_ONLY flag.
This action would be highly visible, and for some domains such as the root
or TLDs, require human interaction to notify the stake holders.
Removing the DELEGATION_ONLY flag from a DNSKEY requires that the zone
signals a new DS record to its parent, as changing any DNSKEY flag
changes the DS record data for that corresponds to its DNSKEY.
In the case of the root key, it would require updating out-of-band root
key meta information and/or perform an style
rollover to the same key with updated DNSKEY flags. Due to the timings of
such a rollover, it would take at least 30 days for validating resolvers
to pick 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 targetted attack mode, but these events are something that can be
easilly tracked by a transparency infrastructure similar to what is now
in use for the WebPKI using (bis). With client
implementations of transparency, this would be logged and become visible
to the owner of the child zone and would expose the parent's malicious
action.
Once the root key is marked with a DELEGATION_ONLY flag, and resolver software
and RFC 5011 compliant resolver setups have rolled into such a key, all TLDs
are ensured that the root key can no longer be abused to create "deep link"
data. Until the root key sets this bit, software MAY imply this bit is always
set as this is the current mode of operation of the root zone.
Even before the root key has been marked with DELEGATION_ONLY, TLDs can already
signal their own willingness to commit to formally being DELEGATION_ONLY zones.
Any changes of that state in a TLD DNSKEY would require those TLDs to submit a new DS
record to the root, and could therefor only be done in a transparent and auditible
way - preventing abuse and coercion.
There might be multiple DNSKEYs with the SEP bit set in a zone. For the purpose of
delcaring 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 DNSKEY's with and some of which point to DNSKEY's
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 commiting to a DELEGATION_ONLY zone (or the reverse).
The DELEGATION_ONLY flag has a strong overlap in functionality with the
Public Suffix List as both signal a formal split of authority between parent
and child.
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 bit 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.
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 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.
There are no negative security impacts of using the DELEGATION_ONLY bit?
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 author 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 and Sam Weiler.