Internet Engineering Task Force T. Savolainen
Internet-Draft Nokia
Intended status: Standards Track June 7, 2010
Expires: December 9, 2010
Improved DNS Server Selection for Multi-Homed Hosts
draft-savolainen-mif-dns-server-selection-03
Abstract
A multi-homed host may receive DNS server configuration information
from multiple physical and/or virtual network interfaces. In split
DNS scenarios some DNS servers have information others do not have.
When the multi-homed host needs to utilize DNS, it has to select
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 December 9, 2010.
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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Savolainen Expires December 9, 2010 [Page 1]
Internet-Draft MIF and DNS server selection June 2010
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 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 . . . . . . . . . . . . . . . . 6
3.1. DNS server selection policy distribution with a DHCPv6
option . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Changes to DNS resolution procedures . . . . . . . . . . . 10
3.3. Example of a host behavior . . . . . . . . . . . . . . . . 10
4. Considerations for network administrators . . . . . . . . . . 12
5. Further considerations . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Best effort 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 . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Savolainen Expires December 9, 2010 [Page 2]
Internet-Draft MIF and DNS server selection June 2010
1. Introduction
A multi-homed host faces several problems over single-homed host as
is described in [I-D.ietf-mif-problem-statement]. This document
studies in detail the problems split DNS may cause for multi-homed
hosts in the IPv4 and IPv6 domains. However, as the IPv4 is being
phased out, this document describes a solution only for the IPv6
domain.
In the split DNS scenario some DNS servers have information other
servers do not have. Because of that, a multi-homed host cannot
assume every DNS server is able to provide any piece of information,
but instead it must be able to ask right server for the information
it needs.
If an application and its DNS queries are bound to utilize only a
single network interface, the problems of split DNS are avoided. If
all applications in a host are administratively bound to use a only
single network interface, even if the used network interfaces were
different for different applications, the problems are avoided.
Please see MIF current practices [I-D.ietf-mif-current-practices] for
more information. However, benefits of multi-homing are lost if
applications are forced to use only a single netowork interface. The
procedure described in chapter 3 applies when applications are
allowed to utilize multiple network interfaces in parallel.
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.
In deployments where split DNS is present, selection of the correct
destination and source addresses for the actual IP connection becomes
crucial, as the resolved destination's IP address may be only usable
on the network interface over which it was resolved on. It may be an
useful optimization for a host to remember which destination address
was resolved based on a matching DNS suffix, and for such addresses
follow tighter source address selection logic. However, the source
address selection logic is out of 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].
Savolainen Expires December 9, 2010 [Page 3]
Internet-Draft MIF and DNS server selection June 2010
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 provides a
solution. (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
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 private 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 =======| 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
Savolainen Expires December 9, 2010 [Page 4]
Internet-Draft MIF and DNS server selection June 2010
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
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 Expires December 9, 2010 [Page 5]
Internet-Draft MIF and DNS server selection June 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.
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 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. DNS server selection procedure
This chapter documents a procedure a (stub) resolver may utilize for
DNS server selection on split-DNS scenarios.
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'
or 'page not found'? Maybe DNSSEC would help here, i.e. roll through
Savolainen Expires December 9, 2010 [Page 6]
Internet-Draft MIF and DNS server selection June 2010
DNS servers until one provides a response that can be validated?)
To prioritize DNS servers in an optimal way, the resolver may learn
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.
By default, the resolver shall assume that all information is
available from any DNS server of any network interface.
Additionally, the resolver can utilize any other 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), or any other piece of
information.
When a resource record is to be resolved, the resolver shall give
highest precedence to the DNS servers explicitly known to serve
matching suffixes or prefixes. A host may need to remember when a
query succeeds that matched to a DNS suffix in order to be able to
perform source address selection better.
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 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.
The resolver 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 third parties.
o It may be a privacy issue as it would reveal all names host is
resolving to all DNS servers.
Savolainen Expires December 9, 2010 [Page 7]
Internet-Draft MIF and DNS server selection June 2010
3.1. DNS server selection policy distribution with a DHCPv6 option
A DHCPv6 option is defined to assist in DNS server selection. The
option informs clients about which DNS server should be contacted
when initiating forward or reverse DNS lookup procedures.
Savolainen Expires December 9, 2010 [Page 8]
Internet-Draft MIF and DNS server selection June 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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-length | |
+-+-+-+-+-+-+-+-+ IPv6 prefix |
| (16 octets) |
| |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
| 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
prefix-length: Length of the IPv6 prefix in bits
IPv6 prefix: The IPv6 prefix DNS server has special reverse
lookup information for
DNS suffixes: The list of DNS suffixes the DNS server has
special knowledge about. Field 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 4
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, or if a DNS
server has special reverse lookup knowledge for more than one
Savolainen Expires December 9, 2010 [Page 9]
Internet-Draft MIF and DNS server selection June 2010
aggregatable IPv6 prefix.
The IPv6 prefix MUST cover all the DNS suffixes configured in this
option. The prefix SHOULD NOT be unnecessarily short, otherwise it
may accidentally collide with information received on other option
instances or with options received from DHCPv6 servers on other
interfaces. Overlapping IPv6 prefixes are interpreted 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. (DISCUSS: When DNSSEC is used, in
split-DNS case it is probably possible to have authoritative answers
for both existence and non-existence of a record, depending on the
interface question is sent on?)
3.2. Changes to DNS resolution procedures
When a stub DNS resolver in a host is requested by an application to
do forward or reverse DNS lookup, the resolver should look if any of
the configured DNS servers is known to have, or likely have,
information matching to the particular query. 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. To avoid accidental use of synthesized
IPv6 addresses in the dual-stack case, the resolver may prioritize
DNS servers' IPv4 addresses over IPv6 addresses.
3.3. Example of a host behavior
Figure 5 illustrates host behavior when it initializes two network
interfaces for parallel usage and learns DNS suffix and prefix
information from DHCPv6 servers.
Savolainen Expires December 9, 2010 [Page 10]
Internet-Draft MIF and DNS server selection June 2010
Application Host 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 host opens its first network interface
2. The host obtains DNS suffix and IPv6 prefix information for the
new interface 1 from DHCPv6 server
3. The host stores the learned DNS suffixes and IPv6 prefixes for
later use
4. The host opens its seconds network interface 2
5. The host obtains DNS suffix, say 'example.com', and IPv6 prefix
information for the new interface 2 from DHCPv6 server
Savolainen Expires December 9, 2010 [Page 11]
Internet-Draft MIF and DNS server selection June 2010
6. The host stores the learned DNS suffixes 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 Host 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 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 DHCPv6 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 an IPv6 address
4. The host replies to application with the resolved IPv6 address
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
Savolainen Expires December 9, 2010 [Page 12]
Internet-Draft MIF and DNS server selection June 2010
DNS.
Network administrators deploying split DNS should assist advanced
hosts in the DNS server selection by configuring their DHCP servers
with proper DNS suffix and prefix information. To ensure hosts'
source and destination IP address selection works correctly, network
administrators should also consider deployment of additional
technologies to help with that.
5. Further considerations
Overloading of existing DNS search list options as described in
Appendix A 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. To avoid overloading of existing options, this document
proposes standardization of a completely new DHCPv6 option.
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, Peter Koch and Dan
Wing.
This document was prepared using xml2rfc template and related web-
tool.
7. IANA Considerations
This memo includes a new DHCPv6 option that requires allocation of a
new code point.
8. Security Considerations
An attacker may try to lure traffic from multi-homed host to his
network by advertising DNS suffixes and prefixes 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
Savolainen Expires December 9, 2010 [Page 13]
Internet-Draft MIF and DNS server selection June 2010
conflicting policies. The prioritization could be based on trust
level of a network interface over which policy 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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
9.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-09 (work in progress), March 2010.
[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.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces Problem
Statement", draft-ietf-mif-problem-statement-04 (work in
progress), May 2010.
[I-D.wing-behave-dns64-config]
Wing, D., "DNS64 Resolvers and Dual-Stack Hosts",
draft-wing-behave-dns64-config-02 (work in progress),
Savolainen Expires December 9, 2010 [Page 14]
Internet-Draft MIF and DNS server selection June 2010
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.
[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Option for DNS Configuration",
RFC 5006, September 2007.
Appendix A. Best effort DNS server selection
On some split-DNS deployments explicit policies for DNS server
selection may not be available. This section proposes ways for hosts
to mitigate the problem by using possibly existing indirect
information elements for the same purposes as the explicit DHCPv6
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.
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
Savolainen Expires December 9, 2010 [Page 15]
Internet-Draft MIF and DNS server selection June 2010
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
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).
Author's Address
Teemu Savolainen
Nokia
Hermiankatu 12 D
TAMPERE, FI-33720
FINLAND
Email: teemu.savolainen@nokia.com
Savolainen Expires December 9, 2010 [Page 16]