One document matched: draft-ietf-mif-dns-server-selection-07.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 RFC1533 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1533.xml">
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2317 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2317.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 RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3396 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3396.xml">
<!ENTITY RFC3736 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736.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 RFC4242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.xml">
<!ENTITY RFC3152 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3152.xml">
<!ENTITY RFC6147 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6147.xml">
<!ENTITY RFC6106 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6106.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.wing-behave-dns64-config SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-behave-dns64-config.xml">
<!ENTITY I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat.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-07" 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-Interfaced 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>
<author fullname="Ted Lemon" initials="T.L."
surname="Lemon">
<organization>Nominum, Inc.</organization>
<address>
<postal>
<street>2000 Seaport Boulevard</street>
<code>CA 94063</code>
<city>Redwood City</city>
<region></region>
<country>USA</country>
</postal>
<phone>+1 650 381 6000</phone>
<email>Ted.Lemon@nominum.com</email>
</address>
</author>
<date month="October" 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-interfaced node is connected to multiple networks, some of which
may be utilizing private DNS namespaces.
A node commonly 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 a
multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to
contact to. This document describes DHCPv4 and DHCPv6 options that can be
used to configure nodes with information required to perform
informed DNS server selection decisions.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>A multi-interfaced node faces several problems a single-homed node does not encounter, as is described
in <xref target="I-D.ietf-mif-problem-statement"></xref>.
This document studies in detail the problems private namespaces may cause for multi-interfaced nodes
and provides a solution. The node may be implemented as a host or as a router.</t>
<t>We start from the premise that network operators sometimes include private namespaces in the answers they
provide from DNS servers, and that those private namespaces are at least as useful to nodes as the
answers from the public DNS. When private namespaces are visible for a node, some DNS servers have
information other servers do not have. The node ought to be able to ask right server for the
information it needs.</t>
<t>An example of an application that benefits from multi-interfacing is a
web browser that commonly accesses many different destinations,
each of which is available only on one network. The browser
therefore needs to be able to communicate over different network
interfaces, depending on the destination it is trying to reach.</t>
<t>In deployments where private namespaces are present, selection of correct route and destination
and source addresses for the actual IP connection is crucial as well, as the resolved
destination's IP addresses may be only usable on the network interface over which the name was
resolved on. Hence solution described in this document is assumed to be commonly used in
combination with tools for delivering additional routing and source and destination address selection
policies.</t>
<t>This document is organized in the following manner. Background information about problem descriptions and example deployment scenarios are
included in <xref target="problems"/> and <xref target="scenarios"/>. <xref target="dnsselection"/> contains all normative descriptions
for DHCP options and node behavior. Informative <xref target="examples"/> illustrates behavior of a node implementing
functionality described in the <xref target="dnsselection"/>.
<xref target="scalability"/> contains informational considerations about scalability.
<xref target="admins"/> contains normative guidelines related to creation of private namespaces.
Informational <xref target="Security"/> summarizes identified security considerations.</t>
<t>The Appendix A describes best current practices possible with tools preceding this
document and that may be possibilities on networks not supporting the solution described in this document. </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="Private namespaces and problems for multi-interfaced nodes" anchor="problems">
<t>This section describes two node multi-interfacing related private namespace scenarios for which
the procedure described in <xref target="dnsselection"/> provides a solution for. Additionally, <xref target="notsolved"/> describes
a problem for which this document provides only partial solution.</t>
<section title="Fully qualified domain names with limited scopes">
<t>A multi-interfaced node may be connected to one or more networks that are using
private namespaces. As an example, the node may have simultaneously
open a wireless LAN (WLAN) connection to the 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 node needs to be
able to choose the right DNS server 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,
but for an FQDN of corporation's or operator's service's private name
the node needs to be able to correctly select the right DNS server for the DNS resolution,
i.e. do also network 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 =======| private names | |
| | +---------------+ +----+
| MIF | | FW |
| node | +----+
| | +---------------+ |
| |----- WLAN ------| DNS server w/ |----| Public
| | | public names | | Internet
| | +---------------+ +----+
| | | FW |
| | +---------------+ +----+
| |---- cellular ---| DNS server w/ | |
+------+ | public + | | Operator
| operator's |----| Intranet
| private names | |
+---------------+
]]></artwork>
<postamble>Private DNS namespaces illustrated</postamble>
</figure>
</section>
<section title="Network interface specific IP addresses">
<t>In the second problem an FQDN 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.
Node's routing and 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 | +--------------------+ +------+
| node | | Peer |
| | +--------------------+ +------+
| | IPv6 | DNS server B | |
| |-- interface 2 --| saying Peer is | |
+------+ | at: 2001:0db8:1::1 |------| IPv6
+--------------------+ |
]]></artwork>
<postamble>Private DNS namespaces and different IP addresses
for an FQDN on interfaces 1 and 2.</postamble>
</figure>
<t>Similar situation can happen with IPv6 protocol translation and AAAA record synthesis
<xref target="RFC6147"></xref>.
A synthetic AAAA record is guaranteed to be valid only on a network
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.</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 | +-------------------+ | +------+
| node | IPv4 +---| Peer |
| | +-------------------+ | +------+
| | IPv6 | DNS server B | |
| |-- interface 2 --| saying Peer is | +-------+
+------+ | at: B_Pref96:IPv4 |----| NAT64 |
+-------------------+ +-------+
]]></artwork>
<postamble>AAAA synthesis results in network interface specific
IPv6 addresses.</postamble>
</figure>
<t>It is worth noting is that network specific IP addresses can cause problems
also for a single-homed node, if the node retains DNS cache during movement
from one network to another. After the network change, a node
may have entries in its DNS cache that are no longer correct or appropriate for its
new network position.</t>
</section>
<section title="A problem not fully solved by the described solution" anchor="notsolved">
<t>A more complex scenario is an FQDN, which in addition to possibly resolving into
network interface specific IP addresses, identifies on different network interfaces
completely different peer entities with potentially different set of service offerings. 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, these problems may be solvable only by manual user intervention.</t>
<t>However, when DNSSEC is used, the DNSSEC validation procedure may provide
assistance for selecting correct responses for some, but not all, use cases. A node may prefer to use
the DNS answer that validates with the preferred trust anchor.</t>
</section>
</section>
<section title="Deployment scenarios" anchor="scenarios">
<t>This document has been written with three particular deployment scenarios in mind. First
being a Consumer Premises Equipment (CPE) with two or more uplink VLAN connections. Second
scenario involves a cellular device with two uplink Internet connections: WLAN and cellular.
Third scenario is for VPNs, where use of local DNS server may be preferred for latency reasons,
but corporate DNS server must be used to resolve private names used by the corporation.
</t>
<section title="CPE deployment scenario">
<t>A home gateway may have two uplink connections leading to different networks, as is
described in <xref target="I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat"/>. In the two uplinks scenario
only one uplink connection leads to the Internet, while another uplink connection
leads to a private network utilizing private namespaces.
</t>
<t>It is desirable that the CPE does not have to send DNS queries over
both uplink connections, but instead CPE should send default queries to the
DNS server of the interface leading to the Internet, and queries related to private
namespace to the DNS server of the private network.
</t>
<t>In this scenario the legacy hosts can be supported by deploying DNS proxy on the
CPE and configuring hosts in the LAN to talk to the DNS proxy. However, updated hosts
would be able to talk directly to the correct DNS servers of each uplink ISP's
DNS server. It is deployment decision whether the updated hosts would be pointed
to DNS proxy or to actual DNS servers.
</t>
<t>Depending on actual deployments, all VLAN connections might be considered as trusted.</t>
</section>
<section title="Cellular network scenario">
<t>A cellular device may have both WLAN and cellular network interfaces up. In such
a case it is often desirable to use WLAN by default, except for those connections
cellular network operator wants to go over cellular interface. The
cellular network may utilize private names and hence the cellular device needs
to ask for those through the cellular interface.
</t>
<t>In this scenario cellular interface can be considered trusted and WLAN oftentimes untrusted.</t>
</section>
<section title="VPN scenario">
<t>
Depending on a deployment, there may be interest to use VPN only
for the traffic destined to a corporate network. The corporation may be using private
namespace, and hence related DNS queries should be send over VPN to the corporate
DNS server, while by default a DNS server of a local access network may be used.
</t>
<t>
In this scenario VPN interface can be considered trusted and local access network
untrusted.
</t>
</section>
<section title="Dual-stack accesses">
<t>
In all three scenarios one or more of the connected networks may support both IPv4 and IPv6.
In such a case both or either of DHCPv4 and DHCPv6 can be used to learn
DNS server selection information.
</t>
</section>
</section>
<section title="Improved DNS server selection" anchor="dnsselection">
<t>This section describes DHCP options and a procedure that a (stub / proxy) resolver may utilize for improved DNS server
selection in the face of private namespaces and multiple simultaneously active network interfaces.
</t>
<section title="Procedure for prioritizing DNS servers and handling responses">
<t>A resolver SHALL build a priority list of DNS servers it
will contact to depending on the query. To build the list in an optimal way, a node SHOULD ask
with DHCP which DNS servers of each network interface are most likely to be able to successfully serve
forward lookup requests matching to specific domain or reverse (PTR record) lookup
requests matching to specific network addresses (later referred as "network").
For security reasons the DNS server selection information MUST be used only when it is safe to do
so, see <xref target="uselimitations"/> for details.
</t>
<t>The node SHOULD create a node specific route for the DNS server addresses learned via DHCP. 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 network interface. </t>
<t>A resolver lacking more specific 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 DNS query needs to be made, the resolver SHOULD give highest precedence to
the DNS servers explicitly known to serve matching domain or network. The resolver MUST take
into account differences in trust levels of pieces of received DNS server selection information.
The resolver
MUST prefer DNS servers of trusted interfaces. The DNS servers of untrusted interfaces may be of highest
priority only if trusted interfaces specifically configure low priority DNS servers. The
non-exhaustive list on figure 4 illustrates how the different trust levels of received DNS server selection
information SHOULD influence the DNS server selection logic.
</t>
<t>Trustworthiness of an interface and configuration information received over the interface is
implementation and/or node deployment dependent. Trust may be based on, for example, on the nature of an interface. For example,
an authenticated and encrypted VPN or layer 2 connections to a trusted home network may be considered as trusted, and
an unauthenticated and unencrypted connection to an unknown visited network may be considered as untrusted. In some occasions
an interface may be considered trusted only if explicitly configured to be trusted.</t>
<t>A resolver SHOULD prioritize between equally trusted DNS servers with help of the DHCP option preference field. The resolver
MUST NOT prioritize less trusted DNS servers higher than trusted, even in the case of less trusted
server would apparently have additional information. In the case of all other things being equal the resolver shall
make the prioritization decision based on its internal preferences.</t>
<figure title="DNS server selection in the case of different trust levels" anchor="Table1"><artwork><![CDATA[
Information from | Information from | Resulting DNS
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>Because DNSSEC provides cryptographic assurance of the integrity of
DNS data, data that can be validated under DNSSEC is necessarily to
be preferred over data that cannot be. There are two ways that a
node can determine that data is valid under DNSSEC. The first is
to perform DNSSEC validation itself. The second is to have a
secure connection to an authenticated DNS server, and to rely on
that DNS server to perform DNSSEC validation (signalling that it
has done so using the AD bit). If a DNS response is not proven to
be unmolested using DNSSEC, then a node cannot make a decision to
prefer data from any interface with any great assurance: any
response could be forged, and there is no way to detect the forgery
without DNSSEC.</t>
<t>A node SHALL send requests to DNS servers in the order defined by the priority list
until an acceptable reply is received, all replies are received, or
a time out occurs. In the case of a requested name matching to a
specific domain or network rule accepted from any interface, a DNSSEC-aware
resolver MUST NOT proceed
with a reply that cannot be validated using DNSSEC until all DNS
servers on the priority list have been contacted or timed out. This protects
against possible redirection attacks. In
the case of the requested name not matching to any specific domain or
network, first received response from any DNS server MAY be considered
acceptable. A DNSSEC-aware node MAY always contact all DNS server in an
attempt to receive a response that can be validated, but contacting all
DNS servers is not mandated for the default case as in some deployments
that would consume excess resources.</t>
<t>The resolver SHOULD avoid sending queries over different network interfaces in parallel as that wastes
resources such as energy. The amount of wasted energy can be significant, for example when
radio interfaces has to be started just for the queries.</t>
<t>In the case of validated NXDOMAIN response being received from a DNS server
that can provide answers for the queried name a node MUST NOT
accept non-validated replies from other DNS servers (see Appendix B for considerations
related to multiple trust anchors.</t>
</section>
<section title="DNS server selection DHCPv6 option">
<t>DHCPv6 option described below can be 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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |prf| |
+-+-+-+-+-+-+-+-+ Domains and networks |
| (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DNS_SERVER_SELECT (TBD)
option-len: Length of the option in octets
DNS-recursive-name-server: An IPv6 address of a recursive DNS server
Reserved: Field reserved for the future. MUST be set to zero.
prf: DNS server preference, for selecting between
equally trusted DNS servers:
01 High
00 Medium
11 Low
10 Reserved
Domains and networks: The list of domains for forward DNS
lookup and networks 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].
Special domain of "." is used to indicate
capability to resolve global names and act as a
default name server. Lack of "."
domain on the list indicates DNS server only has
information related to listed domains and networks.
Networks for reverse mapping are encoded as
defined for ip6.arpa [RFC3152] or in-addr.arpa [RFC2317].
]]></artwork>
<postamble>DHCPv6 option for explicit domain configuration</postamble>
</figure>
<t>A node SHOULD include an OPTION_ORO option in a 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 the OPTION_DNS_SERVER_SELECT.
</t>
<t>The OPTION_DNS_SERVER_SELECT contains one or more domains the related DNS server has particular
knowledge of. The option can occur multiple times in a single DHCPv6 message,
if multiple DNS servers are to be configured.
</t>
<t>IPv6 networks should cover all the domains configured in this option. Networks should be as
long as possible to avoid potential collision with information received on other option
instances or with options received from DHCPv6 servers of other network interfaces. Overlapping
IPv6 networks are interpreted so that the resolver can use any of the
DNS servers for queries matching the networks. </t>
<t>If the OPTION_DNS_SERVER_SELECT contains a DNS server address already learned from other DHCPv6 servers
of the same network, and contains new domains or networks, the node SHOULD append the information to the
information received earlier. The node MUST NOT remove previously obtained information. However, the
node SHOULD NOT extent lifetime of earlier information either. In the case of conflicting DNS server
address is learned from less trusted interface, the node MUST ignore the option.</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 DHCPv6 messages: Solicit, Advertise, Request, Renew,
Rebind, Information-Request, and Reply.</t>
<t>The information conveyed in OPTION_DNS_SERVER_SELECT is considered valid until changed
or refreshed by general events that trigger DHCPv6 action. In the event that it is desired
for the client to request a refresh of the information, use of generic DHCPv6 Information
Refresh Time Option, as specified in <xref target="RFC4242"/> is RECOMMENDED.</t>
</section>
<section title="DNS server selection DHCPv4 option">
<t>DHCPv4 option described below can be used to inform resolvers which DNS server should be contacted
when initiating forward or reverse DNS lookup procedures.</t>
<figure align="center" anchor="xml_figDHCPv4new">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CODE | Len | Reserved |prf| Primary .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. DNS-recursive-name-server's IPv4 address | Secondary .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. DNS-recursive-name-server's IPv4 address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+ Domains and networks |
| (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DNS_SERVER_SELECT (TBD)
option-len: Length of the option in octets
Reserved: Field reserved for the future. MUST be set to zero.
prf: DNS servers preference, for selecting between
equally trusted DNS servers:
01 High
00 Medium
11 Low
10 Reserved
Primary DNS-recursive-name-server's IPv4 address: Address of
a primary recursive DNS server
Secondary DNS-recursive-name-server's IPv4 address: Address of
a secondary recursive DNS server or 0.0.0.0 if
not configured.
Domains and networks: The list of domains for forward DNS lookup
and networks for reverse DNS lookup the DNS servers
have special knowledge about. Field MUST be encoded as
specified in Section "Representation and use of
domain names" of [RFC3315].
Special domain of "." is used to indicate
capability to resolve global names and act as
default name servers. Lack of "."
domain on the list indicates DNS servers only have
information related to listed domains and networks.
Networks for reverse mapping are encoded as
defined for ip6.arpa [RFC3152] or in-addr.arpa [RFC2317].
]]></artwork>
<postamble>DHCPv4 option for explicit domain configuration</postamble>
</figure>
<t>The OPTION_DNS_SERVER_SELECT contains one or more domains the primary and
secondary DNS servers have particular knowledge of. If the length of the
domains and networks field causes option length to exceed the maximum
permissible for a single option (255 octets), then multiple
options MAY be used, as described in "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)" <xref target="RFC3396"/>.
When multiple options are present, the data portions of all option
instances are concatenated together.
</t>
<t>If the OPTION_DNS_SERVER_SELECT contains a DNS server address already learned from other DHCPv4 servers
of the same network, and contains new domains or networks, the node SHOULD append the information to the
information received earlier. The node MUST NOT remove previously obtained information. However, the
node SHOULD NOT extent lifetime of earlier information either. In the case of conflicting DNS server
address is learned from less trusted interface, the node MUST ignore the option.</t>
</section>
<section title="Limitations on use" anchor="uselimitations">
<t>Use of OPTION_DNS_SERVER_SELECT is ideal in the following environments,
but SHOULD NOT be enabled by default otherwise:</t>
<t>1. The server selection option is delivered across a secure, trusted channel.</t>
<t>2. The server selection option is not secured, but the client on a node does DNSSEC validation.</t>
<t>3. The server selection option is not secured, the resolver does DNSSEC
validation, and the client communicates with the resolver configured
with server selection option over a secure, trusted channel.</t>
<t>4. The DNS server IP address that is being recommended in the server
selection option is known and trusted by the client; that is, the
server selection option serves not to introduce the client to a new
server, but rather to inform it that a server it has already been
configured to trust is available to it for resolving certain domains.</t>
</section>
<section title="Coexistence with RFC3646 and RFC1533">
<t>The OPTION_DNS_SERVER_SELECT is designed to coexist with DHCPv6 OPTION_DNS_SERVERS defined
in <xref target="RFC3646"></xref> and DHCPv4 Domain Name Server Option defined in <xref target="RFC1533"></xref>.
The DNS servers configured via OPTION_DNS_SERVERS or Domain Name Server Option 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 MUST make the decision which one to prefer based on DNS preference field value. If
OPTION_DNS_SERVER_SELECT defines medium preference then DNS server from OPTION_DNS_SERVER_SELECT SHALL be
selected.
</t>
<t>If OPTION_DNS_SERVERS or Domain Name Server Option and OPTION_DNS_SERVER_SELECT contain the same DNS server(s) IP address(es),
a node SHALL add the same address of a DNS server to the server list only once.
</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 title="Considerations on follow-up queries">
<t>Any follow-up queries that are performed on the basis of an answer received on an interface MUST
continue to use the same interface, irrespective of the DNS server selection settings on any other
interface. For example, if a node receives a reply with a canonical name (CNAME) or delegation name (DNAME) the follow-up
queries MUST be sent to DNS server(s) of the same interface, or to same DNS server, irrespectively of the FQDN received. Otherwise
referrals may fail.</t>
</section>
</section>
<section title="Example of a node behavior" anchor="examples">
<t>Figure 7 illustrates node behavior when it initializes two network interfaces for parallel usage and
learns domain and network 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 | |
| | domains | |
| +-----------+ |
| | |
| +-----------+ |
(4) | | open | |
| | interface | |
| +-----------+ |
| | | |
(5) | |---option REQ------------------->|
| |<--option RESP-------------------|
| | | |
| +----------+ | |
(6) | | store | | |
| | domains | | |
| +----------+ | |
| | | |
]]></artwork>
<postamble>Illustration of learning domains</postamble>
</figure>
<t>Flow explanations:</t>
<t><list style="numbers">
<t>A node opens its first network interface</t>
<t>The node obtains domain 'domain1.example.com' and IPv6 network '0.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 1 from DHCPv6 server</t>
<t>The node stores the learned domains and IPv6 networks for later use</t>
<t>The node opens its second network interface 2</t>
<t>The node obtains domain 'domain2.example.com' and IPv6 network
information, say '1.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 domains and networks for later use</t>
</list></t>
<t>Figure 8 below illustrates how a resolver uses the learned domain information.
Network information use for reverse lookups is not illustrated, but that would go as the figure 7 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 domain</postamble>
</figure>
<t>Flow explanations:</t>
<t><list style="numbers">
<t>An application makes a request for resolving an FQDN, e.g. 'private.domain2.example.com'</t>
<t>A node creates list of DNS servers to contact to and uses configured DNS server information and stored domain information on prioritization decisions.</t>
<t>The node has chosen interface 2, as from DHCPv6 it was learned earlier that the
interface 2 has domain 'domain2.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" anchor="scalability">
<t>The size limitations of DHCP messages limit the number of domains and networks that can be carried
in configuration options. Including the domains and networks in a DHCP option is best suited for deployments
where relatively few carefully selected domains and networks are adequate. </t>
</section>
<section title="Considerations for network administrators" anchor="admins">
<t>Network administrators deploying private namespaces should assist advanced nodes in their DNS server selection process
by providing information described within this document.</t>
<t>Private namespaces MUST be globally unique in order to keep DNS unambiguous and henceforth avoiding
caching related issues and destination selection problems (see <xref target="notsolved"/>). Exceptions to this rule are domains
utilized for local name resolution (such as .local).</t>
<t>Private namespaces MUST only consist of subdomains of domains for which the relevant operator
provides authoritative name service. Thus, subdomains of example.com are permitted in the private
namespace served by an operator's DNS servers only if the same operator provides an SOA record for example.com.</t>
<t>To counter against attacks against private 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,
Brian Carpenter,
Stuart Cheshire,
Lars Eggert,
Tomohiro Fujisaki,
Peter Koch,
Suresh Krishnan,
Murray Kucherawy,
Edward Lewis,
Kurtis Lindqvist,
Arifumi Matsumoto,
Erik Nordmark,
Steve Padgett,
Fabien Rapin,
Matthew Ryan,
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 requests IANA to assign two new option codes. First option code is requested to be assigned for
DHCPv4 DNS Server Selection option (TBD) from the DHCP
option code space defined in section "New DHCP option codes" of RFC 2939. Second
option code is requested to be assigned to the DHCPv6 DNS Server Selection option (TBD) from the
DHCPv6 option code space defined in section "IANA Considerations" of RFC
3315.</t>
</section>
<section anchor="Security" title="Security Considerations">
<section title="Attack vectors">
<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 domains
and networks 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 best countermeasure for nodes is to implement validating DNSSEC aware resolvers.
Trusting on validation done by a DNS server is a possibility only
if a node trusts the DNS server and can use a secure channel for DNS messages.
</t>
</section>
<section title="Trust levels of network interfaces">
<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. An implementation may not be able to determine
trust levels without explicit configuration provided by user or administrator. Therefore, for
example, an implementation may not by default trust configuration received even over VPN
interfaces.
</t>
<t>The decision on levels of trust may be made by implementation, by node administrators, or for example
by other standards defining organizations as part of system design work.</t>
</section>
<section title="Importance of following the algorithm">
<t>The <xref target="dnsselection"/> uses normative language for describing node internal behavior
in order to ensure nodes would not open up new attack vectors by accidental use of DNS server
selection options. During the standards work consensus was that it is safer to not to enable
this option always by default, but only when deemed useful and safe.
</t>
</section>
</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"?-->
&RFC1533;
&RFC2119;
&RFC2317;
&RFC3315;
&RFC3152;
&RFC3736;
&RFC4242;
&RFC3396;
</references>
<references title="Informative References">
&RFC1918;
&RFC6147;
&I-D.wing-behave-dns64-config;
&I-D.ietf-mif-problem-statement;
&I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat;
&RFC3397;
&RFC3646;
&RFC4191;
&RFC4193;
&RFC6106;
</references>
<section anchor="app-additional" title="Possible alternative practices for DNS server selection">
<t>On some private namespace deployments explicit policies for DNS server selection are not available. This
section describes ways for nodes 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 node SHOULD implement DNSSEC
in order to be able to reject responses that cannot be validated. Selection
between legitimate answers is implementation specific, but replies from trusted
servers 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
'better' responses than other and prefer those - without forgetting fallback required
for cases when node is connected to more than one network using private namespaces.</t>
</section>
<section title="Search list option for DNS forward lookup decisions">
<t>A node can learn the special domains of attached network interfaces from IPv6
Router Advertisement DNS Search List Option <xref target="RFC6106"/> or DHCP search
list options; DHCPv4 Domain Search Option number 119 [RFC3397] and DHCPv6 Domain
Search List Option number 24 [RFC3646]. The node behavior is very similar as is
illustrated in the example at <xref target="examples"/>. While these options are not intended to be
used in DNS server selection, they may be used by the nodes as hints for smarter DNS server prioritization
purposes in order to increase likelihood of fast and successful DNS query.</t>
<t>Overloading of existing DNS search list options is not without problems:
resolvers would obviously use the domains learned from search lists also for name
resolution purposes. This may not be a problem in deployments where DNS search
list options contain few domains like 'example.com, private.example.com', but
can become a problem if many domains 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 nodes.
This information is not intended to be used in DNS server selection, but nevertheless a node
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
more likely capable to answer reverse lookup questions correctly than DNS server of an another interface.
The likelihood of success is possibly higher if DNS server address is received in the same RA
<xref target="RFC6106"></xref> as the more specific route information.</t>
</section>
<section title="Longest matching prefix for reverse lookup decision">
<t>A node may utilize the longest matching prefix approach when deciding which DNS server to contact
for reverse lookup purposes. Namely, the node 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 node or server within the same network (for example intranet).</t>
</section>
</section>
<section anchor="app-additional2" title="DNSSEC and multiple answers validating with different trust anchors">
<t>When validating DNS answers with DNSSEC, a validator might order
the list of trust anchors it uses to start validation chains, in
terms of the node's preferences for those trust anchors. A node
could use this ability in order to select among alternative
DNS results from different interfaces. Suppose that a node has
a trust anchor for the public DNS root, and also has a
special-purpose trust anchor for example.com. An answer is
received on interface i1 for www.example.com, and the validation
for that succeeds by using the public trust anchor. Also, an
answer is received on interface i2 for www.example.com, and the
validation for that succeeds by using the trust anchor for
example.com. In this case, the node has evidence for relying on
i2 for answers in the example.com zone.
</t>
</section>
<!-- Change Log
v00 2009-02-13 TS First version, sending for internal review
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:38 |