DNS
Policy Inheritance Options
Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
Abstract
The problem of creating a signature policy that is
automatically inherited by all sub-domains within a domain hierarchy is
considered. Although the immediate application of interest is Domain Keys Identified Internet Mail the same
considerations also apply to SPF/Sender ID and to any DNS based policy
publication mechanism.
1. Requirements
A core requirement of Domain Keys Identified Internet Mail
(DKIIM) is the ability to inform email recipients that they should expect all
email from a particular source to carry a signature. This allows email
infrastructure to automatically cause email messages that do not carry a
signature to be rejected and/or raise exceptions.
Such a policy statement may be expressed for a given domain
in the form of a DNS record. For example we might consider a statement in a
hypothetical policy language that stated ?all email from the domain name
example.com is signed using a key record that is located in the
_keys.example.com hierarchy.
example.com DKIIM signed=all key=_keys.example.com
This approach allows the sending policy for the domain
example.com to be specified but does not provide any information on the signing
policy for sub-domains within the example.com hierarchy. This allows an
attacker to perform a downgrade attack by sending mail that purports to come
from a user account at a sub-domain such as ?admin(_at_)security(_dot_)example(_dot_)com?.
A simple approach to this problem is to allow a policy record
to apply to all sub-domains where no more specific policy is declared and require
an email recipient to search for a matching DNS policy record by iterating the
DNS tree in an upwards or downwards fashion until a match is found. This
approach creates a serious efficiency problem that may allow an attacker to
perform a denial of service attack. A DNS name can contain up to 255 characters
and each level of delegation requires 2 characters. This means that an attacker
can cause a simple iterative search algorithm to perform over a hundred name
lookups by creating a name of the form security.a.a.a.a?.example.com.
A second problem with the iterative approach is that it does
not provide sufficient guidance for cases where the DNS name cannot be
resolved. When the DNS system was originally deployed every DNS name was
visible to every Internet user. Today this is no longer the case and most
enterprises employ some form of ?split DNS? such that the DNS names of machines
on the internal network are not externally visible. This means that it is
entirely possible for a machine to be the genuine source of a legitimate email
even though the recipient cannot resolve the DNS name specified in the email
from address. Such a machine can still receive mail by means of a wildcard mail
exchange (MX) record.
Another approach to the policy inheritance problem would be
to re-engineer the DNS system to provide explicit support for this feature.
Such a solution is practical in technical terms but is impractical from a
deployment standpoint. Any proposed policy inheritance mechanism must have
minimal impact on the legacy infrastructure and in particular should not
require ?double-ended? deployment of an infrastructure change where both the
sender and receiver of the data must upgrade their infrastructure in order to
take advantage of the change.
Our requirements for inheritable email signing policy
mechanism are thus:
Efficiency
The mechanism must be efficient, allowing the email signature policy
corresponding to any node, whether existing or not to be obtained within a
small, bounded number of operations.
Inheritable
It must be possible to specify the email signing policy for every sub-domain
within a domain regardless of whether the node exists or not
Minimal
Impact
The mechanism must have minimal operational impact and in particular must not
require extensive deployment of new infrastructure or attempt to restrict
established administration conventions such as the use of split DNS.
Minimize
Administration Errors
The mechanism should be robust when used over an extended time period. Routine
administration processes such as changing DNS server configuration should not
result in side effects that result in unexpected changes to the interpretation
of policy.
Extensible
The mechanism should allow for extension to publication of security policies
and other types of policy information for other protocols.
2. Constraints
2.1 The DNS Zone Cut
Another solution that is often proposed in the context of
the policy inheritance problem is to make use of the DNS ?zone cut?. The DNS is
a hierarchical name space that permits (but does not require) delegation at
each level in the hierarchy.
For example the name security.example.com would typically
require queries to three separate DNS servers. The DNS ?root? is first queried
to discover the address of the authoritative servers for the .com domain. An authoritative server
for the .com domain is then
queried in turn to discover the authoritative server for the .example.com domain which in this case
services all sub-domains within the .example.com
domain and returns the answer. The same server could also provide an
authoritative response for mail.security.example.com
without the need to respond with a delegation statement.
The DNS ?authoritative server? delegation point is sometimes
referred to as the ?zone cut?. The zone cut may be used to create a simple
algorithm for establishing a policy inheritance. The recipient first queries
for policy data associated with the full domain name. If no policy data is
available for the full domain name the recipient queries for a policy record
associated with the apex of the zone cut.
For example if no data is found for mail.security.example.com the node example.com is examined for a wildcard
record.
The zone cut is a feature of the DNS architecture that is
visible at the administrative level but frequently opaque at the client level.
DNS is explicitly designed as an intermediated protocol in which each network
connects to the core DNS infrastructure by means of a local caching DNS server.
Many enterprises operate transparent DNS proxies which ensure that all DNS
queries are funneled through the authorized DNS connection infrastructure
either to limit the use of DNS as an unauthorized covert channel or to prevent
outbound Denial of Service attacks via the DNS protocol. The Zone cut mechanism
thus fails the requirement Minimal Impact.
The net result of the intermediated DNS architecture is that
a DNS client application cannot rely on obtaining the necessary data to
determine the location of the zone cut.
A second difficulty with the use of the zone cut is that it
means that changing a DNS server configuration to add or remove a delegation
point has new and significant consequences for the semantics of the policy
records. A DNS administrator for an enterprise who delegates control over a
sub-domain to a separate server must remember to copy the default policy. The
Zone cut mechanism thus fails the requirement Minimize Administration
Errors.
2.2 Limitations of the DNS Wildcard Mechanism
The DNS specification defines a form of wildcard mechanism
but the matching rules are considerably more limited than would generally be
expected for a wildcard mechanism. A DNS wildcard may be used to specify
default records but only for DNS nodes that do not exist at all.
For example the zone example.com might contain a wildcard MX
at the zone apex and an A record for the name pc.example.com. A query for the
MX record for the name pc.example.com returns an empty result and not the
wildcard value.
The limitations of the DNS wildcard mechanism affect many
other administrative tasks including coding records for the Sender-ID policy
mechanism. One way to overcome these limitations is to define a new type of
wildcard that provides a match if a domain exists but has no record entry
corresponding to the query. The use of the % character has been proposed for
this purpose.
Support for the % wildcard can be implemented by means of a
macro processor. For this reason this type of wildcard is sometimes referred to
as a ?macro? wildcard.
2.3 Limited Support for New Resource Record Types
The existing DNS infrastructure provides only a limited
degree of support for newly defined DNS Resource Record (RR) formats. Although
support for new RR types is defined in RFC 3597 this only became a proposed
standard in September 2003. A significant proportion of the deployed DNS
servers do not tolerate unknown resource records.
In particular no version of the Windows operating system
provides native support for new DNS RR types. The DNS server is closely
integrated into the Active Directory subsystem and cannot be adequately
substituted by third party product. Although the native DNS service supports
caching of new RR types and can even be persuaded to emit new RR data items
under certain circumstances critical features such as the ability to survive a
reboot are not supported.
Another area for serious concern is that many embedded
systems including firewalls and low cost ?cable-routers? include embedded DNS
servers that may not provide the necessary level of support.
Accordingly the introduction of new RR types is not
considered to currently meet the requirement Minimal Impact.
2.4 Limitations of the Prefix Extension Mechanism
On means of overcoming the difficulties associated with the
deployment of new resource record is to use a prefix to modify the semantics of
an existing record. In this scheme Resource Record definitions are considered
to describe the syntax of the record and the semantics are
described by means of the prefix.
This mechanism was first applied in the definition of the
SRV (service) record. The prefix mechanism allows new service records to be defined
without the need for the delay that definition and deployment of a new RR type
inevitably incurs.
The main architectural limitation of the prefix scheme is
that use of wildcards results in ambiguity. A DNS wildcard cannot be specified
at a midpoint within a DNS name so it is not possible to define a prefix of the
form _prefix.*.example.com. If a
wildcard is applied at the domain apex (*.example.com)
it will match queries for any service prefix.
Although wildcards are implemented as a server feature and
are only exchanged on the wire in very limited circumstances in the traditional
DNS protocol this situation is changed when DNSSEC is used to sign a zone. The
DNSSEC protocols do not currently support midpoint wildcards and although there
is no reason why they could not be supported in principle the protocol is
already overdue and it is desirable to avoid further changes to the specification
if at all possible.
3. Proposal
We propose the use of the following features to address the
requirements:
- Prefixed TXT
Records to express policy information for an existing node
- Use of the Wildcard mechanism to describe the location
where default policy information can be retrieved for non-existent nodes.
- Use of synthetic Wildcards to provide an administrative
convenience to describe default policy information for existing nodes that
do not have explicit policy information specified.
The retrieval algorithm for the policy corresponding to the
policy _policy for DNS node node.example.com is as follows:
policy, location : String
policy = DNS.Lookup ( TXT, _policy.node.example.com)
IF (policy == NULL) THEN
location = DNS.Lookup ( ???, node.example.com)
IF (location != NULL) THEN
policy = DNS.Lookup ( TXT, "_policy." + location)
ELSE
policy = NULL
RETURN policy
Note that the retrieval algorithm never requires more than
three DNS lookups in any circumstance.
For example consider the following definition for the DNS
zone example.com:
*.example.com ??? _d.example.com
%.example.com ??? _x.example.com
a.example.com A 10.0.0.1
_dk.a.example.com TXT "signed=all"
b.example.com A 10.0.0.2
_dk._d.example.com TXT "signed=unknown"
_dk._x.example.com TXT "signed=never"
After preprocessing the macro _expression_ %.example.com is
removed and replaced with the entries:
a.example.com ??? _x.example.com
b.example.com ??? _x.example.com
Retrieving policy information for the sub-domains a, b and c
produces the following results:
a.example.com ??? "signed=all"
b.example.com ??? "signed=never"
c.example.com ??? "signed=unknown"
Although the macro expansion causes a pointer record to be
created for the sub-domain a.example.com
the explicit entry _dk.a.example.com
takes priority.
Note that the indirect pointer mechanism provides a
convenient means of administering large domains where the number of policies is
much smaller than the number of machines. Each policy is specified in a
separate record and pointer records are used to identify the policy that
applies to a particular machine.
This mechanism is readily extensible to a regime where
multiple policy record prefix are defined.
The main outstanding design choice is the choice of resource
record identifier to represent the pointer record ???.
References
[RFC3597] RFC 3597 Handling of Unknown DNS Resource
Record (RR) Types. A. Gustafsson. September 2003. IETF. (Status: PROPOSED
STANDARD)