Internet Engineering Task Force T. Savolainen
Internet-Draft Nokia
Intended status: Informational October 20, 2009
Expires: April 23, 2010
DNS Server Selection on Multi-Homed Hosts
draft-savolainen-mif-dns-server-selection-01
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 April 23, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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
Savolainen Expires April 23, 2010 [Page 1]
Internet-Draft MIF and DNS server selection October 2009
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.
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 . . . . . . . . . . . . . 8
3.1.2. Changes to DNS resolution procedures . . . . . . . . . 10
4. Considerations for network administrators . . . . . . . . . . 11
5. Further considerations . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Savolainen Expires April 23, 2010 [Page 2]
Internet-Draft MIF and DNS server selection October 2009
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 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 April 23, 2010 [Page 3]
Internet-Draft MIF and DNS server selection October 2009
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 April 23, 2010 [Page 4]
Internet-Draft MIF and DNS server selection October 2009
+---------------+
| 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 April 23, 2010 [Page 5]
Internet-Draft MIF and DNS server selection October 2009
+----------------| |
+------+ 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].
+------------------| +-------+
+------+ 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
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
Savolainen Expires April 23, 2010 [Page 6]
Internet-Draft MIF and DNS server selection October 2009
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.
A host may optimize its behaviour by sending DNS requests in parallel
to multiple DNS servers of different network interfaces, but this
Savolainen Expires April 23, 2010 [Page 7]
Internet-Draft MIF and DNS server selection October 2009
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 higher
precedence to 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
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 April 23, 2010 [Page 8]
Internet-Draft MIF and DNS server selection October 2009
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 April 23, 2010 [Page 9]
Internet-Draft MIF and DNS server selection October 2009
6. The host stores the learned DNS suffixes for later use
3.1.2. 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 available network interfaces is known to advertise DNS
suffix matching to the FQDN. If there is a matching DNS suffix, then
DNS server(s) of that that particular interface should be priorized
higher, i.e. be used for name resolution procedures. This is
illustrated in figure 5 below.
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 5
Flow explanations:
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 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
Savolainen Expires April 23, 2010 [Page 10]
Internet-Draft MIF and DNS server selection October 2009
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.
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, and Arifumi Matsumoto.
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
Savolainen Expires April 23, 2010 [Page 11]
Internet-Draft MIF and DNS server selection October 2009
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. 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",
draft-ietf-behave-dns64-01 (work in progress),
October 2009.
[I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces Problem
Statement", draft-ietf-mif-problem-statement-00 (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.
[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,
Savolainen Expires April 23, 2010 [Page 12]
Internet-Draft MIF and DNS server selection October 2009
December 2003.
Author's Address
Teemu Savolainen
Nokia
Hermiankatu 12 D
TAMPERE, FI-33720
FINLAND
Email: teemu.savolainen@nokia.com
Savolainen Expires April 23, 2010 [Page 13]