[dnssec-deployment] split-view DNSSEC Best Current Practices
Steve Crocker
steve at shinkuro.com
Wed Jan 12 12:15:06 EST 2005
Suresh,
I look forward to reading this. I was thinking about split views a
couple of days ago and I was thinking it would be very helpful to have a
document that shows how to deploy DNSSEC in such environments, so I'm
very pleased to see this. I see your advice is DON'T. I fear this
won't be enough, and I will read your document eagerly.
Steve
Suresh Krishnaswamy wrote:
>This BCP tries to fill in one of the missing operations/documentation
>pieces for DNSSEC deployment.
>
>The use of split-views is quite pervasive in the Internet today and this
>BCP provides recommendations for what would be the best way to
>configure this setup with DNSSEC also present in the picture
>[short answer = DON'T :)].
>
>I'm planning on sending this as an individual submission to dnsops in the
>near future but I would like to hear your viewpoints on this topic first.
>There's also a set of .ppt slides that I had put together a little while
>earlier, and I'll be happy to share those with anyone who needs them.
>
>Suresh Krishnaswamy
>SPARTA, Inc
>
>------------------------------------------------------------------------
>
>
>
>
>DNS Operations S. Krishnaswamy
>Internet-Draft SPARTA Inc.
>Expires: July 8, 2005 January 7, 2005
>
>
> Split-View DNSSEC Operational Best Practices
> draft-krishnaswamy-dnsop-dnssec-split-view-00.txt
>
>Status of this Memo
>
> This document is an Internet-Draft and is in full conformance with
> all provisions of Section 10 of RFC2026.
>
> 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 July 8, 2005.
>
>Copyright Notice
>
> Copyright (C) The Internet Society (2005). All Rights Reserved.
>
>Abstract
>
> The security extensions to DNS [1] allow for integrity protection
> whereby it is possible to make a determination of the verity of data
> returned from DNS in response to a query. Current operation of the
> DNS 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 seemingly
> conflicting values as in split-view DNSSEC can be construed to be
> mutually conflicting goals. Yet split-view DNSSEC has been shown to
> be possible, albeit with some degree of deployment complexity. This
> document provides recommendations on how enterprises may choose to
> implement split-view DNSSEC if the need for multiple views of data is
> perceived to outweigh the deployment complexity.
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 1]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
>Table of Contents
>
> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
> 3. Recommended DNSSEC split-view configuration . . . . . . . . . 5
> 3.1 No internal validation . . . . . . . . . . . . . . . . . . 7
> 3.2 Same Key Signing . . . . . . . . . . . . . . . . . . . . . 8
> 3.3 Partial Decoupling of chains-of-trust . . . . . . . . . . 9
> 3.4 Complete Decoupling of chains-of-trust . . . . . . . . . . 10
> 3.5 Multiple DS Records . . . . . . . . . . . . . . . . . . . 11
> 4. Name Server Requirements . . . . . . . . . . . . . . . . . . . 12
> 4.1 Internal Recursive Forwarder . . . . . . . . . . . . . . . 12
> 4.2 Second-level Recursive Name Server . . . . . . . . . . . . 12
> 4.3 Authoritative Internal-view Name Servers . . . . . . . . . 12
> 4.4 Authoritative External-view Name Servers . . . . . . . . . 12
> 5. Controlling Errant Queries . . . . . . . . . . . . . . . . . . 12
> 6. Packet Filtering Considerations . . . . . . . . . . . . . . . 13
> 6.1 Inner packet filter . . . . . . . . . . . . . . . . . . . 13
> 6.2 Outer packet filter . . . . . . . . . . . . . . . . . . . 14
> 7. Fragility Considerations for Split-View DNSSEC . . . . . . . . 15
> 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
> 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
> 10. Security Considerations . . . . . . . . . . . . . . . . . . 17
> 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
> 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
> 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
> 12.2 Informative References . . . . . . . . . . . . . . . . . . . 18
> Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
> A. Example Configuration . . . . . . . . . . . . . . . . . . . . 19
> A.1 No validation . . . . . . . . . . . . . . . . . . . . . . 20
> A.2 Same key signing . . . . . . . . . . . . . . . . . . . . . 20
> A.3 Partial Decoupling of chains . . . . . . . . . . . . . . . 21
> A.4 Complete Decoupling of chains . . . . . . . . . . . . . . 21
> A.5 Multiple DS records . . . . . . . . . . . . . . . . . . . 22
> Intellectual Property and Copyright Statements . . . . . . . . 23
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 2]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
>1. Introduction
>
> Split-view DNS is the term used to describe multiple views of DNS
> information for a zone based on where and by whom the query is sent.
> Often, there are only two views for split-view DNS: one internal and
> the other external. Most clients in the external view have no
> knowledge of the contents in the internal view, but internal clients
> may still rely on the external view for looking up most of the
> external names. Some clients in the boundary network (such as MTAs)
> may also need to obtain answers from the internal view in order to
> properly perform their operations.
>
> Although DNS was not originally designed to provide information
> hiding services, the tailoring of DNS to create an internal view of
> information hidden from the outside has proven to be useful to a
> large segment of the Internet community. There are two primary
> reasons given for segmenting a namespace -- 1) to prevent exposure of
> the RFC 1918 private addresses used internally within an organization
> and 2) to prevent exposure of hostnames internal to the organization
> 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 less than adequate. Attack vectors in
> recent Internet exploits have been able to successfully infect
> sensitive 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.
>
> The security extensions to DNS provide for origin authenticity and
> data integrity. These properties are determined by validating the
> chain-of-trust[1] from the signed record to some trusted key
> configured at the end resolver. In the case of split-view DNS each
> of the chains-of-trust in the different views must validate properly.
> Cache pollution is a possibility when data for one view is corrupted
> by data returned from a different view. Also, building a
> chain-of-trust from a trusted key above the split to data in the
> internal view of a zone can be especially problematic, caching
> problems notwithstanding.
>
> The objective of this document is to describe an approach for
> configuring split-view DNSSEC environments with the additional
> requirement that no server be both authoritative and recursive at the
> same time. Separation of authoritative and recursive name servers
> not only provides simple role separation, but is also an important
> security measure in DNS for protecting authoritative name servers
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 3]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> against compromised caches.
>
> Among some of the frequently observed DNS resolution misbehaviour [3]
> 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. This document
> provides recommendations for reducing the impact of errant queries in
> the split-view DNS setup and also makes recommedations for DNS
> related packet-filtering rules required to support the proper
> operation of the suggested configuration.
>
>2. Background
>
> Split-view configurations are possible using one or more name
> servers. Variants of the single name server approach include the
> view-based approach and the data tagging approach. In the former,
> the name server loads multiple zone databases and makes available
> answers from a particular zone based on the origin of the query. The
> second approach tags the data in the database itself as either being
> internally, externally or globally available. Both of these single
> name server approaches are susceptible to leakage of DNS information
> if the host on which they operate is compromised. Confidentiality of
> the namespace is directly tied to how resilient the name server is
> against attacks.
>
> An alternate way to protect a namespace of sensitive hosts from
> remote hosts is to have that entire namespace reside within a private
> delegation. By doing this 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 doing namespace separation. They have the drawback that
> they do not allow for transparency during name resolution; queries
> have to be made for specific names in specific views. The
> split-namespace approach is not the subject of this BCP however; best
> practices for only the split-view configuration are described.
>
> This BCP recommends a split-view configuration using a combination of
> two or more name servers and query forwarding. One name server
> answers queries for the internal view and forwards all requests for
> external data to a second name server. The second name server
> recursively answers queries but only if asked by the first. Other
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 4]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> name servers are configured in such a way so as to decouple the
> functionalities between the authoritative and recursive name servers.
>
>3. Recommended DNSSEC split-view configuration
>
> The DNSSEC concerns for split-view are two-fold -- avoiding cache
> pollution and ensuring that the internal and external chains-of-trust
> validate. Resolving outer data is straightforward since queries
> follow their normative paths. For the internal view, a two level
> recursive server scheme is recommended.
>
> One server functions as a recursive forwarder and is responsible for
> answering all internal queries. This server forwards all queries for
> internal data to their respective authoritative name servers while
> recursively obtaining answers from the outside from a second-level
> name server. The second-level name server is a simple caching name
> server that asks questions from the outside, but only if asked by the
> recursive forwarder. The recursive forwarder and the name servers
> authoritative for the internal data reside in the internal network;
> the second-level recursive name server that is used for returning
> answers from the outside resides within the boundary network.
>
> The two-level recursive scheme controls where queries are directed
> to. Since queries for internal data are sent to authoritative name
> servers which are not also recursive, this scheme also controls where
> data is received from. In this way internal data is kept totally
> separate from external data, thus preventing cache pollution. Figure
> 1 illustrates the above setup.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 5]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> ^ root, TLD servers etc
> | ^ (queries) EXTERNAL NAMESERVERS
> [Outside] | ^ (responses)
> | | |
> v | |
> ------------[O u t e r----P a c k e t---F i l t e r]-------------------
> ^ | |
> | | v (queries)
> | | AUTHORITATIVE EXT-VIEW SERV
> | v (responses)
> [Boundary] RECURSIVE NAMESERVER
> Net ^ (queries from the
> | CLIENTS | recursive forwarder
> | (responses ^ | protected by TSIG)
> | for internal | |
> v data) | |
> ------------[I n n e r----P a c k e t---F i l t e r]-------------------
> ^ | |
> | (queries)| |
> | v v (external data)
> | RECURSIVE FORWARDER <---------> INTERNAL
> [Internal] ^ (internal data) (query/ CLIENT
> | | response)
> | |
> | v
> | AUTHORITATIVE INT-VIEW SERV
> v
>
> Figure 1
>
> It is useful to note that the internal recursive forwarder must not
> attempt to recursively answer queries if the authoritative name
> server for internal-view data fails to respond. If it did so,
> external data could be returned in such circumstances and lead to
> cache pollution. Authoritative internal-view servers that receive
> queries for out-of-bailiwick data must also not send referrals for
> these queries to the root servers for the same reason. Since neither
> the server authoritative for a forwarded zone nor the server doing
> the forwarding can recursively answer queries for delegations from
> that zone, 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.
>
> While validating external data is relatively straightforward, there
> are multiple approaches that can used for validating internal data.
> The method of choice depends on what the threat environment for the
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 6]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> internal view is perceived to be, the amount of end-resolver
> configuration overhead that is needed, the ease of debugging and the
> ability to have administrative separation between the two
> split-views. The configuration overhead at end resolvers is mainly
> associated with the task of defining trust anchors at different
> recursive resolvers. Having fewer keys is desirable in that it makes
> key management easier. It is also desirable to reduce the amount of
> reconfiguration required for mobile nodes when they move between the
> two views of data, while still being able to tie an answer to a
> particular view. The different options for internal data validation
> are further outlined below.
>
>3.1 No internal validation
>
> (No trusted key) parent zone (trusted)
> ^
> |
> |
> split zone split zone
> (internal) (external)
> ^
> |
> |
> sub split zone sub split zone
> (internal) (external)
>
> Figure 2
>
> This is an option if the security requirements for the internal zone
> are more relaxed than the external zone. The threat environment for
> the internal zone in this scenario does not include DNS compromise
> and validation results returned from the internal recursive forwarder
> is not important. The internal recursive forwarder does not have any
> trusted key configured and does not perform any validation.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 7]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
>3.2 Same Key Signing
>
> -----------> parent zone (trusted)
> / ^ ^
> / | |
> / (same key)-->|
> / |
> split zone split zone
> (internal) (external)
> ^ ^
> | |
> | |
> sub split zone sub split zone
> (internal) (external)
>
> Figure 3
>
> In this scenario, a single private key is used to sign both the
> internal and the external zone data. The glue DS and NS records at
> the delegation point of the split zone all correspond to the external
> view data. Validation proceeds by constructing two separate segments
> of the chain-of-trust. In the first segment, data at the level of
> the split and below is validated by constructing a chain-of-trust
> contained entirely within the internal view. If the trusted key is
> configured at or below the level of the split, validation stops at
> this point and queries are never sent to the outer view. If not, a
> second validation chain segment is constructed from the DS record
> covering the split to the trusted key. In forming the second
> validation segment all queries (including the query for the DS record
> of the split zone) are sent to the outer zone. Since the same
> private key is used to sign both views of data, the DS record, even
> though pointing to the key in the outer view of the split zone
> applies to the key in the internal view also, thus completing the
> chain-of-trust.
>
> This approach allows flexibility in choosing the level at which the
> trusted key is configured, with the possibility of the same key being
> used in both views. Although easy to setup, this approach is
> 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. Using the same key also makes difficult any
> administrative separation of the two views of data.
>
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 8]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
>3.3 Partial Decoupling of chains-of-trust
>
> parent zone
>
>
> (trusted) split zone split zone (trusted)
> (internal) (external)
> ^ ^
> | |
> | |
> sub split zone sub split zone
> (internal) (external)
>
> Figure 4
>
> With the DS record in the parent always pointing to a key in the
> outer view, the construction of the chain-of-trust becomes
> problematic when the keys used to sign data in the two views of the
> split are different. The trusted key cannot be defined above the
> level of the split since there would be no way of linking the DS
> record in the outer zone to the apex DNSKEY set in the internal view
> of the split zone.
>
> A simple solution is to configure the trusted key at the level of the
> split such that the chains-of-trust for the internal and external
> zones share no common records that might cause any ambiguity.
>
> Having separate keys for the two views of data is useful for
> troubleshooting and in determining which view a given record belongs
> to. This configuration however involves more configuration overhead
> since trusted keys need to be configured for every zone that is
> split. This problem is more pronounced when dealing with validating
> stub resolvers on mobile nodes, where moving between the internal and
> external views would involve constant reconfiguration of all of these
> trusted keys.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 9]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
>3.4 Complete Decoupling of chains-of-trust
>
> (trusted) parent zone parent zone (trusted)
> (internal) (external)
> ^ ^
> | |
> | |
> split zone split zone
> (internal) (external)
> ^ ^
> | |
> | |
> sub split zone sub split zone
> (internal) (external)
>
> Figure 5
>
> One problem with Section 3.3 is that trusted keys need to be
> configured for every zone that is split under the parent. An option
> to circumvent this is to split the parent also, and configure the
> trusted key at the level of the parent. An internal name server is
> configured as the authoritative server for the internal view of this
> split and the internal recursive forwarder is modified to forward all
> internal queries for the parent zone to it.
>
> Although this option reduces the number of trusted keys at the end
> resolver, the trusted key still needs to change when moving between
> the two views. Since splitting the parent essentially creates two
> new zones, records in the parent that were previously common in both
> views would now need to be duplicated in the two split zones. The
> number of such records is typically not very large, but the overhead
> and complexity in maintaining duplicate records can still be a
> burden.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 10]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
>3.5 Multiple DS Records
>
> -----------> parent zone (trusted)
> / (DS1) ^
> / |
> / | (DS2)
> / |
> split zone split zone
> (internal) (external)
> ^ ^
> | |
> | |
> sub split zone sub split zone
> (internal) (external)
>
> Figure 6
>
> In this approach, the parent is not split; however, DS records
> corresponding to each of the two different views are published at the
> delegation point. The glue and NS records at the delegation point
> still corresponds to the external zone but this information is never
> used by the internal zone. As in option 4, the trusted key is
> configured at the level of the parent zone. The chain-of-trust from
> this trusted key to either zone is formed by using one of the two DS
> records, which ever is applicable at that view.
>
> Since some coordination between the split zone and the parent is
> required to publish multiple DS records, this approach is most
> suitable when the split is made at a level lower than the zone apex
> (e.g. for example.com, the split is made at a level lower than
> example.com). This approach lends itself to using different keys in
> different views while still allowing for minimal configuration at the
> end resolvers; trusted keys need not be changed even if the nodes are
> mobile across the two views. This approach has the advantage that
> administrative separation of the two views of the split can be
> maintained while still having a single key configured at the end
> resolvers. Identifying which view a given record belongs to can be
> done by tracing back the keys used to form the chain-of-trust.
>
> While most of the internal zone contents can be kept private to the
> internal view, the DS record must still be exposed. An attendent
> problem with multiple DS records is that since the validation
> algorithm iteratively looks for a DS record in the parent while
> completing the chain-of-trust there is some added computational
> overhead which increases as the number of DS records in the
> delegation point grows. Lastly, the internal view is still
> susceptible to an insider "attack", where data from the outside view
> injected in response to internal queries can corrupt the cache. This
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 11]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> attack is common to all scenarios that use a common key for
> validating internal and external zone contents.
>
>4. Name Server Requirements
>
> This section summarizes the list of requirements for the various name
> servers involved in the split-view configuration. All name servers
> listed below must conform to the specifications given in [2].
>
>4.1 Internal Recursive Forwarder
>
> o Ability to forward queries to specific destinations.
> o Ability to control forwarding behaviour such that the recursive
> option is not tried, even if the name server that queries are
> normally forwarded to fails to respond.
> o Ability to recursively answer queries.
> o Ability to protect the integrity of messages using TSIG for
> selected destinations.
> o Ability to validate DNSSEC responses.
> o Support for configurable DNSSEC trusted keys. It should be
> possible to configure more than one trusted key.
>
>4.2 Second-level Recursive Name Server
>
> o Ability to recursively answer queries.
> o Ability to authenticate messages using TSIG.
> o Ability to filter incoming queries based on the TSIG key used to
> protect the message.
>
>4.3 Authoritative Internal-view Name Servers
>
> o Ability to authoritatively answer queries for a zone.
> o Ability to disable all recursive behaviour.
>
>4.4 Authoritative External-view Name Servers
>
> o Ability to authoritatively answer queries for a zone.
> o Ability to disable all recursive behaviour.
>
>5. Controlling Errant Queries
>
> DNS queries that are sent from the internal recursive forwarder to
> the outside should only be directed towards the second-level
> recursive name server. Since the second-level name server has no
> knowledge of internal-view data, internal resolvers must not use it
> directly for resolving queries. Only properly configured internal
> recursive forwarders must be approved to send queries to this name
> server and solely for the purpose of resolving external answers. It
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 12]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> is conceivable that there are multiple approved name servers sending
> queries to the second-level name server and TSIG is the recommeded
> method for controlling which name servers can send these queries.
> Having these rules alternatively configured in the packet filter is
> also possible, but using TSIG for performing this authorization eases
> packet filter administration for DNS.
>
>6. Packet Filtering Considerations
>
> [Note: This section assumes the availability of a stateful packet
> filter.]
>
> 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.
>
>6.1 Inner packet filter
>
> In order to allow the above configuration to work, any packet
> filtering system between the internal network and the boundary
> network must allow all of the following types of packets.
>
> DNS queries from any internal server to the second-level recursive
> name server (Finer level access control is done by TSIG):
>
>
> Proto SrcIP SrcPort DestIP DstPort AckBit
> UDP internal >1023 rec.srv 53 N/A
> UDP internal 53 rec.srv 53 N/A
> TCP internal >1023 rec.srv 53 Any
>
>
> Other queries originating from internal servers but not destined to
> the second-level recursive name server must be denied.
>
> Responses to the above queries from the second-level recursive name
> server to any internal server:
>
>
> Proto SrcIP SrcPort DestIP DstPort AckBit
> UDP rec.srv 53 internal >1023 N/A
> UDP rec.srv 53 internal 53 N/A
> TCP rec.srv 53 internal >1023 Set
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 13]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> Queries from clients in the boundary network to any internal name
> server:
>
>
> Proto SrcIP SrcPort DestIP DstPort AckBit
> UDP client >1023 internal 53 N/A
> TCP client >1023 internal 53 Any
>
>
> Responses to the above queries from the (any) recursive forwarder to
> clients in the boundary network:
>
>
> Proto SrcIP SrcPort DestIP DstPort AckBit
> UDP internal 53 client >1023 N/A
> TCP internal 53 client >1023 Set
>
>
>
>6.2 Outer packet filter
>
> Any packet filtering system configured between the boundary network
> and the external network needs to allow the following.
>
> Queries from the recursive name server in the boundary network to the
> outside network:
>
>
> Proto SrcIP SrcPort DestIP DstPort AckBit
> UDP rec.srv >1023 outside 53 N/A
> UDP rec.srv 53 outside 53 N/A
> TCP rec.srv >1023 outside 53 Any
>
>
> Responses to the above queries from the outside to the boundary
> network recursive name server:
>
>
> Proto SrcIP SrcPort DestIP DstPort AckBit
> UDP outside 53 rec.srv >1023 N/A
> UDP outside 53 rec.srv 53 N/A
> TCP outside 53 rec.srv >1023 Set
>
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 14]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> Queries from outside clients to the external-view authoritative
> servers:
>
>
> Proto SrcIP SrcPort DestIP DstPort AckBit
> UDP outside >1023 auth.serv(ext view) 53 N/A
> UDP outside 53 auth.serv(ext view) 53 N/A
> TCP outside >1023 auth.serv(ext view) 53 Any
>
>
> 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 outside >1023 N/A
> UDP auth.serv(ext view) 53 outside 53 N/A
> TCP auth.serv(ext view) 53 outside >1023 Set
>
>
> Note that in this configuration, queries from all recursive name
> servers in the boundary network for any external view information
> would need to transit outward through the second-level packet filter
> and then back again into the boundary network. If the existing
> packet filter policy prevents such traffic patterns, all such
> recursive name servers would need additional forwarding statements to
> forward these queries directly to their respective authoritative name
> servers without going through the packet filter.
>
>7. Fragility Considerations for Split-View DNSSEC
>
> Besides the two packet filters, there are four different types of
> name servers (Section 4) that must be separately configured for
> split-view DNSSEC. It becomes increasingly difficult to ensure that
> the split-view configuration remains operationally viable as changes
> are made in the network around it. Some of the common ways in which
> split-views can be mis-configured are summarized below. Section 10
> further details the security ramifications of these mis-steps.
>
> o Glue at the delegation point in the parent zone is for the
> internal view instead of the external view.
> o The DS record at the delegation point are for the wrong view.
> o Trusted keys at end resolvers have been configured for the wrong
> view.
> o Trusted keys have not been re-configured at validating
> stub-resolvers that transit between the internal and external
> views.
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 15]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> o The second-level recursive forwarder is not configured to properly
> recognize queries sent by unauthorized internal clients.
> o The packet filter between the internal network and the boundary
> network does not guard against errant queries sent by authorized
> name servers (queries that follow referrals sent by an
> authoritative internal view server for out-of-bailiwick data).
> o The packet filter configuration disallows traffic patterns that
> are followed by some legitimate queries.
> o Internal recursive forwarders are not configured to turn-off
> recursive query processing when the authoritative name server for
> internal-view data fails to respond.
>
> The above list illustrates how fragile the split-view setup is and
> how easy it is to break the configuration. Because of the lack of
> robustness, the gain associated with implementing split-view DNSSEC
> is sometimes not worth the pain involved in administering it. In
> cases where name hiding is the main objective, the split-namespace
> approach, wherein all sensitive names are placed under a private
> delegation, provides the best solution. In cases where split-view is
> seen as a necessary component of a defense-in-depth solution it is
> strongly recommended that one follow the configuration suggested in
> this BCP in order to minimize the possibility of cache pollution and
> information leakage.
>
>8. Summary
>
> This document describes an approach for performing split-view DNSSEC.
> The approach uses a two level recursive scheme where an internal
> recursive forwarder resolves inside answers and marshalls all outside
> queries to a second-level recursive name server. TSIG between the
> internal and the second-level name servers protects against errant
> queries.
>
> The recommended configuration has been shown to be adjustable for
> various needs and security consideration levels. Differences in
> these approaches make 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 nodes
> that are mobile across the two views.
>
> Although split-view DNSSEC is possible using the setup recommended by
> this BCP, it still involves significant effort: for configuring the
> various name servers, for setting up zone forwarding, for configuring
> and distributing shared keys for TSIG, and, depending on the
> configuration, for performing DS (or keyset) exchanges for every view
> of a split zone. Some configurations may also require multiple
> trusted keys in end resolvers which may change between views. It is
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 16]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> very easy to introduce errors while making these configuration
> changes and proper care must be taken to ensure that correct
> split-view behavior is consistently maintained.
>
>9. IANA Considerations
>
> This document has no actions for IANA.
>
>10. Security Considerations
>
> Since the second-level name server has no knowledge of internal view
> data, internal resolvers must not use it directly for resolving
> queries. Only properly configured internal recursive forwarders must
> be approved to send queries to this name server and solely for the
> purpose of resolving external answers. DNS queries that are sent
> from the internal view name servers to the outside should only be
> destined to the second-level name server.
>
> Additionally, the internal recursive forwarder must not attempt to
> recursively answer queries if the authoritative name server for
> internal-view data fails to respond. If it did so, external data
> could be returned in such circumstances and lead to cache pollution.
> Authoritative internal-view servers that receive queries for
> out-of-bailiwick data must also not send referrals for these queries
> to the root servers for the same reason.
>
> The above is quick reminder for the different ways in which it is
> possible to incorrectly configure the split-view DNS setup. These
> misconfigurations can either pollute the cache or impede the ability
> for end resolvers to validate data returned in response to queries.
> DNSSEC trusted key configuration for every split zone have the
> additonal overhead of key management and parent-child interactions to
> communicate the secure entry point into the child zone. An
> improperly configured packet filter that allows errant DNS traffic
> through or denies legitimate responses can completely invalidate the
> split-view environment or cause aggressive retransmission of queries.
>
> Each of the validation options outlined in Section 3 introduce their
> own security considerations. 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. All
> approaches that use a common key for validating internal and external
> data are also susceptible to an insider attack where data from the
> outside view injected in response to internal queries can corrupt the
> cache. On the other hand, using a multitude of keys at end resolvers
> only increases the chances for configuration errors and operator
> overhead during parent-child communication of secure entry points.
> Although the multiple-DS approach deos offer some balance between
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 17]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> cost of validation and maintainability, it may not always be possible
> for the parent to publish all DS records that the child sends --
> either due to organizational arrangement or as a matter of privacy.
>
>11. Acknowledgements
>
> The contributions, suggestions and remarks of the following persons
> to this draft are particularly acknowledged: Wesley Griffin, John
> Kelley, Russ Mundy and Sam Weiler. The two-level name server scheme
> described in this BCP builds upon work that was originally performed
> by Ed Lewis.
>
>12. References
>
>12.1 Normative References
>
> [1] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
> "DNS Security Introduction and Requirements", Internet Draft
> ietf-dnsext-dnssec-intro, October 2004.
>
> [2] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
> "Protocol Modifications for the DNS Security Extensions",
> Internet Draft ietf-dnsext-dnssec-proto, October 2004.
>
>12.2 Informative References
>
> [3] Larson, M. and P. Barber, "Observed DNS Resolution Misbehavior",
> Internet Draft ietf-dnsop-bad-dns-res, July 2004.
>
>
>Author's Address
>
> Suresh Krishnaswamy
> SPARTA Inc.
> 7075 Samuel Morse Dr.
> Columbia, MD 21046
> US
>
> EMail: suresh at tislabs.com
> URI: http://www.sparta.com
>
>
>
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 18]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
>Appendix A. Example Configuration
>
> ^ root, com.
> | name servers
> | ^
> [Outside] |
> | +<-- -- -- -- -- -+
> v | |
> ------------[O u t e r----P a c k e t---F i l t e r--------------------
> ^ | |
> | | v
> | | 10.0.0.1
> | v example.com
> [10.0.0.0/8] RECURSIVE NAMESERVER sub.example.com(ext)
> | (10.0.0.2)
> | CLIENT (10.0.0.3) ^
> | ^ |
> v | |
> ------------[I n n e r----P a c k e t---F i l t e r--------------------
> ^ | |
> | v v
> | INT RECURSIVE FORWARDER <---------> 192.168.2.3
> | (192.168.2.2)
> [192.168.0.0/16] ^
> | |
> | v
> | 192.168.2.1
> v sub.example.com(int)
>
> Figure 15
>
> Consider a fictitious domain "example.com" containing a delegation
> "sub.example.com", which is split into an internal (int) and an
> external view (ext). The name servers authoritative for the internal
> view data are located in the 192.168.0.0/16 network while the name
> servers authoritative for the external view is located in the
> boundary network (10.0.0.0/8). The name server at 10.0.0.1 is
> authoritative for both the example.com zone and the external view of
> sub.example.com. 10.0.0.3 is a DNS client configured to directly
> query the recursive forwarder at 192.168.2.1 for internal-view data.
>
> [Note: while the above example lists example.com as residing with an
> RFC-1918 private-address space, in real-world situations, the
> boundary network would normally reside in a publically routable
> address space.]
>
> The internal recursive forwarder 192.168.2.2 is configured to forward
> all queries for sub.example.com to the name server at 192.168.2.1
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 19]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> (which is authoritative for the inner view of this zone) and forwards
> all other queries to the recursive server at 10.0.0.2. Communication
> between 192.168.2.2 and 10.0.0.2 is protected using TSIG. 10.0.0.2
> is configured to only answer those queries that are protected using
> the TSIG key that it shares with 192.168.2.2.
>
> The packet filter between the internal network and boundary network
> only allows DNS queries from the internal network destined to
> 10.0.0.2, queries from 10.0.0.3 to the internal name servers and
> their corresponding responses, and denies all other DNS traffic. The
> packet filter between the external network and the boundary network
> allows all outbound queries from 10.0.0.2, all inbound queries to
> 10.0.0.1 and their respective responses while disallowing all other
> DNS traffic. There are no rules that affect forward and reverse
> traffic that result from queries that are sent by clients in the
> boundary network to authoritative external view name servers.
>
> Unless stated otherwise, the "example." zone is assumed to contain
> the following delegation and glue:
>
> sub.example.com NS serv.sub.example.com
> serv.sub.example.com A 10.0.0.1
>
> The following subsections trace the query and response flow that
> occurs in order to validate the query "a.sub.example.com/A"
> originating at a client on 192.168.2.3 and directed at 192.168.2.2,
> for each of the different approaches outlined in Section 3.
>
>A.1 No validation
>
> 192.168.2.2 forwards the query to the authoritative internal-view
> name server (192.168.2.1), which returns an authoritative answer. No
> trusted key is configured at 192.168.2.2 so no validation of this
> response is done. The answer is returned to the client at
> 192.168.2.3 without any validation.
>
>A.2 Same key signing
>
> The example.com/DNSKEY record is configured as a trusted key at
> 192.168.2.2 and forms one end of the chain-of-trust. The delegations
> sub.example.com(ext) and sub.example.com(int) are signed using the
> same key; the DS record in example.com points to this key.
>
> The answer for a.sub.example.com/A is returned from 192.168.2.1 as
> described in the previous section. 192.168.2.2 is able to build the
> chain-of-trust for a.sub.example.com/A from the following additional
> data -- sub.example.com/DNSKEY, sub.example.com/DS and
> example.com/DNSKEY.
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 20]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> The query for sub.example.com/DNSKEY is forwarded to the
> authoritative server at 192.168.2.1. Since sub.example.com/DS and
> example.com/DNSKEY are both external-view data, queries for them are
> forwarded by 192.168.2.2 to the second-level recursive server at
> 10.0.0.2.
>
> 192.168.2.2 determines the final answer based on all received
> responses and returns this to the client at 192.168.2.3.
>
>A.3 Partial Decoupling of chains
>
> The sub.example.com/DNSKEY (internal) record is configured as a
> trusted key at 192.168.2.2 and forms one end of the chain-of-trust.
>
> The answer for a.sub.example.com/A is returned from 192.168.2.1 as
> described in the previous section. In order to complete the
> chain-of-trust for a.sub.example.com/A, 192.168.2.2 only needs to
> fetch the data for sub.example.com/DNSKEY.
>
> It does this according to its forwarding rules by sending a query
> directly to the authoritative server for this data at 192.168.2.1,
> before finally returning the answer to the client at 192.168.2.3.
>
>A.4 Complete Decoupling of chains
>
> In this option, example.com is also split into an internal and
> external view.
>
> [Note: For this sub-section, the name server at 192.168.2.1 is
> assumed to be authoritative for example.com(int) in addition to
> sub.example.com(int).
>
> The delegation point for sub.example.com at example.com(int) is also
> assumed to contain glue that points to the name server at
> 192.168.2.1.
>
> sub.example.com NS serv.sub.example.com
> serv.sub.example.com A 192.168.2.1
>
> The delegation point for sub.example.com at example.com(ext) contains
> glue that points to the name server at 10.0.0.1 and does not change.]
>
> The configuration at 192.168.2.2 is modified to include a rule to
> forward queries for all data under example.com to 192.168.2.1, which
> is the name server authoritative for the internal view of this zone.
> The trusted key for both views of data is configured at the level of
> example.com but the exact key is different for the internal and the
> external view. The internal example.com/DNSKEY record is configured
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 21]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> as the trusted key at 192.168.2.2 and forms one end of the
> chain-of-trust.
>
> The answer for a.sub.example.com/A is returned from 192.168.2.1 as
> before. In order to complete the chain-of-trust for
> a.sub.example.com/A, 192.168.2.2 validates the following data in
> succession -- sub.example.com/DNSKEY, sub.example.com/DS and
> example.com/DNSKEY. All of these queries are sent according to the
> forwarding rules in 192.168.2.2 to 192.168.2.1, which is the
> authoritative server for all of them.
>
> 192.168.2.2 determines the final answer based on all received
> responses and sends this to the client at 192.168.2.3.
>
>A.5 Multiple DS records
>
> sub.example.com(int) and sub.example.com(ext) are signed using
> different keys. The corresponding DS records are both present in
> example.com, which is not split. The trusted key is at the level of
> example.com and is the same for both views. This is configured as
> the trusted key at 192.168.2.2 and forms one end of the
> chain-of-trust.
>
> The answer to a.sub.example.com/A is returned from 192.168.2.1 as
> before. In order to complete the chain-of-trust for
> a.sub.example.com/A, 192.168.2.2 validates the following data in
> succession -- sub.example.com/DNSKEY, sub.example.com/DS and
> example.com/DNSKEY.
>
> The query for sub.example.com/DNSKEY is forwarded to the
> authoritative server at 192.168.2.1 while the the queries for
> sub.example.com/DS and example.com/DNSKEY are sent to the external
> recursive server at 10.0.0.2.
>
> In constructing the chain-of-trust, the recursive server at
> 192.168.2.2 iteratively checks each DS record returned from the
> sub.example.com/DS and uses the one that successfully completes the
> chain for sub.example.com/DNSKEY (internal). 192.168.2.2 determines
> the final answer based on all reveived responses and sends this to
> the client at 192.168.2.3.
>
>
>
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 22]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
>Intellectual Property Statement
>
> The IETF takes no position regarding the validity or scope of any
> intellectual property 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; neither does it represent that it
> has made any effort to identify any such rights. Information on the
> IETF's procedures with respect to rights in standards-track and
> standards-related documentation can be found in BCP-11. Copies of
> claims of rights made available for publication 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 implementors or users of this specification can
> be obtained from the IETF Secretariat.
>
> The IETF invites any interested party to bring to its attention any
> copyrights, patents or patent applications, or other proprietary
> rights which may cover technology that may be required to practice
> this standard. Please address the information to the IETF Executive
> Director.
>
>
>Full Copyright Statement
>
> Copyright (C) The Internet Society (2005). All Rights Reserved.
>
> This document and translations of it may be copied and furnished to
> others, and derivative works that comment on or otherwise explain it
> or assist in its implementation may be prepared, copied, published
> and distributed, in whole or in part, without restriction of any
> kind, provided that the above copyright notice and this paragraph are
> included on all such copies and derivative works. However, this
> document itself may not be modified in any way, such as by removing
> the copyright notice or references to the Internet Society or other
> Internet organizations, except as needed for the purpose of
> developing Internet standards in which case the procedures for
> copyrights defined in the Internet Standards process must be
> followed, or as required to translate it into languages other than
> English.
>
> The limited permissions granted above are perpetual and will not be
> revoked by the Internet Society or its successors or assignees.
>
> This document and the information contained herein is provided on an
> "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
> TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
> BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 23]
>
>Internet-Draft Split-View DNSSEC Operational Best Practices January 2005
>
>
> HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
> MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>Acknowledgment
>
> Funding for the RFC Editor function is currently provided by the
> Internet Society.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Krishnaswamy Expires July 8, 2005 [Page 24]
>
>
>
>
>------------------------------------------------------------------------
>
>#############################################################
>This message is sent to you because you are subscribed to
> the mailing list <dnssec-deployment at shinkuro.com>.
>To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
>To switch to the DIGEST mode, E-mail to <dnssec-deployment-digest at shinkuro.com>
>To switch to the INDEX mode, E-mail to <dnssec-deployment-index at shinkuro.com>
>Send administrative queries to <dnssec-deployment-request at shinkuro.com>
>
>
More information about the Dnssec-deployment
mailing list