One document matched: draft-ietf-mif-dns-server-selection-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3397 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3397.xml">
<!ENTITY RFC3646 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml">
<!ENTITY RFC2767 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2767.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC4191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml">
<!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC5006 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5006.xml">
<!ENTITY RFC3152 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3152.xml">
<!ENTITY I-D.ietf-mif-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mif-problem-statement.xml">
<!ENTITY I-D.ietf-behave-dns64 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-dns64.xml">
<!ENTITY I-D.wing-behave-dns64-config SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-behave-dns64-config.xml">
<!ENTITY I-D.troan-multihoming-without-nat66 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.troan-multihoming-without-nat66.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-mif-dns-server-selection-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="MIF and DNS server selection">Improved DNS Server Selection for Multi-Homed Nodes</title>
<author fullname="Teemu Savolainen" initials="T.S."
surname="Savolainen">
<organization>Nokia</organization>
<address>
<postal>
<street>Hermiankatu 12 D</street>
<code>FI-33720</code>
<city>TAMPERE</city>
<region></region>
<country>FINLAND</country>
</postal>
<email>teemu.savolainen@nokia.com</email>
</address>
</author>
<author fullname="Jun-ya Kato" initials="J.T."
surname="Kato">
<organization>NTT</organization>
<address>
<postal>
<street>9-11, Midori-Cho 3-Chome Musashino-Shi</street>
<code>180-8585</code>
<city>TOKYO</city>
<region></region>
<country>JAPAN</country>
</postal>
<email>kato@syce.net</email>
</address>
</author>
<date month="January" year="2011" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>DNS, interface, FQDN, selection</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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 helping on selection of DNS
server for both forward and reverse DNS lookup procedures with help of DNS
suffix and IPv6 prefix information received via DHCPv6.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>A multi-homed node faces several problems over single-homed node as is described
in <xref target="I-D.ietf-mif-problem-statement"></xref>.
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.</t>
<t>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.</t>
<t>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. </t>
<t>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.</t>
<t>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.</t>
<t>Node multihoming in general may introduce new attack vectors. This document
includes security considerations that will help against possible
new attack vectors and also to some existing attack vectors.</t>
<t>The Appendix A describes best current practices possible with tools preceding this
document and on networks not supporting this specification. As it is possible to
solve the problem with less efficient and less explicit manners, this document can be considered
as an optimization. However, in some environments this optimization is considered essential.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Problem description for local namespaces with multi-homed nodes">
<t>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 <xref target="I-D.troan-multihoming-without-nat66"/>.</t>
<section title="Fully qualified domain names with limited scopes">
<t>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.</t>
<figure align="center" anchor="xml_fig1">
<preamble></preamble>
<artwork align="left"><![CDATA[
+---------------+
| 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 | |
+---------------+
]]></artwork>
<postamble>Split DNS and locally scoped names illustrated</postamble>
</figure>
</section>
<section title="Network interface specific IP addresses">
<t>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.</t>
<figure align="center" anchor="xml_fig2">
<preamble></preamble>
<artwork align="left"><![CDATA[
+--------------------| |
+------+ 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
+--------------------+ |
]]></artwork>
<postamble>Split DSN and different IP addresses
for an FQDN on interfaces 1 and 2.</postamble>
</figure>
<t>Similar situation can happen when IPv6 protocol translation is used in combination
with AAAA record synthesis proceduce <xref target="I-D.ietf-behave-dns64"></xref>.
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 <xref target="RFC2767">Bump-In-the-Stack</xref>.</t>
<t>For a related problem for dual-stack hosts in a network with DNS64, where
IPv4 should be prioritized over synthesized IPv6, please see
<xref target="I-D.wing-behave-dns64-config"></xref>.</t>
<figure align="center" anchor="xml_fig_AAAA">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-------------------| +-------+
+------+ 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 |
+-------------------+ +-------+
]]></artwork>
<postamble>AAAA synthesis results in interface specific
IPv6 addresses.</postamble>
</figure>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="Improved DNS server selection">
<t>This chapter describes a procedure a (stub / proxy) resolver may utilize for improved DNS server
selection in face of multiple namespaces and multiple simultaneously active network interfaces.
</t>
<section title="Procedure for prioritizing DNS servers and handling responses">
<t>The resolver SHALL dynamically build for each DNS query a priority list of DNS servers it
will contact to. To prioritize DNS servers in safe and optimal way, a node SHOULD ask
with DHCPv6 which DNS servers of each network interface are most likely able to successfully serve
forward lookup requests matching to specific DNS suffixes or reverse (PTR record) lookup
requests matching to specific IPv6 prefixes.
</t>
<t>A resolver lacking more explicit information shall assume that all information is
available from any DNS server of any network interface. The DNS servers learnt by other DNS server
address configuration methods MUST be handled as medium priority default servers.
</t>
<t>When a resource record is to be resolved, the resolver SHOULD give highest precedence to
the DNS servers explicitly known to serve matching suffixes or prefixes. However,
the resolver MUST take into account different trust levels
of pieces of DNS server selection information the resolver has received from node's network interfaces. The resolver
MUST generally prefer more trusted DNS servers and less trusted DNS server MAY be of highest
priority only if trusted interfaces specifically configure DNS servers with low priority. The
non-exhaustive list on table 1 illustrates how the different trust levels of received DNS server selection
information MUST influence the DNS server selection logic.
</t>
<figure title="DNS server selection in case of different trust levels" anchor="Table 1"><artwork><![CDATA[
Information from | Information from | Resulting DNS
from more trusted | less trusted | server priority
interface A | interface B | selection
--------------------------+------------------------+--------------------
1. Medium priority | Medium priority | Default: A, then B
default | default |
--------------------------+------------------------+--------------------
2. Medium priority | High priority default | Default: A, then B
default | High priority specific | Specific: A, then B
--------------------------+------------------------+--------------------
3. Low priority default | Medium priority | Default: B, then A
| default |
--------------------------+------------------------+--------------------
4. Low priority default | Medium priority | Default: B, then A
High priority specific | default | Specific: A, then B
--------------------------+------------------------+--------------------
]]></artwork></figure>
<t>The resolver SHOULD avoid sending queries to different interfaces in parallel as that may waste
resources, sometimes significantly, and would also unnecessary reveal information about ongoing communications.
Independently of whether DNS queries are sent in series or parallel, replies for DNS queries MUST be waited until
acceptable positive reply is received, all replies are received, or time out occurs.
Specifically, the resolver MUST NOT proceed with a positive reply from less trusted server that cannot be
validated with DNSSEC if the DNS query sent to more trusted server is still pending.
(DISCUSS: What about those DNS servers that instead of negative answer always return positive reply with an
IP address of some captive portal?)
</t>
<t>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.
</t>
<t>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.
</t>
<t>Resolver SHOULD use DNSSEC to validate all received DNS replies. In the case DNSSEC validation fails the resolver MUST resend
the query to the next preferred DNS server.
</t>
</section>
<section title="DNS server selection option">
<t>A DHCPv6 option described below is used to inform resolvers which DNS server should be contacted
when initiating forward or reverse DNS lookup procedures.</t>
<figure align="center" anchor="xml_figDHCPv6new">
<preamble></preamble>
<artwork align="left"><![CDATA[
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
The preference is used when selecting between
equally trusted DNS servers.
(Editor's note: this field is under consideration
- really needed or not?)
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].
]]></artwork>
<postamble>DHCPv6 option for explicit DNS suffix configuration</postamble>
</figure>
<t>A node SHOULD include an OPTION_ORO option in DHCPv6 request with the
OPTION_DNS_SERVER_SELECT option code to inform the DHCPv6 server about the support for
the improved DNS server selection logic. DHCPv6 server receiving this information MAY then choose
to provision DNS server addresses only with OPTION_DNS_SERVER_SELECT.
</t>
<t>The OPTION_DNS_SERVER_SELECT contains one or more DNS suffixes the 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.
</t>
<t>A resolver SHOULD prioritize between equally trusted DNS servers with help of the preference field. The resolver
MUST NOT prioritize less trusted DNS servers higher than trusted, even in the case of less trusted
server would apprently have additional information. In case all other things being equal the resolver shall
make the prioritization decision based on its internal preferences.</t>
<t>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 so that the resolver can use any or all of the
DNS servers for queries mathing the prefixes. </t>
<t>As the DNS options of <xref target="RFC3646"></xref>, 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.</t>
<t>The node SHOULD create a host specific route for the DNS server address. The route must point
to the interface DNS server address was learned on. This is required to ensure DNS queries are
sent out via the right interface. </t>
<t>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. </t>
</section>
<section title="Coexistence with RFC3646">
<t>The OPTION_DNS_SERVER_SELECT is designed to coexist with OPTION_DNS_SERVERS defined
in <xref target="RFC3646"></xref>. The DNS servers configured via OPTION_DNS_SERVERS MUST BE considered
as default name servers with medium preference. When both options are received from the same
network interface and the OPTION_DNS_SERVER_SELECT contains default DNS server address,
the resolver SHOULD make decision which one to prefer based on preferences. If
OPTION_DNS_SERVER_SELECT defines medium preference then DNS server selection decision
is implementation specific. All default servers are assumed to be able to resolve queries for
global names.
</t>
<t>If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain the same DNS server(s) IPv6 address(es),
only one instance of each DNS servers' IPv6 addresses shall be added to the DNS server list.
</t>
<t>If a node had indicated support for OPTION_DNS_SERVER_SELECT in DHCPv6 request, the DHCPv6 server
may choose to omit sending of OPTION_DNS_SERVERS. This enables offloading use case where
network administrator wishes to only advertise low priority default DNS servers.
</t>
</section>
</section>
<section title="Example of a node behavior">
<t>Figure 5 illustrates node behavior when it initializes two network interfaces for parallel usage and
learns DNS suffix and prefix information from DHCPv6 servers.</t>
<figure align="center" anchor="xml_fig5">
<preamble></preamble>
<artwork align="left"><![CDATA[
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 | | |
| +----------+ | |
| | | |
]]></artwork>
<postamble>Illustration of learning DNS suffixes</postamble>
</figure>
<t>Flow explanations:</t>
<t><list style="numbers">
<t>A node opens its first network interface</t>
<t>The node obtains DNS suffix and IPv6 prefix information for the new interface 1 from DHCPv6 server</t>
<t>The node stores the learned DNS suffixes and IPv6 prefixes for later use</t>
<t>The node opens its seconds network interface 2</t>
<t>The node obtains DNS suffix, say 'example.com', and IPv6 prefix
information, say '8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 2 from DHCPv6 server</t>
<t>The node stores the learned DNS suffixes and prefixes for later use</t>
</list></t>
<t>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.</t>
<figure align="center" anchor="xml_fig6">
<preamble></preamble>
<artwork align="left"><![CDATA[
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-| | |
| | | |
]]></artwork>
<postamble>Example on choosing interface based on DNS suffix</postamble>
</figure>
<t>Flow explanations:</t>
<t><list style="numbers">
<t>An application makes a request for resolving an FQDN, e.g. 'private.example.com'</t>
<t>A node creates list of DNS servers to contact to and uses configured DNS server information and stored DNS suffix information on priorization decisions.</t>
<t>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</t>
<t>The node replies to application with the resolved IPv6 address</t>
</list></t>
</section>
<section title="Scalability considerations">
<t>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. </t>
</section>
<section title="Considerations for network administrators">
<t>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.</t>
<t>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.</t>
<t>To mitigate against attacks against local namespaces, administrators utilizing this tool should deploy DNSSEC for their zone.</t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The author would like to thank following people for their valuable feedback and improvement ideas:
Mark Andrews, Jari Arkko, Marcelo Bagnulo, Stuart Cheshire, Lars Eggert, Tomohiro Fujisaki, Peter Koch, Suresh Krishnan,
Edward Lewis, Kurtis Lindqvist, Arifumi Matsumoto, Erik Nordmark, Steve Padgett, Fabien Rapin, Dave Thaler, Margaret Wasserman, Dan Wing,
and Dec Wojciech. Ted Lemon and Julien Laganier receive special thanks for their contributions to security considerations.</t>
<t>This document was prepared using xml2rfc template and the related web-tool.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes a new DHCPv6 option that requires allocation of a new code point.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>It is possible that attackers might try to utilize OPTION_DNS_SERVER_SELECT
option to redirect some or all DNS queries sent by a resolver
to undesired destinations. The purpose of an attack might be denial-of-service,
preparation for man-in-the-middle attack, or something akin.
</t>
<t>Attackers might try to lure specific traffic by advertising DNS suffixes
and prefixes from very small to very large scope or simply by trying to place attacker's
DNS server as the highest priority default server.
</t>
<t>The main countermeasure against these attacks is to systematically prioritize more trusted DNS
servers higher than less trusted ones. Additionally, resolvers should implement DNSSEC
to be able to validate DNS responses received via any of its interfaces.
</t>
<t>Decision on trust levels of network interfaces depends very much on deployment scenario and
types of network interfaces. For example, unmanaged WLAN may be considered less trustworthy
than managed cellular or VPN connections.
</t>
<t>A node MAY also choose, or be configured, to obtain DNS server selection rules only from selected trusted
interfaces, in which case it would be in the hands of administrators of these trusted
interfaces whether or not to allow redirection, offloading, of DNS queries to untrusted
interfaces (case 4 of table 1).
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC3315;
&RFC3152;
</references>
<references title="Informative References">
&I-D.ietf-behave-dns64;
&I-D.wing-behave-dns64-config;
&I-D.ietf-mif-problem-statement;
&I-D.troan-multihoming-without-nat66;
&RFC2767;
&RFC5006;
&RFC3397;
&RFC3646;
&RFC4191;
&RFC4193;
</references>
<section anchor="app-additional" title="Best Current Practice for DNS server selection">
<t>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 sending wide-spread queries and
by utilizing possibly existing indirect information elements as hints.</t>
<section title="Sending queries out on multiple interfaces in parallel">
<t>A possible current practice is to send DNS queries out of multiple interfaces
and pick up the best out of the received responses. A host SHOULD implement DNSSEC
in order to be able to reject responses that cannot be validated. Selection
between legitimate answers is implementation specific, but positive replies should
be preferred.</t>
<t>A downside of this approach is increased consumption of resources. Namely power
consumption if an interface, e.g. wireless, has to be brought up just for the
DNS query that could have been resolved also via cheaper interface. Also load
on DNS servers is increased. However, local caching of results mitigates these
problems, and a node might also learn interfaces that seem to be able to provide
more responses than other and prefer those - without forgetting fallback required
for cases when node is connected to more than one network using local namespaces.</t>
<t>Another downside is revealing to all DNS servers the names a host is connecting to.
For example, a DNS server of public hotspot could learn all the private names host
is trying to connect on other interfaces. </t>
</section>
<section title="Search list option for DNS forward lookup decisions">
<t>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.</t>
<t>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.</t>
</section>
<section title="More specific routes for reverse lookup decision">
<t><xref target="RFC4191"></xref> 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
<xref target="RFC5006"></xref> as the more specific route information.</t>
</section>
<section title="Longest matching prefix for reverse lookup decision">
<t>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 <xref target="RFC4193"></xref> addresses are used and when the queried address belongs
to a host or server within the same network (for example intranet).</t>
</section>
</section>
<!-- Change Log
v00 2009-02-13 TS First version, sending for internal review
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:17 |