Internet Engineering Task Force T. Savolainen
Internet-Draft Nokia
Intended status: Standards Track February 26, 2010
Expires: August 30, 2010
DNS Server Selection on Multi-Homed Hosts
draft-savolainen-mif-dns-server-selection-02
Abstract
A multi-homed host may receive DNS server configuration information
from multiple physical and/or virtual network interfaces. In split
DNS scenarios not all DNS servers are able to provide the same
information. When the multi-homed host needs to utilize DNS, it has
to select which of the servers to contact to. This document
describes problems of split DNS for multi-homed hosts and also a
method for selecting the DNS server with help of DNS suffix
information received dynamically for each network interface. The
method is useful in split DNS scenarios where private names are used
and where correct DNS server selection is mandatory for successful
DNS resolution.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2010.
Copyright Notice
Savolainen Expires August 30, 2010 [Page 1]
Internet-Draft MIF and DNS server selection February 2010
Copyright (c) 2010 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
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Problem description for split DNS with multi-homed hosts . . . 4
2.1. Private fully qualified domain names . . . . . . . . . . . 4
2.2. Network interface specific IP addresses . . . . . . . . . 5
3. DNS server selection procedure . . . . . . . . . . . . . . . . 7
3.1. DNS suffixes as hints . . . . . . . . . . . . . . . . . . 8
3.1.1. Learning of the DNS suffixes on existing networks . . 8
3.1.2. Explicit DNS suffix configuration with DHCP . . . . . 10
3.1.3. Changes to DNS resolution procedures . . . . . . . . . 11
4. Considerations for network administrators . . . . . . . . . . 12
5. Further considerations . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Savolainen Expires August 30, 2010 [Page 2]
Internet-Draft MIF and DNS server selection February 2010
1. Introduction
A multi-homed host faces several problems over single-homed host as
described in [I-D.ietf-mif-problem-statement]. This document studies
in detail problems split DNS may cause for multi-homed hosts and for
which optimized behaviour should be defined. The problems are mostly
the same in IPv4 and IPv6 domains.
In the split DNS scenario different DNS servers have different
information. Therefore DNS related information, which otherwise
could be consider global for a single-homed host, in a multi-homed
host has to be handled as local to a network interface. DNS record
synthesis, as described in DNS64 [I-D.ietf-behave-dns64] and Bump-In-
the-Stack [RFC2767], can be consider as one manifestation of split
DNS.
An obvious solution for the problem would be for network
administrators to cease utilizing any form of split DNS, or have
split DNS used only in deployments where hosts are not allowed to
multi-home. However, currently split DNS is deployed and multi-homed
hosts have to cope with that.
If an application is bound to utilize only a specific network
interface at a time, it essentially makes the host behave single-
interface way for that particular application and avoids the problems
of split DNS, if also application's DNS requests are handled strictly
with DNS service available in that particular network interface. If
all applications in a host are bound to use only single network
interface at a time, even if the used network interfaces were
different, the problems are generally avoided. Please see MIF
current practices [I-D.ietf-mif-current-practices] for more
information. The procedure described in chapter 3 applies when
applications are allowed to utilize multiple interfaces in parallel.
An example of an application that would benefit from multi-homing is
a web browser, which commonly accesses many different destinations
and should be able to dynamically communicate over different network
interfaces.
The solution presented in this memo is intended to be fully backwards
compatible and one that can be fully ignored by hosts and networks
that are not experiencing the described problem scenarios or that
does not implement the solution.
In deployments where split DNS is used, selection of the correct
destination and source addresses for the actual IP connection is
crucial, as the resolved destination's IP address may be only usable
on the network interface over which it was resolved on. However, the
Savolainen Expires August 30, 2010 [Page 3]
Internet-Draft MIF and DNS server selection February 2010
actual IP address selection logic is not at the scope of this
document.
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 split DNS with multi-homed hosts
This chapter describes two multi-homing related split DNS problem
scenarios for which the procedure described in chapter 3 is targeted
at. (DISCUSS: Even more more known problem scenarios caused by split
DNS for multi-homed hosts?)
2.1. Private fully qualified domain names
A multi-homed host may be connecting to one or more networks that are
using private fully qualified domain names. As an example, the host
may have simultaneously open a wireless LAN (WLAN) connection to open
Internet, cellular connection to an operator network, and virtual
private network (VPN) connection to a corporate network. When an
application initiates connection to an FQDN, the host needs to be
able to choose the right network interface for making successful DNS
query. This is illustrated in figure 1. If the FQDN is for a public
name, in figure 1 scenario it could be resolved with any DNS server
of any network interface, but if the FQDN would be corporation's or
operator's service's private name, the host would need to be able to
correctly select the right network interface for DNS procedures, i.e.
already before destination's IP address is known.
Savolainen Expires August 30, 2010 [Page 4]
Internet-Draft MIF and DNS server selection February 2010
+---------------+
| DNS server w/ | | Corporate
+------+ | public + |----| Intranet
| | | corporation's | |
| |===== VPN =======| private names | |
| | +---------------+ +----+
| MIF | | FW |
| host | +----+
| | +---------------+ |
| |----- WLAN ------| DNS server w/ |----| Public
| | | public names | | Internet
| | +---------------+ +----+
| | | FW |
| | +---------------+ +----+
| |---- cellular ---| DNS server w/ | |
+------+ | public + | | Operator
| operator's |----| Intranet
| private names | |
+---------------+
Split DNS and private names illustrated
Figure 1
2.2. Network interface specific IP addresses
In the second problem an FQDN as such is valid and resolvable via
different network interfaces, but to different and not necessarily
globally reachable IP addresses, as illustrated in figure 2. This is
not so much a problem when a host is single-homed, but for multi-
homed host this results in additional challenges: the host's 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.
Savolainen Expires August 30, 2010 [Page 5]
Internet-Draft MIF and DNS server selection February 2010
+----------------| |
+------+ IPv4 | DNS server A |------| IPv4
| |-- interface 1 --| saying Peer is | |
| | | at: 192.0.2.1 | |
| MIF | +----------------+ +------+
| host | | Peer |
| | +----------------+ +------+
| | IPv4 | DNS server B | |
| |-- interface 2 --| saying Peer is | |
+------+ | at: 10.0.0.1 |------| IPv4
+----------------+ |
Split DSN and different IP addresses for an FQDN on interfaces 1 and
2.
Figure 2
Similar situation can happen when IPv6 protocol translation is used
in combination with AAAA record synthesis proceduce
[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. The same
problem can happen in the IPv4 domain as well if A record synthesis
is done, for example as described in Bump-In-the-Stack [RFC2767].
For a related problem for dual-stack hosts in a network with DNS64,
where IPv4 should be prioritized over synthesized IPv6, please see
[I-D.wing-behave-dns64-config].
+------------------| +-------+
+------+ IPv6 | DNS server A |----| NAT64 |
| |-- interface 1 --| saying Peer is | +-------+
| | | at: A_Pref64::/n | |
| MIF | +------------------+ | +------+
| host | IPv4 +---| Peer |
| | +------------------+ | +------+
| | IPv6 | DNS server B | |
| |-- interface 2 --| saying Peer is | +-------+
+------+ | at: B_Pref64::/n |----| NAT64 |
+------------------+ +-------+
AAAA synthesis results in interface specific IPv6 addresses.
Figure 3
Savolainen Expires August 30, 2010 [Page 6]
Internet-Draft MIF and DNS server selection February 2010
More complex scenario is an FQDN, which in addition to resolving into
network interface specific IP addresses, identifies on different
network interfaces completely different peer entities with
potentially different set of service offering. 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.
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, and
thus on the new network interface host has cache entries invalid for
that network interface. Because of this the cached DNS information
should be considered network interface local instead of node global.
3. DNS server selection procedure
This chapter documents a possible procedure a host may utilize for
DNS server selection on multi-homing scenarios.
Essentially, the host shall build dynamically for each DNS query a
list of DNS servers it will try to contact to. The host shall cycle
through the list until a positive reply is received, or until all
selected DNS servers have been contacted or timed out. (DISCUSS:
What about those DNS servers that instead of negative answer always
return positive reply with an IP address of some default HTTP server,
which purpose is just to say 'page not found'?)
When building the list, the host shall prioritize DNS servers in a
optimal way for the query at hand. Host can utilize any information
it may have, e.g. possible user's preferences, host's general
preferences between network interfaces, differences on trust levels
of network interfaces (see Security Considerations), DNS suffix
information possibly available, or any other piece of information.
For the scenario where an FQDN maps to same service but different IP
addresses on different network interfaces, the source address
selection algorithm must be able to pick a source address from the
network interface that was used for DNS resolution.
In private FQDN deployments a negative reply from a DNS server
implies only that the DNS server at hand is not able to serve the
query. However, it is not probable that the secondary DNS servers on
the same network interface would be able to serve either, due likely
being in the same administrative domain. Therefore the next DNS
server host contacts should be from another network interface.
Savolainen Expires August 30, 2010 [Page 7]
Internet-Draft MIF and DNS server selection February 2010
A host may optimize its behaviour by sending DNS requests in parallel
to multiple DNS servers of different network interfaces, but this
approach is not always practical:
o It may unnecessary trigger activation of a radio and thus increase
battery consumption.
o It may unnecessarily reveal private names to outsiders.
o It may be a privacy issue as it would reveal all names host is
resolving to all DNS servers.
3.1. DNS suffixes as hints
To help prioritize DNS servers in an optimal way, a host may learn
which DNS servers are most likely able to successfully serve requests
related to specific DNS suffixes.
By default, a host should assume all information is available via all
DNS servers of any network interface.
When a resource record is to be resolved, a host shall give highest
precedence to the DNS servers explicitly known to serve matching
suffixes and then to the DNS servers of the network interface(s)
advertising corresponding DNS suffix.
For example, when a resolution of an FQDN has been requested and the
host is prioritizing DNS servers of different network interfaces, the
host may prioritize higher DNS server(s) of the network interface(s)
with matching DNS suffix than it otherwise would have.
3.1.1. Learning of the DNS suffixes on existing networks
A host can learn the 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].
This is illustrated in example figure 4 below.
Savolainen Expires August 30, 2010 [Page 8]
Internet-Draft MIF and DNS server selection February 2010
Application Host DHCP server of DHCP server of
interface 1 interface 2
| | |
| +-----------+ |
(1) | | open | |
| | interface | |
| +-----------+ |
| | |
(2) | |---option REQ-->|
| |<--option RESP--|
| | |
| +-----------+ |
(3) | | store | |
| | suffixes | |
| +-----------+ |
| | |
| +-----------+ |
(4) | | open | |
| | interface | |
| +-----------+ |
| | | |
(5) | |---option REQ------------------->|
| |<--option RESP-------------------|
| | | |
| +----------+ | |
(6) | | store | | |
| | suffixes | | |
| +----------+ | |
| | | |
Learning DNS suffixes
Figure 4
Flow explanations:
1. A host opens its first network interface
2. The host obtains DNS suffix information for the new interface 1
from DHCP server
3. The host stores the learned DNS suffixes for later use
4. The host opens its seconds network interface 2
5. The host obtains DNS suffix, say 'example.com' information for
the new interface 2 from DHCP server
Savolainen Expires August 30, 2010 [Page 9]
Internet-Draft MIF and DNS server selection February 2010
6. The host stores the learned DNS suffixes for later use
3.1.2. Explicit DNS suffix configuration with DHCP
To avoid overloading of existing DHCP(v6) options, new DHCP(v6)
options could be defined to assist in DNS server selection. The
options would define which DNS server should be used for resolving
names matching configured DNS suffixes. Below is description of the
DHCPv6 option. DHCPv4 version is to be added in next revision, but
would work similarly.
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNS suffixes |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
DNS suffixes: The list of DNS suffixes MUST be encoded as
specified in section "Representation and use of
domain names" of <xref target="RFC3315"></xref>.
DHCPv6 option for explicit DNS suffix configuration
Figure 5
The OPTION_DNS_SERVER_SELECT contains one or more DNS suffixes the
related DNS server has particular knowledge of (e.g. private
suffixes). The option can occur multiple times in a single DHCPv6
message, if multiple DNS servers are to be configured.
As the DNS options of [RFC3646], the OPTION_DNS_SERVER_SELECT option
MUST NOT appear in any other than the following messages: Solicit,
Advertise, Request, Renew, Rebind, Information-Request, and Reply.
Savolainen Expires August 30, 2010 [Page 10]
Internet-Draft MIF and DNS server selection February 2010
Due backwards compatibility, the DHCPv6 message containing
OPTION_DNS_SERVER_SELECT also very likely contains
OPTION_DNS_SERVERS. In case both options contain same IPv6
addresses, only one copy of the IPv6 address SHALL be added to the
DNS server list.
In the case of a DNS server replying negatively to a question having
matching suffix, it will be for implementation to decide whether to
consider that as authoritative response, or whether to ask also from
other DNS servers. The implementation decision may be based, for
example, on deployment or trust models.
3.1.3. Changes to DNS resolution procedures
When a DNS resolver in a host is requested by an application to do
DNS resolution for an FQDN to an IP address, the host should look if
any of the configured DNS servers are known to serve addresses for
particular suffixes, or if any of the available network interfaces
are known to advertise DNS suffixes matching to the FQDN. If there
is a match, then explicitly configured DNS server(s) or DNS server(s)
of the particular interface should be priorized higher, i.e. be used
for name resolution procedures. This is illustrated in figure 6
below. To avoid accidental use of synthesized IPv6 addresses in the
dual-stack case, a host may prioritize DNS servers' IPv4 addresses
over IPv6 addresses.
Application Host DHCP server of DHCP server of
interface 1 interface 2
| | | |
(1) |--Name REQ-->| | |
| | | |
| +----------------+ | |
(2) | | DNS server | | |
| | prioritization | | |
| +----------------+ | |
| | | |
(3) | |------------DNS resolution------>|
| |<--------------------------------|
| | | |
(4) |<--Name resp-| | |
| | | |
Choosing interface based on DNS suffix
Figure 6
Flow explanations:
Savolainen Expires August 30, 2010 [Page 11]
Internet-Draft MIF and DNS server selection February 2010
1. An application makes a request for resolving an FQDN, e.g.
'private.example.com'
2. A host creates list of DNS servers to contact to and uses
configured DNS server information and stored DNS suffix
information on priorization decisions.
3. The host has chosen interface 2, as from DHCP it was learned
earlier that the interface 2 has DNS suffix 'example.com'. The
host then resolves the requested name using interface 2's DNS
server to IP 192.0.2.1
4. The host replies to application with resolved IP address
192.0.2.1
4. Considerations for network administrators
Due to the problems caused by split DNS for multi-homed hosts,
network administrators should consider carefully deployment of split
DNS.
Network administrators deploying split DNS should assist hosts in DNS
server selection by configuring their DHCP servers with proper DNS
suffix information, which hosts then can use as hints. To ensure
hosts' source and destination IP address selection works correctly,
network administrators should also consider deployment of additional
technologies to help with that.
Network administrators can continue using DHCP DNS search list
options as before, but administrators should take into account that
multi-homed hosts may choose to use the DNS suffix information also
for DNS server selection purposes.
5. Further considerations
Overloading of existing DNS search list options is not without
problems, though: hosts 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. To avoid overloading of
existing options, this document proposes standardization of a
completely new DHCP option.
Savolainen Expires August 30, 2010 [Page 12]
Internet-Draft MIF and DNS server selection February 2010
6. Acknowledgements
The author would like to thank following people for their valuable
comments: Jari Arkko, Marcelo Bagnulo, Lars Eggert, Kurtis Lindqvist,
Fabien Rapin, Dave Thaler, Margaret Wasserman, Dec Wojciech, Suresh
Krishnan, Arifumi Matsumoto, Tomohiro Fujisaki and Dan Wing.
This document was prepared using xml2rfc template and related web-
tool.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
An attacker may try to lure traffic from multi-homed host to his
network by advertising DNS suffixes attacker wishes to intercept or
deny service of. The host's security should not be based on correct
functionality of DNS server selection, but nevertheless risks of this
attack can be mitigated by using DNSSEC and additionally properly
prioritizing network interfaces with conflicting DNS suffix
advertisements. The prioritization could be based on trust level of
a network interface over which DNS suffix was learned from, like for
example:
1. Managed tunnel interfaces (such as VPN) considered most
trustworthy
2. Managed networks being on the middle
3. Unmanaged networks having lowest priority
Now, for example, if all of the three abovementioned networks would
advertise 'corporation.com' DNS suffix, the host would prefer the VPN
network interface for related DNS resolution requests.
9. References
9.1. Normative 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",
Savolainen Expires August 30, 2010 [Page 13]
Internet-Draft MIF and DNS server selection February 2010
draft-ietf-behave-dns64-06 (work in progress),
February 2010.
[I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces Problem
Statement", draft-ietf-mif-problem-statement-01 (work in
progress), October 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack
Hosts using the "Bump-In-the-Stack" Technique (BIS)",
RFC 2767, February 2000.
[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.
[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.
9.2. Informative References
[I-D.ietf-mif-current-practices]
Wasserman, M., "Current Practices for Multiple Interface
Hosts", draft-ietf-mif-current-practices-00 (work in
progress), October 2009.
[I-D.wing-behave-dns64-config]
Wing, D., "DNS64 Resolvers and Dual-Stack Hosts",
draft-wing-behave-dns64-config-02 (work in progress),
February 2010.
Savolainen Expires August 30, 2010 [Page 14]
Internet-Draft MIF and DNS server selection February 2010
Author's Address
Teemu Savolainen
Nokia
Hermiankatu 12 D
TAMPERE, FI-33720
FINLAND
Email: teemu.savolainen@nokia.com
Savolainen Expires August 30, 2010 [Page 15]