DNS Operations S. Krishnaswamy
Internet-Draft SPARTA Inc.
Expires: September 5, 2007 March 4, 2007
Split-View DNSSEC Operational Practices
draft-krishnaswamy-dnsop-dnssec-split-view-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The security extensions to the Domain Name System (DNSSEC) allow for
integrity protection, whereby it is possible to make a determination
of the verity of data returned from the Domain Name System in
response to a query. Current operation of the Domain Name System
also allows for the creation of multiple views of data, where the
answer returned in response to a query is dependent on the origin of
the query. Data integrity and the ability to return possibly
conflicting values as in split-views may be construed to be mutually
conflicting goals; but this apparent dichotomy is resolvable in
Krishnaswamy Expires September 5, 2007 [Page 1]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
practice through careful configuration. This document provides
recommendations for configuring a manageable split-view DNSSEC
environment in a representative enterprise network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Considerations for split-views . . . . . . . . . . . . . . . . 4
2.1. Split-Views and Name Hiding . . . . . . . . . . . . . . . 4
2.2. Representative Network Structure . . . . . . . . . . . . . 5
2.3. Special Capabilities in Network Devices . . . . . . . . . 5
3. Generic Split-View DNS Architecture . . . . . . . . . . . . . 5
3.1. Query Channeling . . . . . . . . . . . . . . . . . . . . . 6
3.2. Controlling Errant Queries . . . . . . . . . . . . . . . . 8
3.3. Name Server Requirements for Split-Views . . . . . . . . . 8
3.3.1. Internal Recursive Forwarder . . . . . . . . . . . . . 8
3.3.2. Boundary Recursive Name Server . . . . . . . . . . . . 8
3.3.3. Authoritative Internal and External-View Name
Servers . . . . . . . . . . . . . . . . . . . . . . . 9
4. Split-View DNSSEC . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Approaches . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Same Key Signing . . . . . . . . . . . . . . . . . . . 10
4.1.2. Partial Decoupling of Authentication Chains . . . . . 11
4.1.3. Multiple DS Records . . . . . . . . . . . . . . . . . 13
4.1.4. Complete Decoupling of Authentication Chains . . . . . 14
4.1.5. No Internal Validation . . . . . . . . . . . . . . . . 16
4.2. Name Server Requirements for Split-View DNSSEC . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Packet Filtering Considerations . . . . . . . . . . . 19
A.1. Inner Packet Filter . . . . . . . . . . . . . . . . . . . 19
A.2. Outer Packet Filter . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Krishnaswamy Expires September 5, 2007 [Page 2]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
1. Introduction
Split-view DNS is the term used to describe the behavior where the
DNS returns different responses to the same query based upon the
query source address. It is also a network management technique that
can be used to restrict DNS names to only those segments or views of
the network that need to see these names.
The security extensions to DNS (commonly labeled "DNSSEC") [1]
provide for origin authenticity and data integrity. These properties
are determined by validating the authentication chain from some trust
anchor configured at the validating resolver to a signed record.
The combination of DNSSEC with split-views raises some potential
issues and concerns. In the case of split-view DNS every
authentication chain in every view must validate properly. Names
that are common in different views may contain different data for the
same resource record type in each of these views. Cache
contamination is a possibility when data from the wrong view is
returned in response to a query. For "private" views, or views of
the DNS that contain data not available through the public DNS,
building an authentication chain from a public trust anchor to data
in the private view of a zone can be especially problematic, caching
problems notwithstanding.
This document describes a configuration that allows for the co-
existence of split-views with DNSSEC. Section 3 describes a generic
two-level recursive scheme where an Internal Recursive Forwarder
resolves internal answers from internal authoritative name servers
and marshalls all other queries to a Boundary Recursive Name Server.
TSIG between the Internal Recursive Forwarder and the Boundary
Recursive Name Server protects against errant queries.
Section 4 provides multiple choices for configuring the trust anchor
while using DNSSEC. This list of choices provides trade-offs between
configuration overhead and validation overhead. Trading-off in
favour of minimal operator overhead is useful for overall
maintainability of the system, especially when split-view DNS is
considered in the context of validating stub resolvers that are
mobile across the two views.
In cases where the different views of DNS information correspond to
different physical networks, the name servers authoritative for the
internal and external views of data are often separated by a
firewall. This document provides recommendations for reducing the
impact of errant queries in the split-view DNS setup and also makes
recommendations in Appendix A for DNS-related packet filtering rules
required to support the proper operation of the suggested
Krishnaswamy Expires September 5, 2007 [Page 3]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
configuration.
Although closely tied to it, this document must not be viewed as an
endorsement of split-views technique in itself; this document only
provides recommendations for DNSSEC in such environments while
avoiding some of the common pitfalls that are possible in this setup.
The approach given in this document is adjustable for various
operational and security consideration levels. Network architects
may implement other mechanisms for DNSSEC split-views however they
must carefully consider the ramifications of any changes with respect
to the base architecture given in this document.
2. Considerations for split-views
2.1. Split-Views and Name Hiding
Although primarily meant to be a network management technique, the
use of split-views is also seen by some as an approach for improving
an organization's security posture - by preventing the exposure of
internal host names, knowledge of whose existence is deemed to be
sensitive.
Relying solely on split-view DNS to protect sensitive hosts from
attacks has proven to be insufficiently adequate in the past and is
not recommended. Attack vectors in Internet exploits have been able
to successfully infect hosts with or without their IP addresses being
published in the DNS. Conversely, publishing the IP addresses of
hosts that are otherwise secured does not necessarily increase their
vulnerability to these attacks.
Name hiding through split-view DNS is primarily useful as part of a
more comprehensive defense-in-depth strategy to provide one line of
defense against name-based attacks. Split-views are not recommended
by themselves as a name-hiding approach. A better alternative for
protecting a namespace of sensitive hosts is to have that entire
namespace reside within a private delegation. By doing so, it is
possible to have the protection given to the name server that serves
these names commensurate with the protection given to the hosts
themselves. Since hosts in the private branch are explicitly marked
as such by virtue of their domain name, this method also allows the
network administrator to better classify hosts as being public or
private and lessens the opportunity for sensitive hosts to be
inadvertantly placed in public domains. Private delegations are
useful when name hiding is the only reason for namespace separation.
They do not, however, allow for transparency during name resolution;
queries have to be made for specific names in specific views.
Krishnaswamy Expires September 5, 2007 [Page 4]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
2.2. Representative Network Structure
The architecture for split-views in this document is modeled around a
representative enterprise structure as described below.
The two views are for the internal and external segments of the
network, with the external segment residing within the boundary
network. The external view of the DNS is also the "global" view of
the enterprise to the outside world. The two networks are separated
by a packet filtering firewall. A packet filtering firewall also
separates the boundary network from the external Internet. Name
hiding is not an objective of this split-view setup, but avoiding
cache contamination is. Although the two concepts are related,
split-views is not recommended for hiding sensitive names because of
the ease with which names can be leaked out (through email headers,
for example). Again, if name hiding is the main objective, the
approach of using a private delegation for sensitive names is
strongly encouraged.
2.3. Special Capabilities in Network Devices
Some name server implementations directly support split-view DNS as a
configuration feature. However, the options for placement of such
devices in the representative architecture suggested above are rarely
optimal.
Split views can also be constructed using a single multi-homed device
in lieu of the multiple machines suggested in this document -- an
approach typically used in a proxy-firewall setting. The device is
configured as the authoritative name server for both views of data by
running multiple instances of the name server process and answering
differently based on the query source.
This document describes a generic architecture for split-view DNS
without relying on any of the above special capablities from any
network device or name server implementation. Ergo, the number of
distinct devices that provide the name resolution function is
increased. Networks that use a reduced set of network devices for
providing the split-view functionality may still draw from
recommendations given in this document, provided that the
ramifications of any change (if any) with respect to the base
architecture given in this document are well understood.
3. Generic Split-View DNS Architecture
Split-views can be implemented using an approach known as "query
channeling". Query channeling involves carefully controlling the
Krishnaswamy Expires September 5, 2007 [Page 5]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
security-aware validating name server path for fetching responses
from different name servers so that cache contamination is avoided.
Figure 1 illustrates this setup.
^
| +------------+ +----------------+
[External] | root, TLD | | External Rec NS|
| | servers etc| | and resolvers |
| +------------+ +----------------+
| (Q)^ | | ^(R)
| | | | |
v +------------------------------------------------------+
======| Outer Packet Fiter/Firewall |======
^ +------------------------------------------------------+
| | | | |
[ DMZ ] | v(R) (Q)v |
Boundary +------------+ +--------------+ +----------+
| | MTAs, etc | | Boundary | | Ext-view |
| | | | recursive NS | | Auth NS |
| +------------+ +--------------+ +----------+
| (R)^ | (Q)^ |
| | | | |
v +------------------------------------------------------+
======| Inner Packet Fiter/Firewall |======
^ +------------------------------------------------------+
| | | | |
[Internal] | | | |
| | v(Q) | v(R)
| +----------+ (Q)+---------------+ (Q)+----------+
| | Int-view |---->| Internal Rec. |---->|Int-view |
| | clients |<----| Forwarder |<----| Auth NS |
| +----------+(R) +---------------+(R) +----------+
|
v
Figure 1: Split-View Architecture
3.1. Query Channeling
Resolution of external data by clients in the external segment of the
network or in the global Internet is straightforward since queries
follow their normative paths. The configuration in Figure 1 uses a
combination of multiple name servers and query forwarding to return
answers for clients in the internal segment of the network.
One server functions as an Internal Recursive Forwarder and is
responsible for answering queries for clients on the internal segment
of network. Some appliances in the boundary network (such as Mail
Krishnaswamy Expires September 5, 2007 [Page 6]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
Transfer Agents, MTAs) may directly query the Internal Recursive
Forwarder for the internal view of certain names.
None of the name servers in this architecture are simultaneously
recursive and authoritative. Separation of authoritative and
recursive name servers not only provides simple role separation, but
is also widely recognized as a security measure in DNS for protecting
authoritative name servers against compromised caches.
The Internal Recursive Forwarder forwards any query for internal data
to its corresponding Internal-view Authoritative Name Server while
recursively obtaining any other data from a Boundary Recursive Name
Server. The Internal-View Authoritative Name Servers do not perform
recursion. In cases where queries can only be forwarded per zone,
the Internal Recursive Forwarder recursively obtains answers for any
names that lie within delegations under the forwarded zones, so
queries for child names do not require further forwarding. However,
if forwarding is only possible per domain, the Internal Recursive
Forwarder must explicitly forward queries for every internal
delegation to its respective authoritative name server. This rule
can be relaxed while forwarding queries to name servers that are
simultaneously authoritative for the child as well as the parent
zone.
The Boundary Recursive Name Server is a simple caching name server
that obtains answers from the outside, but only if asked by the
Internal Recursive Forwarder. Separation of the Internal Recursive
Forwarder from the Boundary Recursive Name Server allows queries to
and responses from the outside network to be channeled (and mediated)
through the boundary network.
The Internal Recursive Forwarder and the Internal-view Authoritative
Name Servers reside in the internal network; the Boundary Recursive
Name Server and the External-view Authoritative Name Servers reside
in the boundary network. The Boundary Recursive Name Server and the
Internal Recursive Forwarder may alternatively be implemented as an
integral part of the device that provides packet-filtering or
firewalling services between the internal network and the boundary
network, provided that they execute as distinct and well-separated
processes within this device.
The two-level recursive scheme controls the name servers to which
queries are directed to. Since queries for internal data are sent to
authoritative name servers which are not recursive, this scheme also
controls the data reception path. In this way internal data can be
kept totally separate from external data, thus preventing cache
contamination.
Krishnaswamy Expires September 5, 2007 [Page 7]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
3.2. Controlling Errant Queries
DNS queries that are sent from the Internal Recursive Forwarder for
global DNS data should only be directed towards the Boundary
Recursive Name Server. Since the Boundary Recursive Name Server has
no knowledge of internal-view data, internal clients must not use it
directly for resolving any queries. Only properly configured
Internal Recursive Forwarders that are approved to send queries to
this name server must do so.
It is useful to note that the Internal Recursive Forwarder must not
attempt to recursively answer queries if the Internal-view
Authoritative Name Server fails to respond. If it did so, external
data could be returned in such circumstances and lead to cache
contamination.
TSIG [3] is the recommended method for controlling which name servers
are approved for sending queries to the Boundary Recursive Name
Server. Alternatively, configuring the Boundary Recursive Name
Server such that it only answers queries for the Internal Recursive
Forwarder(s), and supporting this configuring with an appropriate set
of rules in the packet filter is also possible.
Some devices such as MTAs that reside in the Boundary network may
also directly query the Internal Recursive Forwarder for internal
data. This must be configured via an appropriate set of rules at the
packet filter between the Internal Network and the Boundary Network.
3.3. Name Server Requirements for Split-Views
This section summarizes the list of requirements for the various name
servers involved in the split-view configuration.
3.3.1. Internal Recursive Forwarder
o Ability to forward queries for names in specific zones or domains
to specific name servers.
o Ability to control forwarding behaviour such that no further
attempt to resolve the query is made if the name server(s) that
queries are normally forwarded to fails to respond.
o Ability to recursively answer queries.
o Ability to authenticate (and verify the authenticity of) messages
using TSIG.
3.3.2. Boundary Recursive Name Server
Krishnaswamy Expires September 5, 2007 [Page 8]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
o Ability to recursively answer queries.
o Ability to authenticate (and verify the authenticity of) messages
using TSIG.
o Ability to filter incoming queries based on the TSIG key used to
authenticate the message.
3.3.3. Authoritative Internal and External-View Name Servers
o Ability to authoritatively answer queries for a zone.
o Ability to disable all recursive behaviour.
4. Split-View DNSSEC
The DNSSEC concern for split-view is ensuring that both the internal
and the external authentication chains validate properly. While
validating external data is relatively straightforward, there are
multiple approaches that can be used for validating internal data.
The method of choice depends on the percieved threat environment for
the internal view, the amount of end-resolver configuration overhead
and the ability to support administrative separation between the two
split-views.
The configuration overhead at end resolvers is mainly associated with
the task of managing trust anchors. Having fewer keys is desirable
since it makes key management easier. It is also desirable to reduce
the amount of reconfiguration required for validating stub resolvers
that are mobile across the two views of data, while still being able
to tie an answer to a particular view when troubleshooting this
setup. In many cases two views of a split zone are administered
separately, so the ability to configure and use different zone
signing keys for the different views is also useful.
4.1. Approaches
The different options for internal data validation, with
recommendations on when these options must (and must not) be used,
are further outlined below. In each of these options, the zone that
is split is assumed to be a delegation under example.com and unless
explicitly mentioned, configuration of trust anchors (and hence
validation of internal data) occurs at the Internal Recursive
Forwarder and validating stub resolvers. Validating stub resolvers
that operate in the internal segment of the network must still
resolve DNS queries through the Internal Recursive Forwarder.
Krishnaswamy Expires September 5, 2007 [Page 9]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
4.1.1. Same Key Signing
-----------> example.com (trusted)
/ ^ ^
/ | |
/ (same key)-->|
/ |
split.example.com split.example.com
(internal) (external)
^ ^
|<--- (same key) ------>|
| |
sub.split.example.com sub.split.example.com
(internal) (external)
Figure 2: Same Key Signing
DESCRIPTION:
The same keys are used to sign corresponding zone data in both views
of the split name space. The DS, NS and glue records at example.com
all correspond to the external view data. Since the keys referenced
in the DS record at example.com are present in the apex key-set of
both views, the authentication chain can always be completed. The
trust anchor at the Internal Recursive Forwarder and any validating
stub resolver can be configured at any level of the zone hierarchy.
ADVANTAGES:
o Trust Anchor management is simple in this approach. A single
trust anchor is sufficient to validate answers in both views.
There is also more flexibility in chosing the zone level at which
the Trust Anchor is defined.
o Validating stub resolvers on hosts that are mobile across views
can validate answers in both views without having to change their
trust anchor.
o Key management is straightforward for administrators since the
same keys are used for signing the internal and external views.
DISADVANTAGES:
o Although easy to setup, this approach can be difficult to
troubleshoot. There is no easy way to identify if the record
obtained for a query corresponds to the internal view or the
external view.
o Using the same key makes administrative separation of the two
views of data difficult.
Krishnaswamy Expires September 5, 2007 [Page 10]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
o Cache contamination caused by the insertion of data from the
external view for data with the same name in the internal view (or
vice-verca) cannot be automatically detected.
RECOMMENDED USAGE SCENARIO:
o This approach must be only used when all zones covered by the
split are administered by the same individual and key management
overhead needs to be kept to a minimum.
4.1.2. Partial Decoupling of Authentication Chains
---------------> com
/ ^ ^
/ | |
/ (same key)-->|
/ |
(trusted) example.com example.com (trusted)
(internal) (external)
^ ^
|<--- (diff key) ------>|
| |
split.example.com split.example.com
(internal) (external)
^ ^
|<--- (diff key) ------>|
| |
sub.split.example.com sub.split.example.com
(internal) (external)
Figure 3: Partial Decoupling of Authentication Chains
DESCRIPTION:
In this approach example.com zone is also split into two views.
Different keys are used for signing each view of the split below (but
not including) example.com such that the authentication chains for
the internal and external zones share no common records that may
cause any ambiguity. The trust anchor is configured at the level of
example.com or higher. The apex keyset in example.com is the same
for both views, but the glue and DS information for delegations under
example.com is different across views. An internal name server is
configured as the authoritative server for the internal view of the
split example.com zone and the Internal Recursive Forwarder is
modified to forward all internal queries for this zone to it.
ADVANTAGES:
Krishnaswamy Expires September 5, 2007 [Page 11]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
o Trust Anchor management is simple in this approach. A single
trust anchor is sufficient to validate answers in both views.
o Validating stub resolvers on hosts that are mobile across views
can validate answers in both views without having to change their
trust anchor.
o Having separate keys for the two views of data is useful for
troubleshooting and in determining which view a given record
belongs to.
o The approach allows for administrative separation between the
different views.
o As long as all members of the authentication chain are not
inserted from one view to the other, cache contamination caused by
the insertion of data from the external view for data with the
same name in the internal view (or vice-verca) can be
automatically detected.
DISADVANTAGES:
o Key management is onerous since different keys are used to sign
data in different views.
o This approach relies on the presence of an additional view of the
example.com zone where relevant records are duplicated. The
number of such records is typically not very large, but the
overhead and complexity in maintaining duplicate records can, in
some cases, be a burden. This approach must only be used if this
duplication is administratively viable.
o Cache contamination caused by the insertion of data from the
external view for data with the same name in the internal view (or
vice-verca) cannot be automatically detected when all elements of
the authentication chain are inserted.
RECOMMENDED USAGE SCENARIO:
o This approach may be used if internal and external views are
administered separately. This approach may also be used when
there is a single administrator, if the administrator has a well-
defined process in place for managing DNS keys.
o This approach is not recommeded if creating a split view of the
parent (example.com) is not administratively viable.
Krishnaswamy Expires September 5, 2007 [Page 12]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
4.1.3. Multiple DS Records
-----------> example.com (trusted)
/ (DS1) ^
/ |
/ | (DS2)
/<--- (diff key) ---->|
/ |
split.example.com split.example.com
(internal) (external)
^ ^
| |
|<--- (diff key) ------>|
| |
sub.split.example.com sub.split.example.com
(internal) (external)
Figure 4: Multiple DS Records
DESCRIPTION:
This approach is simliar to Section 4.1.2. However, in this
approach, example.com is not split. DS records corresponding to each
of the two different views of split.example.com are published at the
delegation point. The glue and NS records at the delegation point
still correspond to the external view of split.example.com but this
information is never used by the internal zone. The trust anchor is
configured at the level of example.com or higher. The authentication
chain from this trust anchor to data in either zone is automatically
constructed by using one of the two DS records, which ever is
applicable at that view.
ADVANTAGES:
o Trust Anchor management is simple in this approach. A single
trust anchor is sufficient to validate answers in both views.
o Validating stub resolvers on hosts that are mobile across views
can validate answers in both views without having to change their
trust anchor.
o Having separate keys for the two views of data is useful for
troubleshooting and in determining which view a given record
belongs to.
o The approach allows for administrative separation between the
different views.
o As long as all members of the authentication chain are not
inserted from one view to the other, cache contamination caused by
the insertion of data from the external view for data with the
same name in the internal view (or vice-verca) can be
Krishnaswamy Expires September 5, 2007 [Page 13]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
automatically detected.
DISADVANTAGES:
o Key management is onerous since different keys are used to sign
data in different views.
o While most of the internal zone contents can be kept private to
the internal view, the DS record must still be exposed. Since
data hiding is not an objective of the split-view setup this is
not really a problem in most instances.
o An attendent problem with multiple DS records is that since the
validation algorithm iteratively verifies parent DS records while
trying to complete the authentication chain, there is some added
computational overhead, which increases as the number of DS
records in the delegation point grows.
o Cache contamination caused by the insertion of data from the
external view for data with the same name in the internal view (or
vice-verca) cannot be automatically detected when all elements of
the authentication chain are inserted.
RECOMMEDED USAGE SCENARIO:
o This approach may be used if internal and external views are
administered separately. This approach may also be used when
there is a single administrator, if the administrator has a well-
defined process in place for managing DNS keys.
o Since some coordination between split.example.com and its parent,
example.com, is required to publish multiple DS records, this
approach is most suitable when the split is made at a level lower
than the organization apex.
o This approach must not be used if exposure of the DS record for
the internal view of the split view is considered to be a problem.
4.1.4. Complete Decoupling of Authentication Chains
example.com (trusted)
^
|
(trusted) split.example.com split.example.com
(internal) (external)
^ ^
| |
|<--- (diff key) ------>|
| |
sub.split.example.com sub.split.example.com
(internal) (external)
Figure 5: Complete Decoupling of Authentication Chains
Krishnaswamy Expires September 5, 2007 [Page 14]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
DESCRIPTION:
This approach makes it possible to create multiple split views
without having to split or modify the parent zone data in any manner.
It does so at the expense of increased administrator overhead. In
this approach different keys are used for signing each view of the
split below (and including) split.example.com such that the
authentication chains for the internal and external zones share no
common records that may cause any ambiguity. A new trust anchor is
configured for each internal view of the split zone in addition to
any existing trust anchors for the outer zone data.
ADVANTAGES:
o This approach allows for administrative separation between the
different views.
o Having separate keys for the two views of data is useful for
troubleshooting and in determining which view a given record
belongs to.
o This approach can automatically detect cases where data from the
external zone has been inserted into the internal network.
DISADVANTAGES:
o Key management is onerous since different keys are used to sign
data in different views.
o Trust Anchor management is onerous since multiple trust anchors
need to be configured at validating resolvers.
o Validation on moible hosts containing stub resolvers may not be
seamless. The outcome of validation in the external view may be
impacted by the local policy on the validator, which decides how
multiple trust anchors are evaluated. Further, in a working setup
involving multiple trust anchors, cache contamination cannot be
detected automatically. In order to have predictable results, the
trust anchors configured on such validators must be constantly
changed whenever they move across views.
RECOMMEDED USAGE SCENARIO:
o This approach may be used if the two views are signed and the
approaches specified in Section 4.1.2 and Section 4.1.3 are not
feasable.
o This approach may also be used in scenarios where DNSSEC
deployment schedules for the two split views are different and the
internal view data is signed and deployed long before the external
view data. DNSSEC deployment in the two views can occur
independently.
Krishnaswamy Expires September 5, 2007 [Page 15]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
o This option may also be used when accidental or malicious
insertion of DNS data across views is a concern.
4.1.5. No Internal Validation
(No trust anchors) example.com (trusted)
^
|
|
split.example.com split.example.com
(internal) (external)
^
|
|
sub.split.example.com sub.split.example.com
(internal) (external)
Figure 6: No Internal Validation
DESCRIPTION:
The Internal Recursive Forwarder does not perform any DNSSEC
validation for internal view data. DNSSEC is enabled but no trust
anchors are configured at the Internal Recursive Forwarder and
validating stub resolvers. Instead, trust anchors are configured at
the Boundary Recursive Name Server for validating global data queried
by clients in the internal view of the network. The Internal
Recursive Forwarder does not return answers that do not contain the
AD bit from the Boundary Recursive Name Server to internal clients.
The organizational network is assumed to be secure, so no additional
last-mile protection of DNSSEC results between the Boundary Recursive
Name Server and the Internal Recursive Forwarder is needed.
It should be noted that disabling DNSSEC validation in the internal
view can also be accomplished by selectively turning "off" DNSSEC at
the Internal Recursive Forwarder for all zones under and including
the internal view of the split namespace if this feature is
available. However, this has the drawback that such features would
have to be additionally supported by and configured at every
validating stub resolver.
ADVANTAGES:
o Trust Anchor management is simple in this approach. Trust anchors
are only needed for validating external view data.
o Key management is straightforward for administrators since keys
are not required for the internal view.
Krishnaswamy Expires September 5, 2007 [Page 16]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
DISADVANTAGES:
o Requires additional configuration on validating resolvers to add
and remove trust anchors as they move from the internal to
external view and vice-versa.
RECOMMENDED USAGE SCENARIO:
o This is an option if the organizations internal and boundary
network are considered safe -- the threat environment for the
internal zone in this scenario does not include DNS compromise.
o This approach may be used in scenarios where DNSSEC deployment
schedules for the two split views are different and the internal
view data is signed and deployed long after the external view
data.
4.2. Name Server Requirements for Split-View DNSSEC
In order to support split-views with DNSSEC, in addtion to the list
of requirements specified in Section 3.3, all name servers involved
in the split-view configuration must conform to the specifications
given in [2]. DNSSEC support must be enabled on all of these name
servers. Additionally, the Internal Recursive Forwarder must support
the following features:
o Ability to validate DNSSEC responses.
o Support for configurable DNSSEC trust anchors. It should be
possible to configure more than one trust anchor.
o Ability to accept or discard reponses from the Boundary Recursive
Name Server based on the AD bit as described in Section 4.1.5.
5. IANA Considerations
This document has no actions for IANA.
6. Security Considerations
The configuration suggested in this document tries to minimize cache
contamination, but misconfigurations are still easily possible. Any
misconfigurations in the three different types of name servers or the
two packet filters can result in cache contamination and cause
incorrect or inconsistent results to be returned between views. The
validating resolver may or may not detect this depending on the
manner in which secure entry points to split zones are defined and
which trust anchors are configured. Confidentiality loss caused by
leakage of information in this context is not an issue since split-
Krishnaswamy Expires September 5, 2007 [Page 17]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
views by itself is not meant to provide this functionality. In name-
hiding is the objective, split-views can (and must) be avoided and
the alternative scheme of using different names for internal and
external domains must be used instead.
An improperly configured packet filter that allows errant DNS traffic
through or denies legitimate responses can lead to aggressive
retransmission of queries by resolvers to name servers, leading to
increased query load at such name servers.
Each of the validation options outlined in Section 4 also introduce
their own security considerations. Not using DNSSEC in the internal
view creates the possibility of a malicious entity supplying bogus
information in response to queries, without detection. Using a
common key between both views of the split does not allow one to
differentiate between internal and external data and troubleshooting
is greatly encumbered. On the other hand, using a multitude of keys
at validating resolvers increases the operator overhead and thus the
chances for configuration errors. All approaches that use a common
key for validating internal and external data are unable to
automatically detect cache contamination, so they may escape the
attention of a system administrator until troubleshooting begins.
Approaches using a common trust anchor are also susceptible to an
insider attack where data from one view injected into a response for
queries for data in the other the other view can corrupt the cache
within the Internal Recursive Forwarder.
7. Acknowledgements
The contributions, suggestions and remarks of the following persons
to this draft are particularly acknowledged: Wes Griffin, John
Kelley, Ed Lewis, Russ Mundy, Scott Rose, Mike StJohns, Char Sample,
Andrew Sullivan, Howard Eland, Wes Hardaker and Robert Story. The
two-level name server scheme described in this document builds upon
work that was originally performed by Ed Lewis.
8. References
8.1. Normative References
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
Krishnaswamy Expires September 5, 2007 [Page 18]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
RFC 4035, March 2005.
[3] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
8.2. Informative References
[4] Larson, M. and P. Barber, "Observed DNS Resolution Misbehavior",
Work in Progress ietf-dnsop-bad-dns-res, July 2005.
Appendix A. Packet Filtering Considerations
Among some of the frequently observed DNS resolution misbehaviour [4]
is the problem of resolvers aggressively retransmitting queries from
behind misconfigured firewalls that allow queries out, but drop all
returned responses. This problem is exacerbated by a handful of
errant queries that are sent by only a subset of internal resolvers,
which makes problem isolation extremely difficult. The following
subsections define the rules that must be configured in the two
packet filters depicted in Figure 1 in order to support the split-
view configuration.
A.1. Inner Packet Filter
In order to allow the configuration described in Section 3 to work,
any packet filtering system between the internal network and the
boundary network must ALLOW all of the following types of packets.
o DNS queries from any internal address to the Boundary Recursive
Name Server (finer level access control is done by TSIG):
Proto SrcIP SrcPort DestIP DstPort AckBit
UDP internal >1023 boundary rec srv 53 N/A
UDP internal 53 boundary rec srv 53 N/A
TCP internal >1023 boundary rec srv 53 Any
o Responses to the above queries from the Boundary Recursive Name
Server to any internal address:
Proto SrcIP SrcPort DestIP DstPort AckBit
UDP boundary rec srv 53 internal >1023 N/A
UDP boundary rec srv 53 internal 53 N/A
TCP boudnary rec srv 53 internal >1023 Set
Krishnaswamy Expires September 5, 2007 [Page 19]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
o Queries from devices in the boundary network (such as MTAs) to any
internal name server:
Proto SrcIP SrcPort DestIP DstPort AckBit
UDP boundary device >1023 internal 53 N/A
TCP boundary device >1023 internal 53 Any
o Responses to the above queries from the (any) recursive forwarder
to devices that reside in the boundary network:
Proto SrcIP SrcPort DestIP DstPort AckBit
UDP internal 53 boundary device >1023 N/A
TCP internal 53 boundary device >1023 Set
The packet filtering system between the internal network and the
boundary network must finally DROP any DNS packets not covered by the
above rules.
Proto SrcIP SrcPort DestIP DstPort AckBit
UDP Any 53 Any Any N/A
UDP Any Any Any 53 N/A
TCP Any 53 Any Any Any
TCP Any Any Any 53 Any
A.2. Outer Packet Filter
Any packet filtering system configured between the boundary network
and the external network needs to ALLOW the following.
o Queries from the Boundary Recursive Name Server network to the
external network:
Proto SrcIP SrcPort DestIP DstPort AckBit
UDP boundary rec srv >1023 Any 53 N/A
UDP boundary rec srv 53 Any 53 N/A
TCP boundary rec srv >1023 Any 53 Any
Krishnaswamy Expires September 5, 2007 [Page 20]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
o Responses to the above queries from the outside to the Boundary
Recursive Name Server:
Proto SrcIP SrcPort DestIP DstPort AckBit
UDP Any 53 boundary rec srv >1023 N/A
UDP Any 53 boundary rec srv 53 N/A
TCP Any 53 boundary rec srv >1023 Set
o Queries from outside resolvers to the external-view authoritative
servers:
Proto SrcIP SrcPort DestIP DstPort AckBit
UDP Any >1023 auth serv(ext view) 53 N/A
UDP Any 53 auth serv(ext view) 53 N/A
TCP Any >1023 auth serv(ext view) 53 Any
o Responses to the above queries from the external-view
authoritative server to the outside:
Proto SrcIP SrcPort DestIP DstPort AckBit
UDP auth serv(ext view) 53 Any >1023 N/A
UDP auth serv(ext view) 53 Any 53 N/A
TCP auth serv(ext view) 53 Any >1023 Set
The packet filtering system between the boundary network and the
externally network must finally DROP any DNS packets not covered by
the above rules.
Proto SrcIP SrcPort DestIP DstPort AckBit
UDP Any 53 Any Any N/A
UDP Any Any Any 53 N/A
TCP Any 53 Any Any Any
TCP Any Any Any 53 Any
Krishnaswamy Expires September 5, 2007 [Page 21]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
Author's Address
Suresh Krishnaswamy
SPARTA Inc.
7110 Samuel Morse Dr.
Columbia, MD 21046
US
Email: suresh AT sparta DOT com
URI: http://www.sparta.com
Krishnaswamy Expires September 5, 2007 [Page 22]
Internet-Draft Split-View DNSSEC Operational Practices March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Krishnaswamy Expires September 5, 2007 [Page 23]