Internet Engineering Task Force T. Savolainen
Internet-Draft Nokia
Intended status: Standards Track J. Kato
Expires: September 12, 2011 NTT
March 11, 2011
Improved DNS Server Selection for Multi-Homed Nodes
draft-ietf-mif-dns-server-selection-01
Abstract
A multi-homed node can be connected to multiple networks that may
utilize different DNS namespaces. The node commonly receives DNS
server configuration information from all connected networks. Some
of the DNS servers may have information about namespaces other
servers do not have. When the multi-homed node needs to utilize DNS,
it has to choose which of the servers to contact to. This document
describes a policy based method for helping on selection of DNS
server, for both forward and reverse DNS lookup procedures, with help
of DNS suffix and IPv6 prefix information received via DHCPv6.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 12, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Savolainen & Kato Expires September 12, 2011 [Page 1]
Internet-Draft MIF and DNS server selection March 2011
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Problem description for local namespaces with multi-homed
nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Fully qualified domain names with limited scopes . . . . . 4
2.2. Network interface specific IP addresses . . . . . . . . . 5
2.3. A problem not fully solved by the described solution . . . 6
3. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 6
3.1. CPE deployment scenario . . . . . . . . . . . . . . . . . 7
3.2. Cellular network scenario . . . . . . . . . . . . . . . . 7
3.3. VPN scenario . . . . . . . . . . . . . . . . . . . . . . . 7
4. Improved DNS server selection . . . . . . . . . . . . . . . . 8
4.1. Procedure for prioritizing DNS servers and handling
responses . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. DNS server selection option . . . . . . . . . . . . . . . 10
4.3. Coexistence with RFC3646 . . . . . . . . . . . . . . . . . 13
4.4. Interactions with OPTION_DOMAIN_LIST . . . . . . . . . . . 13
4.5. CNAME/DNAME record considerations . . . . . . . . . . . . 13
5. Example of a node behavior . . . . . . . . . . . . . . . . . . 14
6. Scalability considerations . . . . . . . . . . . . . . . . . . 16
7. Considerations for network administrators . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Best Current Practice for DNS server selection . . . 19
A.1. Sending queries out on multiple interfaces in parallel . . 19
A.2. Search list option for DNS forward lookup decisions . . . 20
A.3. More specific routes for reverse lookup decision . . . . . 20
A.4. Longest matching prefix for reverse lookup decision . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Savolainen & Kato Expires September 12, 2011 [Page 2]
Internet-Draft MIF and DNS server selection March 2011
1. Introduction
A multi-homed node faces several problems a single-homed node does
not encounter, as is described in [I-D.ietf-mif-problem-statement].
This document studies in detail the problems local namespaces may
cause for multi-homed nodes and provides a solution for IPv6 domain.
The node may be implemented as a host or as a router.
When multiple namespaces are visible for a node, some DNS servers
have information other servers do not have. Because of that, a
multi-homed node cannot assume every DNS server is able to properly
answer for any query, but instead the node must be able to ask right
server for the information it needs.
An example of an application that benefits from multi-homing is a web
browser that commonly accesses many different destinations and needs
to be able to dynamically communicate over different network
interfaces.
In deployments where multiple namespaces are present, selection of
correct route and destination and source addresses for the actual IP
connection is crucial as well, as the resolved destination's IP
addresses may be only usable on the network interface over which the
name was resolved on. Hence solution described in this document is
assumed to be commonly used in combination with tools for delivering
additional routing and source and destination address selection
policies.
The Appendix A describes best current practices possible with tools
preceding this document and on networks not supporting the solution
described in this document. As it is possible to solve the problem
with less efficient and less explicit manners, the new solution may
be considered as an optimization. However, in some environments this
solution is considered essential.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Problem description for local namespaces with multi-homed nodes
This chapter describes two host multi-homing related local namespace
scenarios for which the procedure described in chapter 3 provides a
solution for. Essentially the same challenges may be faced by
Consumer Premises Equipment as is described in
Savolainen & Kato Expires September 12, 2011 [Page 3]
Internet-Draft MIF and DNS server selection March 2011
[I-D.ietf-v6ops-multihoming-without-nat66]. This chapter
additionally describes a related problem for which this document
provides only partial solution.
2.1. Fully qualified domain names with limited scopes
A multi-homed node may be connected to one or more networks that are
using local namespaces. As an example, the node may have
simultaneously open a wireless LAN (WLAN) connection to the public
Internet, cellular connection to an operator network, and a virtual
private network (VPN) connection to a corporate network. When an
application initiates a connection establishment to an FQDN, the host
needs to be able to choose the right DNS server for making a
successful DNS query. This is illustrated in the figure 1. An FQDN
for a public name can be usually resolved with any DNS server, but
for an FQDN of corporation's or operator's service's local name the
node needs to be able to correctly select the right DNS server for
the DNS resolution, i.e. do also network interface selection already
before destination's IP address is known.
+---------------+
| DNS server w/ | | Corporate
+------+ | public + |----| Intranet
| | | corporation's | |
| |===== VPN =======| local names | |
| | +---------------+ +----+
| MIF | | FW |
| node | +----+
| | +---------------+ |
| |----- WLAN ------| DNS server w/ |----| Public
| | | public names | | Internet
| | +---------------+ +----+
| | | FW |
| | +---------------+ +----+
| |---- cellular ---| DNS server w/ | |
+------+ | public + | | Operator
| operator's |----| Intranet
| local names | |
+---------------+
Local DNS namespaces illustrated
Figure 1
Savolainen & Kato Expires September 12, 2011 [Page 4]
Internet-Draft MIF and DNS server selection March 2011
2.2. Network interface specific IP addresses
In the second problem an FQDN is valid and resolvable via different
network interfaces, but to different and not necessarily globally
reachable IP addresses, as is illustrated in the figure 2. Node's
routing and source and destination address selection mechanism must
ensure the destination's IP address is only used in combination with
source IP addresses of the network interface the name was resolved
on.
+--------------------| |
+------+ IPv6 | DNS server A |------| IPv6
| |-- interface 1 --| saying Peer is | |
| | | at: 2001:0db8:0::1 | |
| MIF | +--------------------+ +------+
| node | | Peer |
| | +--------------------+ +------+
| | IPv6 | DNS server B | |
| |-- interface 2 --| saying Peer is | |
+------+ | at: 2001:0db8:1::1 |------| IPv6
+--------------------+ |
Local DNS namespaces and different IP addresses for an FQDN on
interfaces 1 and 2.
Figure 2
Similar situation can happen with IPv6 protocol translation and AAAA
record synthesis [I-D.ietf-behave-dns64]. A synthesised AAAA record
is guaranteed to be valid only on a network interface it was
synthesized on. Figure 3 illustrates a scenario where the peer's
IPv4 address is synthesized into different IPv6 addresses by DNS
servers A and B.
Savolainen & Kato Expires September 12, 2011 [Page 5]
Internet-Draft MIF and DNS server selection March 2011
+-------------------| +-------+
+------+ IPv6 | DNS server A |----| NAT64 |
| |-- interface 1 --| saying Peer is | +-------+
| | | at: A_Pref96:IPv4 | |
| MIF | +-------------------+ | +------+
| node | IPv4 +---| Peer |
| | +-------------------+ | +------+
| | IPv6 | DNS server B | |
| |-- interface 2 --| saying Peer is | +-------+
+------+ | at: B_Pref96:IPv4 |----| NAT64 |
+-------------------+ +-------+
AAAA synthesis results in interface specific IPv6 addresses.
Figure 3
A thing worth noting is that interface specific IP addresses can
cause problems also for a single-homed host, if the host retains its
DNS cache during movement from one network interface to another.
After the interface change a host could have both positive and
negative DNS cache entries no longer valid on the new network
interface. Because of this the cached DNS information should be
considered network interface local instead of node global.
2.3. A problem not fully solved by the described solution
A more complex scenario is an FQDN, which in addition to possibly
resolving into network interface specific IP addresses, identifies on
different network interfaces completely different peer entities with
potentially different set of service offerings. In even more complex
scenario, an FQDN identifies unique peer entity, but one that
provides different services on its different network interfaces. The
solution described in this document is not able to tackle these
higher layer issues. In fact, these problems may be solvable only by
manual user intervention.
However, when DNSSEC is used, the DNSSEC validation procedure may
provide assistance for selecting correct responses for some, but not
all, use cases. A node may prefer to use the DNS answer that
validates with the preferred trust anchor.
3. Deployment scenarios
This document has been written with three particular deployment
scenarios in mind. First being a Consumer Premises Equipment (CPE)
with two or more uplink VLAN connections. Second scenario involves a
Savolainen & Kato Expires September 12, 2011 [Page 6]
Internet-Draft MIF and DNS server selection March 2011
cellular device with two uplink Internet connections: WLAN and
cellular. Third scenario is for VPNs, where use of local DNS server
may be preferred for latency reasons, but corporate DNS server must
be used to resolve private names used by the corporation.
3.1. CPE deployment scenario
A home gateway may have two uplink connections leading to different
networks, as is described in
[I-D.ietf-v6ops-multihoming-without-nat66]. In this scenario only
first uplink connections lead to Internet, while second uplink
connection leads to a private network utilizing private namespace.
It is desirable that the CPE does not have to send DNS queries over
both uplink connections, but instead CPE should send default queries
to the DNS server of the interface leading to the Internet, and
queries related to private namespace to the DNS server of the private
network.
Depending on actual deployments, all VLAN connections may be
considered secure.
3.2. Cellular network scenario
A cellular device may have both WLAN and cellular network interfaces
up. In such a case it is often desirable to use WLAN by default,
except for those connections cellular network operator wants to go
over cellular interface. The cellular network may utilize private
names and hence the cellular device needs to ask for those through
the cellular interface.
In this scenario cellular interface can be considered secure and WLAN
often insecure.
3.3. VPN scenario
Depending on a deployment, there may be need to use VPN only for
traffic destined to a corporate network. The corporation may be
using private namespace, and hence related DNS queries should be send
over VPN to the corporate DNS server, while by default a DNS server
of a local access network may be used.
In this scenario VPN interface can be considered secure and local
access network insecure.
Savolainen & Kato Expires September 12, 2011 [Page 7]
Internet-Draft MIF and DNS server selection March 2011
4. Improved DNS server selection
This chapter describes a procedure a (stub / proxy) resolver may
utilize for improved DNS server selection in face of multiple
namespaces and multiple simultaneously active network interfaces.
4.1. Procedure for prioritizing DNS servers and handling responses
A resolver SHALL build a priority list of DNS servers it will contact
to depending on the query. To build the list in safe and optimal
way, a node SHOULD ask with DHCPv6 which DNS servers of each network
interface are most likely able to successfully serve forward lookup
requests matching to specific DNS suffixes or reverse (PTR record)
lookup requests matching to specific IPv6 prefixes.
A resolver lacking more explicit information shall assume that all
information is available from any DNS server of any network
interface. The DNS servers learnt by other DNS server address
configuration methods MUST be handled as medium priority default
servers.
When a DNS query needs to be made, the resolver SHOULD give highest
precedence to the DNS servers explicitly known to serve matching
suffixes or prefixes. However, the resolver MUST take into account
different trust levels of pieces of DNS server selection information
the resolver may have received from node's network interfaces. The
resolver MUST generally prefer more trusted DNS servers and less
trusted DNS servers MAY be of highest priority only if trusted
interfaces specifically configure DNS servers to be of low priority.
The non-exhaustive list on figure 4 illustrates how the different
trust levels of received DNS server selection information MUST
influence the DNS server selection logic.
Savolainen & Kato Expires September 12, 2011 [Page 8]
Internet-Draft MIF and DNS server selection March 2011
Information from | Information from | Resulting DNS
from more trusted | less trusted | server priority
interface A | interface B | selection
--------------------------+------------------------+--------------------
1. Medium priority | Medium priority | Default: A, then B
default | default |
--------------------------+------------------------+--------------------
2. Medium priority | High priority default | Default: A, then B
default | High priority specific | Specific: A, then B
--------------------------+------------------------+--------------------
3. Low priority default | Medium priority | Default: B, then A
| default |
--------------------------+------------------------+--------------------
4. Low priority default | Medium priority | Default: B, then A
High priority specific | default | Specific: A, then B
--------------------------+------------------------+--------------------
Figure 4: DNS server selection in case of different trust levels
The resolver SHOULD avoid sending queries to different interfaces in
parallel as that may waste resources, sometimes significantly, and
would also unnecessary reveal information about ongoing
communications. Independently of whether DNS queries are sent in
series or parallel, replies for DNS queries MUST be waited until
acceptable positive reply is received, all replies are received, or
time out occurs. Specifically, the resolver MUST NOT proceed with a
positive reply from less trusted server that cannot be validated with
DNSSEC if the DNS query sent to more trusted server is still pending.
If the reply does not validate with a preferred trust anchor, the
node may send queries also to other servers in an attempt to receive
a reply that validates with more preferred trust anchor. (DISCUSS:
What about those DNS servers that instead of negative answer always
return positive reply with an IP address of some captive portal?)
When local namespaces are present a negative reply from a DNS server
implies only that the particular DNS server was not able to serve the
query. However, it is not probable that the secondary DNS servers on
the same network interface, on a same administrative domain, would be
able to serve either. Therefore, the next DNS server resolver
contacts SHOULD be from another network interface.
Resolver SHOULD use DNSSEC to validate all received DNS replies. In
the case DNSSEC validation fails the resolver MUST resend the query
to the next preferred DNS server.
Savolainen & Kato Expires September 12, 2011 [Page 9]
Internet-Draft MIF and DNS server selection March 2011
4.2. DNS server selection option
A DHCPv6 option described below is used to inform resolvers which DNS
server should be contacted when initiating forward or reverse DNS
lookup procedures.
Savolainen & Kato Expires September 12, 2011 [Page 10]
Internet-Draft MIF and DNS server selection March 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DNS_SERVER_SELECT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS-recursive-name-server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|prf| Reserved | |
+-+-+-+-+-+-+-+-+ DNS suffixes and prefixes |
| (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DNS_SERVER_SELECT (TBD)
option-len: Lenght of the option in octets
DNS-recursive-name-server: An IPv6 address of a DNS server
prf: DNS server preference, for selecting between
equally trusted DNS servers:
01 High
00 Medium
11 Low
10 Reserved
Reserved: Flags reserved for the future. MUST be set to zero.
DNS suffixes and prefixes: The list of DNS suffixes for forward DNS
lookup and prefixes for reverse DNS lookup the DNS server
has special knowledge about. Field MUST be encoded as
specified in section "Representation and use of
domain names" of [RFC3315].
Special suffix of "." is used to indicate
capability to resolve global names and act as a
default name server. Lack of "."
suffix on the list indicates DNS server only has
information related to listed suffixes and prefixes.
Prefixes for reverse mapping are encoded as
defined for ip6.arpa [RFC3152].
DHCPv6 option for explicit DNS suffix configuration
Figure 5
Savolainen & Kato Expires September 12, 2011 [Page 11]
Internet-Draft MIF and DNS server selection March 2011
A node SHOULD include an OPTION_ORO option in a DHCPv6 request with
the OPTION_DNS_SERVER_SELECT option code to inform the DHCPv6 server
about the support for the improved DNS server selection logic.
DHCPv6 server receiving this information MAY then choose to provision
DNS server addresses only with the OPTION_DNS_SERVER_SELECT.
The OPTION_DNS_SERVER_SELECT contains one or more DNS suffixes the
related DNS server has particular knowledge of. The option can occur
multiple times in a single DHCPv6 message, if multiple DNS servers
are to be configured.
A resolver SHOULD prioritize between equally trusted DNS servers with
help of the preference field. The resolver MUST NOT prioritize less
trusted DNS servers higher than trusted, even in the case of less
trusted server would apprently have additional information. In the
case of all other things being equal the resolver shall make the
prioritization decision based on its internal preferences.
IPv6 prefixes should cover all the DNS suffixes configured in this
option. Prefixes should be as long as possible to avoid potential
collision with information received on other option instances or with
options received from DHCPv6 servers of other network interfaces.
Overlapping IPv6 prefixes are interpreted so that the resolver can
use any of the DNS servers for queries mathing the prefixes.
If the OPTION_DNS_SERVER_SELECT contains a DNS server address already
learned from other DHCPv6 servers and possibly through other network
interfaces, the node MAY append new prefixes and suffixes to the
information received earlier. The node MUST NOT remove previously
obtained information. However, the node SHOULD NOT extent lifetime
of earlier information either. In the case conflicting DNS server
address and related information is learned from less trusted
interface, the node MAY choose to ignore the option.
As the DNS options of [RFC3646], the OPTION_DNS_SERVER_SELECT option
MUST NOT appear in any other than the following DHCPv6 messages:
Solicit, Advertise, Request, Renew, Rebind, Information-Request, and
Reply.
The node SHOULD create a host specific route for the DNS server
address. The route must point to the interface DNS server address
was learned on. This is required to ensure DNS queries are sent out
via the right interface.
In the case of a trusted DNS server replying negatively to a question
having matching suffix, it will be for implementation to decide
whether to consider that as a final response, or whether to ask also
from other DNS servers. The implementation decision may be based,
Savolainen & Kato Expires September 12, 2011 [Page 12]
Internet-Draft MIF and DNS server selection March 2011
for example, on deployment or trust models.
The information conveyed in OPTION_DNS_SERVER_SELECT is considered
valid until changed or refreshed by general events that trigger
DHCPv6 action. In the event that it is desired for the client to
request a refresh of the information, use of generic DHCPv6
Information Refresh Time Option, as specified in [RFC4242] is
envisaged.
4.3. Coexistence with RFC3646
The OPTION_DNS_SERVER_SELECT is designed to coexist with
OPTION_DNS_SERVERS defined in [RFC3646]. The DNS servers configured
via OPTION_DNS_SERVERS MUST BE considered as default name servers
with medium preference. When both options are received from the same
network interface and the OPTION_DNS_SERVER_SELECT contains default
DNS server address, the resolver MUST make the decision which one to
prefer based on preferences. If OPTION_DNS_SERVER_SELECT defines
medium preference then DNS server from OPTION_DNS_SERVER_SELECT SHALL
be selected. All default servers are assumed to be able to resolve
queries for global names.
If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain the
same DNS server(s) IPv6 address(es), only one instance of each DNS
servers' IPv6 addresses shall be added to the DNS server list.
If a node had indicated support for OPTION_DNS_SERVER_SELECT in
DHCPv6 request, the DHCPv6 server may choose to omit sending of
OPTION_DNS_SERVERS. This enables offloading use case where network
administrator wishes to only advertise low priority default DNS
servers.
4.4. Interactions with OPTION_DOMAIN_LIST
A node may be configured with DNS search list with
OPTION_DOMAIN_LIST. Resolution for the name containing any dots
SHOULD first be attempted with DNS servers of all interfaces as
described earlier. Only if the resolution fails the node SHOULD
append the name with search list suffix(es) and then utilize improved
DNS server selection algorith again to decide which DNS server(s) to
contact next. A name without any dots SHALL immediately be appended
with suffix(es) and improved DNS server selection be utilized on
resolution.
4.5. CNAME/DNAME record considerations
If a node receives a reply with a canonical name (CNAME) or
delegation name (DNAME) the follow-up queries MUST be sent to the
Savolainen & Kato Expires September 12, 2011 [Page 13]
Internet-Draft MIF and DNS server selection March 2011
same DNS server irrespectively of the FQDN received. Otherwise
referrals may fail.
5. Example of a node behavior
Figure 6 illustrates node behavior when it initializes two network
interfaces for parallel usage and learns DNS suffix and prefix
information from DHCPv6 servers.
Application Node DHCPv6 server DHCPv6 server
on interface 1 on interface 2
| | |
| +-----------+ |
(1) | | open | |
| | interface | |
| +-----------+ |
| | |
(2) | |---option REQ-->|
| |<--option RESP--|
| | |
| +-----------+ |
(3) | | store | |
| | suffixes | |
| +-----------+ |
| | |
| +-----------+ |
(4) | | open | |
| | interface | |
| +-----------+ |
| | | |
(5) | |---option REQ------------------->|
| |<--option RESP-------------------|
| | | |
| +----------+ | |
(6) | | store | | |
| | suffixes | | |
| +----------+ | |
| | | |
Illustration of learning DNS suffixes
Figure 6
Flow explanations:
Savolainen & Kato Expires September 12, 2011 [Page 14]
Internet-Draft MIF and DNS server selection March 2011
1. A node opens its first network interface
2. The node obtains DNS suffix and IPv6 prefix information for the
new interface 1 from DHCPv6 server
3. The node stores the learned DNS suffixes and IPv6 prefixes for
later use
4. The node opens its seconds network interface 2
5. The node obtains DNS suffix, say 'example.com', and IPv6 prefix
information, say '8.b.d.0.1.0.0.2.ip6.arpa' for the new interface
2 from DHCPv6 server
6. The node stores the learned DNS suffixes and prefixes for later
use
Figure 7 below illustrates how a resolver uses the learned suffix
information. Prefix information use for reverse lookups is not
illustrated, but that would go as the figure 7 example.
Application Node DHCPv6 server DHCPv6 server
on interface 1 on interface 2
| | | |
(1) |--Name REQ-->| | |
| | | |
| +----------------+ | |
(2) | | DNS server | | |
| | prioritization | | |
| +----------------+ | |
| | | |
(3) | |------------DNS resolution------>|
| |<--------------------------------|
| | | |
(4) |<--Name resp-| | |
| | | |
Example on choosing interface based on DNS suffix
Figure 7
Flow explanations:
1. An application makes a request for resolving an FQDN, e.g.
'private.example.com'
Savolainen & Kato Expires September 12, 2011 [Page 15]
Internet-Draft MIF and DNS server selection March 2011
2. A node creates list of DNS servers to contact to and uses
configured DNS server information and stored DNS suffix
information on priorization decisions.
3. The node has chosen interface 2, as from DHCPv6 it was learned
earlier that the interface 2 has DNS suffix 'example.com'. The
node then resolves the requested name using interface 2's DNS
server to an IPv6 address
4. The node replies to application with the resolved IPv6 address
6. Scalability considerations
The size limitations of DHCPv6 messages limit the number of suffixes
and prefixes that can be carried in a configuration option.
Including the suffixes and prefixes in a DHCPv6 option is best suited
for deployments where relatively few carefully selected suffixes and
prefixes are adequate.
7. Considerations for network administrators
Network administrators deploying private namespaces should assist
advanced hosts in the DNS server selection by providing information
described in this document for nodes. To ensure nodes' routing and
source and destination IP address selection also works correctly,
network administrators should also deploy related technologies for
that purpose.
The solution described herein is best for selecting a DNS server
having knowledge of some namespaces. The solution is not able to
make the right decision in a scenario where the same name points to
different services on different network interfaces, as described in
section 2.3. Network administrators are recommended to avoid
overloading of namespaces in such manner.
To mitigate against attacks against local namespaces, administrators
utilizing this tool should deploy DNSSEC for their zone.
8. Acknowledgements
The author would like to thank following people for their valuable
feedback and improvement ideas: Mark Andrews, Jari Arkko, Marcelo
Bagnulo, Stuart Cheshire, Lars Eggert, Tomohiro Fujisaki, Peter Koch,
Suresh Krishnan, Edward Lewis, Kurtis Lindqvist, Arifumi Matsumoto,
Erik Nordmark, Steve Padgett, Fabien Rapin, Dave Thaler, Margaret
Savolainen & Kato Expires September 12, 2011 [Page 16]
Internet-Draft MIF and DNS server selection March 2011
Wasserman, Dan Wing, and Dec Wojciech. Ted Lemon and Julien Laganier
receive special thanks for their contributions to security
considerations.
This document was prepared using xml2rfc template and the related
web-tool.
9. IANA Considerations
This memo includes a new DHCPv6 option that requires allocation of a
new code point.
10. Security Considerations
It is possible that attackers might try to utilize
OPTION_DNS_SERVER_SELECT option to redirect some or all DNS queries
sent by a resolver to undesired destinations. The purpose of an
attack might be denial-of-service, preparation for man-in-the-middle
attack, or something akin.
Attackers might try to lure specific traffic by advertising DNS
suffixes and prefixes from very small to very large scope or simply
by trying to place attacker's DNS server as the highest priority
default server.
The main countermeasure against these attacks is to systematically
prioritize more trusted DNS servers higher than less trusted ones.
It is also implementation possiblity to listen for DNS server
selection rules only on trusted interfaces. Additionally, resolvers
SHOULD implement validating DNSSEC aware resolvers in order to be
able to validate DNS responses received via any of its interfaces.
Trusting on validation done by a DNS server is a possibility only if
a host trusts the DNS server and can use a secure channel for DNS
messages.
Decision on trust levels of network interfaces depends very much on
deployment scenario and types of network interfaces. For example,
unmanaged WLAN may be considered less trustworthy than managed
cellular or VPN connections.
A node MAY also choose, or be configured, to obtain DNS server
selection rules only from selected trusted interfaces, in which case
it would be in the hands of administrators of these trusted
interfaces whether or not to allow redirection, offloading, of DNS
queries to untrusted interfaces (case 4 of figure 4).
Savolainen & Kato Expires September 12, 2011 [Page 17]
Internet-Draft MIF and DNS server selection March 2011
A node that accepts DNS server selection rules from non-trusted
interfaces and also implements DNSSEC validation SHOULD send queries
also to (all) other known DNS servers in case a non-validatable
response is received from the preferred DNS server. This protects
against possible redirection attacks.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
August 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005.
11.2. Informative References
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-11 (work in progress),
October 2010.
[I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement",
draft-ietf-mif-problem-statement-09 (work in progress),
October 2010.
[I-D.ietf-v6ops-multihoming-without-nat66]
Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
Wing, "IPv6 Multihoming without Network Address
Translation",
draft-ietf-v6ops-multihoming-without-nat66-00 (work in
Savolainen & Kato Expires September 12, 2011 [Page 18]
Internet-Draft MIF and DNS server selection March 2011
progress), December 2010.
[I-D.wing-behave-dns64-config]
Wing, D., "IPv6-only and Dual Stack Hosts on the Same
Network with DNS64", draft-wing-behave-dns64-config-03
(work in progress), February 2011.
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration
Protocol (DHCP) Domain Search Option", RFC 3397,
November 2002.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Option for DNS Configuration",
RFC 5006, September 2007.
Appendix A. Best Current Practice for DNS server selection
On some local namespace deployments explicit policies for DNS server
selection are not available. This section describes ways for hosts
to mitigate the problem by sending wide-spread queries and by
utilizing possibly existing indirect information elements as hints.
A.1. Sending queries out on multiple interfaces in parallel
A possible current practice is to send DNS queries out of multiple
interfaces and pick up the best out of the received responses. A
host SHOULD implement DNSSEC in order to be able to reject responses
that cannot be validated. Selection between legitimate answers is
implementation specific, but replies from trusted servers should be
preferred.
A downside of this approach is increased consumption of resources.
Namely power consumption if an interface, e.g. wireless, has to be
brought up just for the DNS query that could have been resolved also
via cheaper interface. Also load on DNS servers is increased.
However, local caching of results mitigates these problems, and a
node might also learn interfaces that seem to be able to provide
Savolainen & Kato Expires September 12, 2011 [Page 19]
Internet-Draft MIF and DNS server selection March 2011
'better' responses than other and prefer those - without forgetting
fallback required for cases when node is connected to more than one
network using local namespaces.
Another downside is revealing to all DNS servers the names a host is
connecting to. For example, a DNS server of a public hotspot could
learn all the private names host is trying to connect on other
interfaces.
A.2. Search list option for DNS forward lookup decisions
A host can learn the special DNS suffixes of attached network
interfaces from DHCP search list options; DHCPv4 Domain Search Option
number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24
[RFC3646]. The host behavior is very similar as is illustrated in
the example at section 3.3. While these DHCP options are not
intented to be used in DNS server selection, they may be used by the
host as hints for smarter DNS server prioritization purposes in order
to increase likelyhood of fast and successful DNS query.
Overloading of existing DNS search list options is not without
problems: resolvers would obviously use the DNS suffixes learned from
search lists also for name resolution purposes. This may not be a
problem in deployments where DNS search list options contain few DNS
suffixes like 'example.com, private.example.com', but can become a
problem if many suffixes are configured.
A.3. More specific routes for reverse lookup decision
[RFC4191] defines how more specific routes can be provisioned for
hosts. This information is not intented to be used in DNS server
selection, but nevertheless a host can use this information as a hint
about which interface would be best to try first for reverse lookup
procedures. A DNS server configured via the same interface as more
specific routes is more likely capable to answer reverse lookup
questions correctly than DNS server of an another interface. The
likelyhood of success is possibly higher if DNS server address is
received in the same RA [RFC5006] as the more specific route
information.
A.4. Longest matching prefix for reverse lookup decision
A host may utilize the longest matching prefix approach when deciding
which DNS server to contact for reverse lookup purposes. Namely, the
host may send a DNS query to a DNS server learned over an interface
having longest matching prefix to the address being queried. This
approach can help in cases where ULA [RFC4193] addresses are used and
when the queried address belongs to a host or server within the same
Savolainen & Kato Expires September 12, 2011 [Page 20]
Internet-Draft MIF and DNS server selection March 2011
network (for example intranet).
Authors' Addresses
Teemu Savolainen
Nokia
Hermiankatu 12 D
TAMPERE, FI-33720
FINLAND
Email: teemu.savolainen@nokia.com
Jun-ya Kato
NTT
9-11, Midori-Cho 3-Chome Musashino-Shi
TOKYO, 180-8585
JAPAN
Email: kato@syce.net
Savolainen & Kato Expires September 12, 2011 [Page 21]
