[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/