Internet Engineering Task Force T. Savolainen
Internet-Draft Nokia
Intended status: Standards Track J. Kato
Expires: March 21, 2011 NTT
September 17, 2010
Improved DNS Server Selection for Multi-Homed Nodes
draft-savolainen-mif-dns-server-selection-04
Abstract
A multi-homed node can be connected to multiple networks that may
utilize different DNS namespaces. The node often 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 selecting 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 March 21, 2011.
Copyright Notice
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
Savolainen & Kato Expires March 21, 2011 [Page 1]
Internet-Draft MIF and DNS server selection September 2010
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 . . . . . . . . . 4
3. Improved DNS server selection procedure . . . . . . . . . . . 6
3.1. DNS server selection option . . . . . . . . . . . . . . . 7
4. Example of a node behavior . . . . . . . . . . . . . . . . . . 9
5. Scalability considerations . . . . . . . . . . . . . . . . . . 12
6. Considerations for network administrators . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. Suffix matching example . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Best Current Practice for DNS server selection . . . 15
A.1. Search list option for DNS forward lookup decisions . . . 15
A.2. More specific routes for reverse lookup decision . . . . . 15
A.3. Longest matching prefix for reverse lookup decision . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Savolainen & Kato Expires March 21, 2011 [Page 2]
Internet-Draft MIF and DNS server selection September 2010
1. Introduction
A multi-homed node faces several problems over single-homed node 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 in the IPv4 and IPv6 domains and provides a solution.
The node may be implemented as a host, or as a router such as
Consumer Premises Equipment.
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 provide
any piece of information, 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 should
be able to dynamically communicate over different network interfaces.
However, as the IPv4 is being phased out and often uses NATs to
achieve similar functions, this document describes a solution only
for the IPv6 domain.
In deployments where multiple namespaces are present, selection of
the correct destination and source addresses for the actual IP
connection is usually crucial as well, as the resolved destination's
IP address may be only usable on the network interface over which it
was resolved on. Hence solution described in this document is
assumed to be often used in combination of tools delivering source
and destination address selection policies.
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. Essentially the same challenges may be faced by Consumer
Premises Equipment as is described in
[I-D.troan-multihoming-without-nat66].
Savolainen & Kato Expires March 21, 2011 [Page 3]
Internet-Draft MIF and DNS server selection September 2010
2.1. Fully qualified domain names with limited scopes
A multi-homed host may be connecting to one or more networks that are
using local namespaces. As an example, the host may have
simultaneously open a wireless LAN (WLAN) connection to 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 network interface for making a
successful DNS query. This is illustrated in the figure 1. An FQDN
for a public name can be resolved with any DNS server of any network
interface, but for an FQDN of corporation's or operator's service's
local name the host would need to be able to correctly select the
right network interface for the DNS resolution, i.e. do interface
selection already before destination's IP address is known.
+---------------+
| DNS server w/ | | Corporate
+------+ | public + |----| Intranet
| | | corporation's | |
| |===== VPN =======| local names | |
| | +---------------+ +----+
| MIF | | FW |
| host | +----+
| | +---------------+ |
| |----- WLAN ------| DNS server w/ |----| Public
| | | public names | | Internet
| | +---------------+ +----+
| | | FW |
| | +---------------+ +----+
| |---- cellular ---| DNS server w/ | |
+------+ | public + | | Operator
| operator's |----| Intranet
| local names | |
+---------------+
Split DNS and locally scoped 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 is illustrated in the figure 2.
This is a problem when a host is single-homed, but for multi-homed
host this results in additional challenges: the host's source and
Savolainen & Kato Expires March 21, 2011 [Page 4]
Internet-Draft MIF and DNS server selection September 2010
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 | +--------------------+ +------+
| host | | Peer |
| | +--------------------+ +------+
| | IPv6 | DNS server B | |
| |-- interface 2 --| saying Peer is | |
+------+ | at: 2001:0db8:1::1 |------| IPv6
+--------------------+ |
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].
Savolainen & Kato Expires March 21, 2011 [Page 5]
Internet-Draft MIF and DNS server selection September 2010
+-------------------| +-------+
+------+ IPv6 | DNS server A |----| NAT64 |
| |-- interface 1 --| saying Peer is | +-------+
| | | at: A_Pref96:IPv4 | |
| MIF | +-------------------+ | +------+
| host | 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 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. In fact, some of the problems may be solvable
only by user intervention.
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 invalid for the new network interface.
Because of this the cached DNS information should be considered
network interface local instead of node global.
3. Improved DNS server selection procedure
This chapter documents a procedure a (stub / proxy) resolver may
utilize for DNS server selection in face of multiple namespaces.
Essentially, the resolver shall dynamically build for each DNS query
a priority list of DNS servers it will try to contact to. The
resolver 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 'authenticate'
Savolainen & Kato Expires March 21, 2011 [Page 6]
Internet-Draft MIF and DNS server selection September 2010
or 'page not found'? Maybe DNSSEC would help here, i.e. roll through
DNS servers until one provides a response that can be validated?)
To prioritize DNS servers in an optimal way, the resolver should ask
with DHCPv6 which DNS servers 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.
Additionally, the resolver may utilize any other information it may
have, e.g. possible user's preferences, node's general preferences
between network interfaces, differences on trust levels of network
interfaces (see Security Considerations), or any other piece of
information.
When a resource record is to be resolved, the resolver MUST give
highest precedence to the DNS servers explicitly known to serve
matching suffixes or prefixes. A node may need to remember the
interface used for successfuly query in order to be able to improve
source address selection.
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.
When local namespace 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.
3.1. DNS server selection option
A DHCPv6 option described below is used to inform nodes which DNS
server should be contacted when initiating forward or reverse DNS
lookup procedures.
Savolainen & Kato Expires March 21, 2011 [Page 7]
Internet-Draft MIF and DNS server selection September 2010
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:
01 High
00 Medium
11 Low
10 Reserved - MUST NOT be sent
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].
Additionally, special suffix of "." is used to indicate
capability to resolve global names. Lack of "."
suffix on the list indicates DNS server has only local
information. Prefixes for reverse mapping are encoded as
defined for ip6.arpa [RFC3152].
DHCPv6 option for explicit DNS suffix configuration
Figure 4
The OPTION_DNS_SERVER_SELECT contains one or more DNS suffixes the
Savolainen & Kato Expires March 21, 2011 [Page 8]
Internet-Draft MIF and DNS server selection September 2010
related DNS server has particular knowledge of (i.e.. local
namespaces). The option can occur multiple times in a single DHCPv6
message, if multiple DNS servers are to be configured.
A node can prioritize DNS servers with help of preference field.
IPv6 prefixes should cover all the DNS suffixes configured in this
option. Prefixes should be as long as possible to avoid collision
with information received on other option instances or with options
received from DHCPv6 servers of other network interfaces.
Overlapping IPv6 prefixes are interpreted by a node so that the
resolver can use multiple DNS servers for queries mathing the
prefixes.
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.
For backwards compatibility reasons the DHCPv6 message containing
OPTION_DNS_SERVER_SELECT also likely contains OPTION_DNS_SERVERS
option. In case both options contain the same IPv6 addresses, only
one copy of the IPv6 address of DNS server 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 a final response, or whether to ask also from other
DNS servers. The implementation decision may be based, for example,
on deployment or trust models.
4. Example of a node behavior
Figure 5 illustrates node behavior when it initializes two network
interfaces for parallel usage and learns DNS suffix and prefix
information from DHCPv6 servers.
Savolainen & Kato Expires March 21, 2011 [Page 9]
Internet-Draft MIF and DNS server selection September 2010
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 5
Flow explanations:
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
Savolainen & Kato Expires March 21, 2011 [Page 10]
Internet-Draft MIF and DNS server selection September 2010
2 from DHCPv6 server
6. The node stores the learned DNS suffixes and prefixes for later
use
Figure 6 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 6 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 6
Flow explanations:
1. An application makes a request for resolving an FQDN, e.g.
'private.example.com'
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
Savolainen & Kato Expires March 21, 2011 [Page 11]
Internet-Draft MIF and DNS server selection September 2010
5. 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.
6. Considerations for network administrators
Network administrators deploying private namespaces should assist
advanced hosts in the DNS server selection by providing information
described in this memo for nodes. To ensure nodes' 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 same name points to
different services on different network interfaces. Network
administrators are recommended to avoid overloading of namespaces in
such manner.
7. 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, Ted Lemon, Edward Lewis, Kurtis Lindqvist, Arifumi
Matsumoto, Erik Nordmark, Steve Padgett, Fabien Rapin, Dave Thaler,
Margaret Wasserman, Dan Wing, and Dec Wojciech.
This document was prepared using xml2rfc template and the related
web-tool.
8. IANA Considerations
This memo includes a new DHCPv6 option that requires allocation of a
new code point.
9. Security Considerations
An attacker may try to lure traffic from multi-homed host to his
Savolainen & Kato Expires March 21, 2011 [Page 12]
Internet-Draft MIF and DNS server selection September 2010
network by advertising DNS suffixes and prefixes attacker wishes to
intercept or deny service of. The node's security should not be
based on correct functionality of DNS server selection. Use of
DNSSEC is recommended to mitigates risks of forgery.
Additionally nodes may employ heuristics to more wisely prioritize
network interfaces with conflicting policies. The prioritization
may, for example, be based on trust level of a network interface over
which policy was learned from. To avoid problem of attacker
advertising suffix with wide scope (such as .com) or intentionally
narrow scope (such as mail.example.com), the node may want to first
match suffixes of highest priority interface and if such match is
found, consider information from other interface as lower priority.
9.1. Suffix matching example
In this example a host has three interfaces (in decreasing order of
priority):
1. Managed tunnel interfaces (such as VPN) considered most
trustworthy. Advertises suffix 'example.com'
2. Cellular network advertising default suffix '.'
3. WLAN hotspot with attacker advertising suffixes
'mail.example.com' and '.com'
When a host resolves name 'mail.example.com', it will notice the
highest priority interface has matching non-default suffix. As the
'example.com' matches to 'mail.example.com', the tunnel interface
will be used. Simple longest matching or shortest matching rules
would have resulted in the host using attackers network.
When a host resolves name 'example2.com', it will find highest
matching non-default prefix from WLAN hotspot. While it would have
been safer to use cellular network's DNS server, security level is
not decreased from what any single interface node would have.
The multi-homed host may also choose to always use the most
trustworthy interface it has for DNS queries.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Savolainen & Kato Expires March 21, 2011 [Page 13]
Internet-Draft MIF and DNS server selection September 2010
[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.
10.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-10 (work in progress), July 2010.
[I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces Problem
Statement", draft-ietf-mif-problem-statement-07 (work in
progress), August 2010.
[I-D.troan-multihoming-without-nat66]
Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
Wing, "IPv6 Multihoming without Network Address
Translation", draft-troan-multihoming-without-nat66-01
(work in progress), July 2010.
[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.
[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,
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.
Savolainen & Kato Expires March 21, 2011 [Page 14]
Internet-Draft MIF and DNS server selection September 2010
[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 split-DNS deployments explicit policies for DNS server
selection are not available. This section describes ways for hosts
to mitigate the problem by utilizing possibly existing indirect
information elements as hints. The approach to ask everything from
everyone remains always as last resort option.
A.1. 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 for smart 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.2. 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 likely more capable to answer reverse lookup
questions 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.3. 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
Savolainen & Kato Expires March 21, 2011 [Page 15]
Internet-Draft MIF and DNS server selection September 2010
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
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 March 21, 2011 [Page 16]