< draft-ietf-mif-dns-server-selection-11.txt   draft-ietf-mif-dns-server-selection-12.txt >
Internet Engineering Task Force T. Savolainen Internet Engineering Task Force T. Savolainen
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track J. Kato Intended status: Standards Track J. Kato
Expires: February 2, 2013 NTT Expires: February 2, 2013 NTT
T. Lemon T. Lemon
Nominum, Inc. Nominum, Inc.
Aug 2012 Aug 2012
Improved Recursive DNS Server Selection for Multi-Interfaced Nodes Improved Recursive DNS Server Selection for Multi-Interfaced Nodes
draft-ietf-mif-dns-server-selection-11 draft-ietf-mif-dns-server-selection-12
Abstract Abstract
A multi-interfaced node is connected to multiple networks, some of A multi-interfaced node is connected to multiple networks, some of
which might be utilizing private DNS namespaces. A node commonly which might be utilizing private DNS namespaces. A node commonly
receives recursive DNS server configuration information from all receives recursive DNS server configuration information from all
connected networks. Some of the recursive DNS servers might have connected networks. Some of the recursive DNS servers might have
information about namespaces other servers do not have. When a information about namespaces other servers do not have. When a
multi-interfaced node needs to utilize DNS, the node has to choose multi-interfaced node needs to utilize DNS, the node has to choose
which of the recursive DNS servers to use. This document describes which of the recursive DNS servers to use. This document describes
skipping to change at page 3, line 28 skipping to change at page 3, line 28
4. Improved RDNSS Selection . . . . . . . . . . . . . . . . . . . 10 4. Improved RDNSS Selection . . . . . . . . . . . . . . . . . . . 10
4.1. Procedure for Prioritizing RDNSSes and Handling 4.1. Procedure for Prioritizing RDNSSes and Handling
Responses . . . . . . . . . . . . . . . . . . . . . . . . 10 Responses . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. RDNSS Selection DHCPv6 Option . . . . . . . . . . . . . . 12 4.2. RDNSS Selection DHCPv6 Option . . . . . . . . . . . . . . 12
4.3. RDNSS Selection DHCPv4 Option . . . . . . . . . . . . . . 15 4.3. RDNSS Selection DHCPv4 Option . . . . . . . . . . . . . . 15
4.4. Scalability Considerations . . . . . . . . . . . . . . . . 17 4.4. Scalability Considerations . . . . . . . . . . . . . . . . 17
4.5. Limitations on Use . . . . . . . . . . . . . . . . . . . . 17 4.5. Limitations on Use . . . . . . . . . . . . . . . . . . . . 17
4.6. Coexistence of Various RDNSS Configuration Tools . . . . . 17 4.6. Coexistence of Various RDNSS Configuration Tools . . . . . 17
4.7. Considerations on Follow-Up Queries . . . . . . . . . . . 18 4.7. Considerations on Follow-Up Queries . . . . . . . . . . . 18
4.8. Closing Network Interfaces and Local Caches . . . . . . . 18 4.8. Closing Network Interfaces and Local Caches . . . . . . . 18
5. Example of a Node Behavior . . . . . . . . . . . . . . . . . . 18 5. Example of a Node Behavior . . . . . . . . . . . . . . . . . . 19
6. Considerations for Network Administrators . . . . . . . . . . 21 6. Considerations for Network Administrators . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Attack vectors . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Attack vectors . . . . . . . . . . . . . . . . . . . . . . 22
9.2. Trust levels of Network Interfaces . . . . . . . . . . . . 22 9.2. Trust levels of Network Interfaces . . . . . . . . . . . . 22
9.3. Importance of Following the Algorithm . . . . . . . . . . 23 9.3. Importance of Following the Algorithm . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Possible Alternative Practices for RDNSS Selection . 24 Appendix A. Possible Alternative Practices for RDNSS Selection . 24
A.1. Sending Queries Out on Multiple Interfaces in Parallel . . 24 A.1. Sending Queries Out on Multiple Interfaces in Parallel . . 25
A.2. Search List Option for DNS Forward Lookup Decisions . . . 25 A.2. Search List Option for DNS Forward Lookup Decisions . . . 25
A.3. More Specific Routes for Reverse Lookup Decisions . . . . 25 A.3. More Specific Routes for Reverse Lookup Decisions . . . . 25
A.4. Longest Matching Prefix for Reverse Lookup Decisions . . . 25 A.4. Longest Matching Prefix for Reverse Lookup Decisions . . . 26
Appendix B. DNSSEC and Multiple Answers Validating with Appendix B. DNSSEC and Multiple Answers Validating with
Different Trust Anchors . . . . . . . . . . . . . . . 26 Different Trust Anchors . . . . . . . . . . . . . . . 26
Appendix C. Pseudo Code for RDNSS Selection . . . . . . . . . . . 26 Appendix C. Pseudo Code for RDNSS Selection . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
A multi-interfaced node faces several problems a single-homed node A multi-interfaced node faces several problems a single-homed node
does not encounter, as is described in [RFC6418]. This document does not encounter, as is described in [RFC6418]. This document
studies in detail the problems private namespaces might cause for studies in detail the problems private namespaces might cause for
skipping to change at page 17, line 15 skipping to change at page 17, line 15
4.4. Scalability Considerations 4.4. Scalability Considerations
The general size limitations of the DHCP messages limit the number of The general size limitations of the DHCP messages limit the number of
domains and networks that can be carried inside of these RDNSS domains and networks that can be carried inside of these RDNSS
selection options. The DHCP options for RDNSS selection are best selection options. The DHCP options for RDNSS selection are best
suited for those deployments where relatively few and carefully suited for those deployments where relatively few and carefully
selected domains and networks are enough. selected domains and networks are enough.
4.5. Limitations on Use 4.5. Limitations on Use
Use of OPTION_DNS_SERVER_SELECT is ideal in the following The option OPTION_DNS_SERVER_SELECT SHOULD NOT be enabled by default.
environments, but SHOULD NOT be enabled by default otherwise: The option can be used in the following environments:
1. The RDNSS selection option is delivered across a secure, trusted 1. The RDNSS selection option is delivered across a secure, trusted
channel. channel.
2. The RDNSS selection option is not secured, but the client on a 2. The RDNSS selection option is not secured, but the client on a
node does DNSSEC validation. node does DNSSEC validation.
3. The RDNSS selection option is not secured, the resolver does 3. The RDNSS selection option is not secured, the resolver does
DNSSEC validation, and the client communicates with the resolver DNSSEC validation, and the client communicates with the resolver
configured with RDNSS selection option over a secure, trusted configured with RDNSS selection option over a secure, trusted
channel. channel.
4. The IP address of RDNSS that is being recommended in the RDNSS 4. The IP address of RDNSS that is being recommended in the RDNSS
selection option is known and trusted by the client; that is, the selection option is known and trusted by the client; that is, the
RDNSS selection option serves not to introduce the client to a new RDNSS selection option serves not to introduce the client to a new
RDNSS, but rather to inform it that RDNSS it has already been RDNSS, but rather to inform it that RDNSS it has already been
configured to trust is available to it for resolving certain domains. configured to trust is available to it for resolving certain domains.
As the DHCP by itself cannot tell whether it is using secure, trusted
channel, or whether the client on a node is performing DNSSEC
validation, this option cannot be used without being explicitly
enabled. The functionality can be enabled for an interface via
administrative means, such as by provisioning tools or manual
configuration. Furthermore, the functionality can be automatically
enabled by a client on a node that knows it is performing DNSSEC
validation, or by a node that is configured or hard-coded to trust
certain interfaces (see Section 9.2).
4.6. Coexistence of Various RDNSS Configuration Tools 4.6. Coexistence of Various RDNSS Configuration Tools
The DHCPv4 and DHCPv6 OPTION_DNS_SERVER_SELECT options are designed The DHCPv4 and DHCPv6 OPTION_DNS_SERVER_SELECT options are designed
to coexist between each other and with other tools used for RDNSS to coexist between each other and with other tools used for RDNSS
address configuration. address configuration.
For RDNSS selection purposes information received from all tools MUST For RDNSS selection purposes information received from all tools MUST
be combined together into a single list, as discussed in Section 4.1. be combined together into a single list, as discussed in Section 4.1.
It can happen that the DHCPv4 and the DHCPv6 are providing It can happen that the DHCPv4 and the DHCPv6 are providing
 End of changes. 8 change blocks. 
8 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/