idnits 2.17.1 draft-ietf-mif-dns-server-selection-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2011) is 4560 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3736' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'I-D.wing-behave-dns64-config' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 922, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1533 (Obsoleted by RFC 2132) ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01 -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Savolainen 3 Internet-Draft Nokia 4 Intended status: Standards Track J. Kato 5 Expires: April 27, 2012 NTT 6 T. Lemon 7 Nominum, Inc. 8 October 25, 2011 10 Improved DNS Server Selection for Multi-Interfaced Nodes 11 draft-ietf-mif-dns-server-selection-07 13 Abstract 15 A multi-interfaced node is connected to multiple networks, some of 16 which may be utilizing private DNS namespaces. A node commonly 17 receives DNS server configuration information from all connected 18 networks. Some of the DNS servers may have information about 19 namespaces other servers do not have. When a multi-interfaced node 20 needs to utilize DNS, the node has to choose which of the servers to 21 contact to. This document describes DHCPv4 and DHCPv6 options that 22 can be used to configure nodes with information required to perform 23 informed DNS server selection decisions. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 27, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 61 2. Private namespaces and problems for multi-interfaced nodes . . 5 62 2.1. Fully qualified domain names with limited scopes . . . . . 5 63 2.2. Network interface specific IP addresses . . . . . . . . . 6 64 2.3. A problem not fully solved by the described solution . . . 8 65 3. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 8 66 3.1. CPE deployment scenario . . . . . . . . . . . . . . . . . 8 67 3.2. Cellular network scenario . . . . . . . . . . . . . . . . 9 68 3.3. VPN scenario . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.4. Dual-stack accesses . . . . . . . . . . . . . . . . . . . 9 70 4. Improved DNS server selection . . . . . . . . . . . . . . . . 9 71 4.1. Procedure for prioritizing DNS servers and handling 72 responses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2. DNS server selection DHCPv6 option . . . . . . . . . . . . 12 74 4.3. DNS server selection DHCPv4 option . . . . . . . . . . . . 14 75 4.4. Limitations on use . . . . . . . . . . . . . . . . . . . . 16 76 4.5. Coexistence with RFC3646 and RFC1533 . . . . . . . . . . . 16 77 4.6. Considerations on follow-up queries . . . . . . . . . . . 17 78 5. Example of a node behavior . . . . . . . . . . . . . . . . . . 17 79 6. Scalability considerations . . . . . . . . . . . . . . . . . . 20 80 7. Considerations for network administrators . . . . . . . . . . 20 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 10.1. Attack vectors . . . . . . . . . . . . . . . . . . . . . . 21 85 10.2. Trust levels of network interfaces . . . . . . . . . . . . 21 86 10.3. Importance of following the algorithm . . . . . . . . . . 21 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 90 Appendix A. Possible alternative practices for DNS server 91 selection . . . . . . . . . . . . . . . . . . . . . . 23 92 A.1. Sending queries out on multiple interfaces in parallel . . 23 93 A.2. Search list option for DNS forward lookup decisions . . . 24 94 A.3. More specific routes for reverse lookup decision . . . . . 24 95 A.4. Longest matching prefix for reverse lookup decision . . . 24 97 Appendix B. DNSSEC and multiple answers validating with 98 different trust anchors . . . . . . . . . . . . . . . 25 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 101 1. Introduction 103 A multi-interfaced node faces several problems a single-homed node 104 does not encounter, as is described in 105 [I-D.ietf-mif-problem-statement]. This document studies in detail 106 the problems private namespaces may cause for multi-interfaced nodes 107 and provides a solution. The node may be implemented as a host or as 108 a router. 110 We start from the premise that network operators sometimes include 111 private namespaces in the answers they provide from DNS servers, and 112 that those private namespaces are at least as useful to nodes as the 113 answers from the public DNS. When private namespaces are visible for 114 a node, some DNS servers have information other servers do not have. 115 The node ought to be able to ask right server for the information it 116 needs. 118 An example of an application that benefits from multi-interfacing is 119 a web browser that commonly accesses many different destinations, 120 each of which is available only on one network. The browser 121 therefore needs to be able to communicate over different network 122 interfaces, depending on the destination it is trying to reach. 124 In deployments where private namespaces are present, selection of 125 correct route and destination and source addresses for the actual IP 126 connection is crucial as well, as the resolved destination's IP 127 addresses may be only usable on the network interface over which the 128 name was resolved on. Hence solution described in this document is 129 assumed to be commonly used in combination with tools for delivering 130 additional routing and source and destination address selection 131 policies. 133 This document is organized in the following manner. Background 134 information about problem descriptions and example deployment 135 scenarios are included in Section 2 and Section 3. Section 4 136 contains all normative descriptions for DHCP options and node 137 behavior. Informative Section 5 illustrates behavior of a node 138 implementing functionality described in the Section 4. Section 6 139 contains informational considerations about scalability. Section 7 140 contains normative guidelines related to creation of private 141 namespaces. Informational Section 10 summarizes identified security 142 considerations. 144 The Appendix A describes best current practices possible with tools 145 preceding this document and that may be possibilities on networks not 146 supporting the solution described in this document. 148 1.1. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 2. Private namespaces and problems for multi-interfaced nodes 156 This section describes two node multi-interfacing related private 157 namespace scenarios for which the procedure described in Section 4 158 provides a solution for. Additionally, Section 2.3 describes a 159 problem for which this document provides only partial solution. 161 2.1. Fully qualified domain names with limited scopes 163 A multi-interfaced node may be connected to one or more networks that 164 are using private namespaces. As an example, the node may have 165 simultaneously open a wireless LAN (WLAN) connection to the public 166 Internet, cellular connection to an operator network, and a virtual 167 private network (VPN) connection to a corporate network. When an 168 application initiates a connection establishment to an FQDN, the node 169 needs to be able to choose the right DNS server for making a 170 successful DNS query. This is illustrated in the figure 1. An FQDN 171 for a public name can be resolved with any DNS server, but for an 172 FQDN of corporation's or operator's service's private name the node 173 needs to be able to correctly select the right DNS server for the DNS 174 resolution, i.e. do also network interface selection already before 175 destination's IP address is known. 177 +---------------+ 178 | DNS server w/ | | Corporate 179 +------+ | public + |----| Intranet 180 | | | corporation's | | 181 | |===== VPN =======| private names | | 182 | | +---------------+ +----+ 183 | MIF | | FW | 184 | node | +----+ 185 | | +---------------+ | 186 | |----- WLAN ------| DNS server w/ |----| Public 187 | | | public names | | Internet 188 | | +---------------+ +----+ 189 | | | FW | 190 | | +---------------+ +----+ 191 | |---- cellular ---| DNS server w/ | | 192 +------+ | public + | | Operator 193 | operator's |----| Intranet 194 | private names | | 195 +---------------+ 197 Private DNS namespaces illustrated 199 Figure 1 201 2.2. Network interface specific IP addresses 203 In the second problem an FQDN is valid and resolvable via different 204 network interfaces, but to different and not necessarily globally 205 reachable IP addresses, as is illustrated in the figure 2. Node's 206 routing and source and destination address selection mechanism must 207 ensure the destination's IP address is only used in combination with 208 source IP addresses of the network interface the name was resolved 209 on. 211 +--------------------| | 212 +------+ IPv6 | DNS server A |------| IPv6 213 | |-- interface 1 --| saying Peer is | | 214 | | | at: 2001:0db8:0::1 | | 215 | MIF | +--------------------+ +------+ 216 | node | | Peer | 217 | | +--------------------+ +------+ 218 | | IPv6 | DNS server B | | 219 | |-- interface 2 --| saying Peer is | | 220 +------+ | at: 2001:0db8:1::1 |------| IPv6 221 +--------------------+ | 223 Private DNS namespaces and different IP addresses for an FQDN on 224 interfaces 1 and 2. 226 Figure 2 228 Similar situation can happen with IPv6 protocol translation and AAAA 229 record synthesis [RFC6147]. A synthetic AAAA record is guaranteed to 230 be valid only on a network it was synthesized on. Figure 3 231 illustrates a scenario where the peer's IPv4 address is synthesized 232 into different IPv6 addresses by DNS servers A and B. 234 +-------------------| +-------+ 235 +------+ IPv6 | DNS server A |----| NAT64 | 236 | |-- interface 1 --| saying Peer is | +-------+ 237 | | | at: A_Pref96:IPv4 | | 238 | MIF | +-------------------+ | +------+ 239 | node | IPv4 +---| Peer | 240 | | +-------------------+ | +------+ 241 | | IPv6 | DNS server B | | 242 | |-- interface 2 --| saying Peer is | +-------+ 243 +------+ | at: B_Pref96:IPv4 |----| NAT64 | 244 +-------------------+ +-------+ 246 AAAA synthesis results in network interface specific IPv6 addresses. 248 Figure 3 250 It is worth noting is that network specific IP addresses can cause 251 problems also for a single-homed node, if the node retains DNS cache 252 during movement from one network to another. After the network 253 change, a node may have entries in its DNS cache that are no longer 254 correct or appropriate for its new network position. 256 2.3. A problem not fully solved by the described solution 258 A more complex scenario is an FQDN, which in addition to possibly 259 resolving into network interface specific IP addresses, identifies on 260 different network interfaces completely different peer entities with 261 potentially different set of service offerings. In even more complex 262 scenario, an FQDN identifies unique peer entity, but one that 263 provides different services on its different network interfaces. The 264 solution described in this document is not able to tackle these 265 higher layer issues. In fact, these problems may be solvable only by 266 manual user intervention. 268 However, when DNSSEC is used, the DNSSEC validation procedure may 269 provide assistance for selecting correct responses for some, but not 270 all, use cases. A node may prefer to use the DNS answer that 271 validates with the preferred trust anchor. 273 3. Deployment scenarios 275 This document has been written with three particular deployment 276 scenarios in mind. First being a Consumer Premises Equipment (CPE) 277 with two or more uplink VLAN connections. Second scenario involves a 278 cellular device with two uplink Internet connections: WLAN and 279 cellular. Third scenario is for VPNs, where use of local DNS server 280 may be preferred for latency reasons, but corporate DNS server must 281 be used to resolve private names used by the corporation. 283 3.1. CPE deployment scenario 285 A home gateway may have two uplink connections leading to different 286 networks, as is described in 287 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. In the two 288 uplinks scenario only one uplink connection leads to the Internet, 289 while another uplink connection leads to a private network utilizing 290 private namespaces. 292 It is desirable that the CPE does not have to send DNS queries over 293 both uplink connections, but instead CPE should send default queries 294 to the DNS server of the interface leading to the Internet, and 295 queries related to private namespace to the DNS server of the private 296 network. 298 In this scenario the legacy hosts can be supported by deploying DNS 299 proxy on the CPE and configuring hosts in the LAN to talk to the DNS 300 proxy. However, updated hosts would be able to talk directly to the 301 correct DNS servers of each uplink ISP's DNS server. It is 302 deployment decision whether the updated hosts would be pointed to DNS 303 proxy or to actual DNS servers. 305 Depending on actual deployments, all VLAN connections might be 306 considered as trusted. 308 3.2. Cellular network scenario 310 A cellular device may have both WLAN and cellular network interfaces 311 up. In such a case it is often desirable to use WLAN by default, 312 except for those connections cellular network operator wants to go 313 over cellular interface. The cellular network may utilize private 314 names and hence the cellular device needs to ask for those through 315 the cellular interface. 317 In this scenario cellular interface can be considered trusted and 318 WLAN oftentimes untrusted. 320 3.3. VPN scenario 322 Depending on a deployment, there may be interest to use VPN only for 323 the traffic destined to a corporate network. The corporation may be 324 using private namespace, and hence related DNS queries should be send 325 over VPN to the corporate DNS server, while by default a DNS server 326 of a local access network may be used. 328 In this scenario VPN interface can be considered trusted and local 329 access network untrusted. 331 3.4. Dual-stack accesses 333 In all three scenarios one or more of the connected networks may 334 support both IPv4 and IPv6. In such a case both or either of DHCPv4 335 and DHCPv6 can be used to learn DNS server selection information. 337 4. Improved DNS server selection 339 This section describes DHCP options and a procedure that a (stub / 340 proxy) resolver may utilize for improved DNS server selection in the 341 face of private namespaces and multiple simultaneously active network 342 interfaces. 344 4.1. Procedure for prioritizing DNS servers and handling responses 346 A resolver SHALL build a priority list of DNS servers it will contact 347 to depending on the query. To build the list in an optimal way, a 348 node SHOULD ask with DHCP which DNS servers of each network interface 349 are most likely to be able to successfully serve forward lookup 350 requests matching to specific domain or reverse (PTR record) lookup 351 requests matching to specific network addresses (later referred as 352 "network"). For security reasons the DNS server selection 353 information MUST be used only when it is safe to do so, see 354 Section 4.4 for details. 356 The node SHOULD create a node specific route for the DNS server 357 addresses learned via DHCP. The route must point to the interface 358 DNS server address was learned on. This is required to ensure DNS 359 queries are sent out via the right network interface. 361 A resolver lacking more specific information shall assume that all 362 information is available from any DNS server of any network 363 interface. The DNS servers learnt by other DNS server address 364 configuration methods MUST be handled as medium priority default 365 servers. 367 When a DNS query needs to be made, the resolver SHOULD give highest 368 precedence to the DNS servers explicitly known to serve matching 369 domain or network. The resolver MUST take into account differences 370 in trust levels of pieces of received DNS server selection 371 information. The resolver MUST prefer DNS servers of trusted 372 interfaces. The DNS servers of untrusted interfaces may be of 373 highest priority only if trusted interfaces specifically configure 374 low priority DNS servers. The non-exhaustive list on figure 4 375 illustrates how the different trust levels of received DNS server 376 selection information SHOULD influence the DNS server selection 377 logic. 379 Trustworthiness of an interface and configuration information 380 received over the interface is implementation and/or node deployment 381 dependent. Trust may be based on, for example, on the nature of an 382 interface. For example, an authenticated and encrypted VPN or layer 383 2 connections to a trusted home network may be considered as trusted, 384 and an unauthenticated and unencrypted connection to an unknown 385 visited network may be considered as untrusted. In some occasions an 386 interface may be considered trusted only if explicitly configured to 387 be trusted. 389 A resolver SHOULD prioritize between equally trusted DNS servers with 390 help of the DHCP option preference field. The resolver MUST NOT 391 prioritize less trusted DNS servers higher than trusted, even in the 392 case of less trusted server would apparently have additional 393 information. In the case of all other things being equal the 394 resolver shall make the prioritization decision based on its internal 395 preferences. 397 Information from | Information from | Resulting DNS 398 more trusted | less trusted | server priority 399 interface A | interface B | selection 400 --------------------------+------------------------+-------------------- 401 1. Medium priority | Medium priority | Default: A, then B 402 default | default | 403 --------------------------+------------------------+-------------------- 404 2. Medium priority | High priority default | Default: A, then B 405 default | High priority specific | Specific: A, then B 406 --------------------------+------------------------+-------------------- 407 3. Low priority default | Medium priority | Default: B, then A 408 | default | 409 --------------------------+------------------------+-------------------- 410 4. Low priority default | Medium priority | Default: B, then A 411 High priority specific | default | Specific: A, then B 412 --------------------------+------------------------+-------------------- 414 Figure 4: DNS server selection in the case of different trust levels 416 Because DNSSEC provides cryptographic assurance of the integrity of 417 DNS data, data that can be validated under DNSSEC is necessarily to 418 be preferred over data that cannot be. There are two ways that a 419 node can determine that data is valid under DNSSEC. The first is to 420 perform DNSSEC validation itself. The second is to have a secure 421 connection to an authenticated DNS server, and to rely on that DNS 422 server to perform DNSSEC validation (signalling that it has done so 423 using the AD bit). If a DNS response is not proven to be unmolested 424 using DNSSEC, then a node cannot make a decision to prefer data from 425 any interface with any great assurance: any response could be forged, 426 and there is no way to detect the forgery without DNSSEC. 428 A node SHALL send requests to DNS servers in the order defined by the 429 priority list until an acceptable reply is received, all replies are 430 received, or a time out occurs. In the case of a requested name 431 matching to a specific domain or network rule accepted from any 432 interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that 433 cannot be validated using DNSSEC until all DNS servers on the 434 priority list have been contacted or timed out. This protects 435 against possible redirection attacks. In the case of the requested 436 name not matching to any specific domain or network, first received 437 response from any DNS server MAY be considered acceptable. A DNSSEC- 438 aware node MAY always contact all DNS server in an attempt to receive 439 a response that can be validated, but contacting all DNS servers is 440 not mandated for the default case as in some deployments that would 441 consume excess resources. 443 The resolver SHOULD avoid sending queries over different network 444 interfaces in parallel as that wastes resources such as energy. The 445 amount of wasted energy can be significant, for example when radio 446 interfaces has to be started just for the queries. 448 In the case of validated NXDOMAIN response being received from a DNS 449 server that can provide answers for the queried name a node MUST NOT 450 accept non-validated replies from other DNS servers (see Appendix B 451 for considerations related to multiple trust anchors. 453 4.2. DNS server selection DHCPv6 option 455 DHCPv6 option described below can be used to inform resolvers which 456 DNS server should be contacted when initiating forward or reverse DNS 457 lookup procedures. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | OPTION_DNS_SERVER_SELECT | option-len | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | | 465 | DNS-recursive-name-server (IPv6 address) | 466 | | 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Reserved |prf| | 470 +-+-+-+-+-+-+-+-+ Domains and networks | 471 | (variable length) | 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 option-code: OPTION_DNS_SERVER_SELECT (TBD) 477 option-len: Length of the option in octets 479 DNS-recursive-name-server: An IPv6 address of a recursive DNS server 481 Reserved: Field reserved for the future. MUST be set to zero. 483 prf: DNS server preference, for selecting between 484 equally trusted DNS servers: 485 01 High 486 00 Medium 487 11 Low 488 10 Reserved 490 Domains and networks: The list of domains for forward DNS 491 lookup and networks for reverse DNS lookup the DNS server 492 has special knowledge about. Field MUST be encoded as 493 specified in Section "Representation and use of 494 domain names" of [RFC3315]. 495 Special domain of "." is used to indicate 496 capability to resolve global names and act as a 497 default name server. Lack of "." 498 domain on the list indicates DNS server only has 499 information related to listed domains and networks. 500 Networks for reverse mapping are encoded as 501 defined for ip6.arpa [RFC3152] or in-addr.arpa [RFC2317]. 503 DHCPv6 option for explicit domain configuration 505 Figure 5 507 A node SHOULD include an OPTION_ORO option in a DHCPv6 request with 508 the OPTION_DNS_SERVER_SELECT option code to inform the DHCPv6 server 509 about the support for the improved DNS server selection logic. 510 DHCPv6 server receiving this information MAY then choose to provision 511 DNS server addresses only with the OPTION_DNS_SERVER_SELECT. 513 The OPTION_DNS_SERVER_SELECT contains one or more domains the related 514 DNS server has particular knowledge of. The option can occur 515 multiple times in a single DHCPv6 message, if multiple DNS servers 516 are to be configured. 518 IPv6 networks should cover all the domains configured in this option. 519 Networks should be as long as possible to avoid potential collision 520 with information received on other option instances or with options 521 received from DHCPv6 servers of other network interfaces. 522 Overlapping IPv6 networks are interpreted so that the resolver can 523 use any of the DNS servers for queries matching the networks. 525 If the OPTION_DNS_SERVER_SELECT contains a DNS server address already 526 learned from other DHCPv6 servers of the same network, and contains 527 new domains or networks, the node SHOULD append the information to 528 the information received earlier. The node MUST NOT remove 529 previously obtained information. However, the node SHOULD NOT extent 530 lifetime of earlier information either. In the case of conflicting 531 DNS server address is learned from less trusted interface, the node 532 MUST ignore the option. 534 As the DNS options of [RFC3646], the OPTION_DNS_SERVER_SELECT option 535 MUST NOT appear in any other than the following DHCPv6 messages: 536 Solicit, Advertise, Request, Renew, Rebind, Information-Request, and 537 Reply. 539 The information conveyed in OPTION_DNS_SERVER_SELECT is considered 540 valid until changed or refreshed by general events that trigger 541 DHCPv6 action. In the event that it is desired for the client to 542 request a refresh of the information, use of generic DHCPv6 543 Information Refresh Time Option, as specified in [RFC4242] is 544 RECOMMENDED. 546 4.3. DNS server selection DHCPv4 option 548 DHCPv4 option described below can be used to inform resolvers which 549 DNS server should be contacted when initiating forward or reverse DNS 550 lookup procedures. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | CODE | Len | Reserved |prf| Primary .. | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | .. DNS-recursive-name-server's IPv4 address | Secondary .. | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | .. DNS-recursive-name-server's IPv4 address | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 561 | | 562 + Domains and networks | 563 | (variable length) | 564 | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 option-code: OPTION_DNS_SERVER_SELECT (TBD) 569 option-len: Length of the option in octets 571 Reserved: Field reserved for the future. MUST be set to zero. 573 prf: DNS servers preference, for selecting between 574 equally trusted DNS servers: 575 01 High 576 00 Medium 577 11 Low 578 10 Reserved 580 Primary DNS-recursive-name-server's IPv4 address: Address of 581 a primary recursive DNS server 583 Secondary DNS-recursive-name-server's IPv4 address: Address of 584 a secondary recursive DNS server or 0.0.0.0 if 585 not configured. 587 Domains and networks: The list of domains for forward DNS lookup 588 and networks for reverse DNS lookup the DNS servers 589 have special knowledge about. Field MUST be encoded as 590 specified in Section "Representation and use of 591 domain names" of [RFC3315]. 592 Special domain of "." is used to indicate 593 capability to resolve global names and act as 594 default name servers. Lack of "." 595 domain on the list indicates DNS servers only have 596 information related to listed domains and networks. 597 Networks for reverse mapping are encoded as 598 defined for ip6.arpa [RFC3152] or in-addr.arpa [RFC2317]. 600 DHCPv4 option for explicit domain configuration 602 Figure 6 604 The OPTION_DNS_SERVER_SELECT contains one or more domains the primary 605 and secondary DNS servers have particular knowledge of. If the 606 length of the domains and networks field causes option length to 607 exceed the maximum permissible for a single option (255 octets), then 608 multiple options MAY be used, as described in "Encoding Long Options 609 in the Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396]. When 610 multiple options are present, the data portions of all option 611 instances are concatenated together. 613 If the OPTION_DNS_SERVER_SELECT contains a DNS server address already 614 learned from other DHCPv4 servers of the same network, and contains 615 new domains or networks, the node SHOULD append the information to 616 the information received earlier. The node MUST NOT remove 617 previously obtained information. However, the node SHOULD NOT extent 618 lifetime of earlier information either. In the case of conflicting 619 DNS server address is learned from less trusted interface, the node 620 MUST ignore the option. 622 4.4. Limitations on use 624 Use of OPTION_DNS_SERVER_SELECT is ideal in the following 625 environments, but SHOULD NOT be enabled by default otherwise: 627 1. The server selection option is delivered across a secure, trusted 628 channel. 630 2. The server selection option is not secured, but the client on a 631 node does DNSSEC validation. 633 3. The server selection option is not secured, the resolver does 634 DNSSEC validation, and the client communicates with the resolver 635 configured with server selection option over a secure, trusted 636 channel. 638 4. The DNS server IP address that is being recommended in the server 639 selection option is known and trusted by the client; that is, the 640 server selection option serves not to introduce the client to a new 641 server, but rather to inform it that a server it has already been 642 configured to trust is available to it for resolving certain domains. 644 4.5. Coexistence with RFC3646 and RFC1533 646 The OPTION_DNS_SERVER_SELECT is designed to coexist with DHCPv6 647 OPTION_DNS_SERVERS defined in [RFC3646] and DHCPv4 Domain Name Server 648 Option defined in [RFC1533]. The DNS servers configured via 649 OPTION_DNS_SERVERS or Domain Name Server Option MUST be considered as 650 default name servers with medium preference. When both options are 651 received from the same network interface and the 652 OPTION_DNS_SERVER_SELECT contains default DNS server address, the 653 resolver MUST make the decision which one to prefer based on DNS 654 preference field value. If OPTION_DNS_SERVER_SELECT defines medium 655 preference then DNS server from OPTION_DNS_SERVER_SELECT SHALL be 656 selected. 658 If OPTION_DNS_SERVERS or Domain Name Server Option and 659 OPTION_DNS_SERVER_SELECT contain the same DNS server(s) IP 660 address(es), a node SHALL add the same address of a DNS server to the 661 server list only once. 663 If a node had indicated support for OPTION_DNS_SERVER_SELECT in 664 DHCPv6 request, the DHCPv6 server may choose to omit sending of 665 OPTION_DNS_SERVERS. This enables offloading use case where network 666 administrator wishes to only advertise low priority default DNS 667 servers. 669 4.6. Considerations on follow-up queries 671 Any follow-up queries that are performed on the basis of an answer 672 received on an interface MUST continue to use the same interface, 673 irrespective of the DNS server selection settings on any other 674 interface. For example, if a node receives a reply with a canonical 675 name (CNAME) or delegation name (DNAME) the follow-up queries MUST be 676 sent to DNS server(s) of the same interface, or to same DNS server, 677 irrespectively of the FQDN received. Otherwise referrals may fail. 679 5. Example of a node behavior 681 Figure 7 illustrates node behavior when it initializes two network 682 interfaces for parallel usage and learns domain and network 683 information from DHCPv6 servers. 685 Application Node DHCPv6 server DHCPv6 server 686 on interface 1 on interface 2 687 | | | 688 | +-----------+ | 689 (1) | | open | | 690 | | interface | | 691 | +-----------+ | 692 | | | 693 (2) | |---option REQ-->| 694 | |<--option RESP--| 695 | | | 696 | +-----------+ | 697 (3) | | store | | 698 | | domains | | 699 | +-----------+ | 700 | | | 701 | +-----------+ | 702 (4) | | open | | 703 | | interface | | 704 | +-----------+ | 705 | | | | 706 (5) | |---option REQ------------------->| 707 | |<--option RESP-------------------| 708 | | | | 709 | +----------+ | | 710 (6) | | store | | | 711 | | domains | | | 712 | +----------+ | | 713 | | | | 715 Illustration of learning domains 717 Figure 7 719 Flow explanations: 721 1. A node opens its first network interface 723 2. The node obtains domain 'domain1.example.com' and IPv6 network 724 '0.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 1 from DHCPv6 725 server 727 3. The node stores the learned domains and IPv6 networks for later 728 use 730 4. The node opens its second network interface 2 731 5. The node obtains domain 'domain2.example.com' and IPv6 network 732 information, say '1.8.b.d.0.1.0.0.2.ip6.arpa' for the new 733 interface 2 from DHCPv6 server 735 6. The node stores the learned domains and networks for later use 737 Figure 8 below illustrates how a resolver uses the learned domain 738 information. Network information use for reverse lookups is not 739 illustrated, but that would go as the figure 7 example. 741 Application Node DHCPv6 server DHCPv6 server 742 on interface 1 on interface 2 743 | | | | 744 (1) |--Name REQ-->| | | 745 | | | | 746 | +----------------+ | | 747 (2) | | DNS server | | | 748 | | prioritization | | | 749 | +----------------+ | | 750 | | | | 751 (3) | |------------DNS resolution------>| 752 | |<--------------------------------| 753 | | | | 754 (4) |<--Name resp-| | | 755 | | | | 757 Example on choosing interface based on domain 759 Figure 8 761 Flow explanations: 763 1. An application makes a request for resolving an FQDN, e.g. 764 'private.domain2.example.com' 766 2. A node creates list of DNS servers to contact to and uses 767 configured DNS server information and stored domain information 768 on prioritization decisions. 770 3. The node has chosen interface 2, as from DHCPv6 it was learned 771 earlier that the interface 2 has domain 'domain2.example.com'. 772 The node then resolves the requested name using interface 2's DNS 773 server to an IPv6 address 775 4. The node replies to application with the resolved IPv6 address 777 6. Scalability considerations 779 The size limitations of DHCP messages limit the number of domains and 780 networks that can be carried in configuration options. Including the 781 domains and networks in a DHCP option is best suited for deployments 782 where relatively few carefully selected domains and networks are 783 adequate. 785 7. Considerations for network administrators 787 Network administrators deploying private namespaces should assist 788 advanced nodes in their DNS server selection process by providing 789 information described within this document. 791 Private namespaces MUST be globally unique in order to keep DNS 792 unambiguous and henceforth avoiding caching related issues and 793 destination selection problems (see Section 2.3). Exceptions to this 794 rule are domains utilized for local name resolution (such as .local). 796 Private namespaces MUST only consist of subdomains of domains for 797 which the relevant operator provides authoritative name service. 798 Thus, subdomains of example.com are permitted in the private 799 namespace served by an operator's DNS servers only if the same 800 operator provides an SOA record for example.com. 802 To counter against attacks against private namespaces, administrators 803 utilizing this tool SHOULD deploy DNSSEC for their zone. 805 8. Acknowledgements 807 The author would like to thank following people for their valuable 808 feedback and improvement ideas: Mark Andrews, Jari Arkko, Marcelo 809 Bagnulo, Brian Carpenter, Stuart Cheshire, Lars Eggert, Tomohiro 810 Fujisaki, Peter Koch, Suresh Krishnan, Murray Kucherawy, Edward 811 Lewis, Kurtis Lindqvist, Arifumi Matsumoto, Erik Nordmark, Steve 812 Padgett, Fabien Rapin, Matthew Ryan, Dave Thaler, Margaret Wasserman, 813 Dan Wing, and Dec Wojciech. Ted Lemon and Julien Laganier receive 814 special thanks for their contributions to security considerations. 816 This document was prepared using xml2rfc template and the related 817 web-tool. 819 9. IANA Considerations 821 This memo requests IANA to assign two new option codes. First option 822 code is requested to be assigned for DHCPv4 DNS Server Selection 823 option (TBD) from the DHCP option code space defined in section "New 824 DHCP option codes" of RFC 2939. Second option code is requested to 825 be assigned to the DHCPv6 DNS Server Selection option (TBD) from the 826 DHCPv6 option code space defined in section "IANA Considerations" of 827 RFC 3315. 829 10. Security Considerations 831 10.1. Attack vectors 833 It is possible that attackers might try to utilize 834 OPTION_DNS_SERVER_SELECT option to redirect some or all DNS queries 835 sent by a resolver to undesired destinations. The purpose of an 836 attack might be denial-of-service, preparation for man-in-the-middle 837 attack, or something akin. 839 Attackers might try to lure specific traffic by advertising domains 840 and networks from very small to very large scope or simply by trying 841 to place attacker's DNS server as the highest priority default 842 server. 844 The best countermeasure for nodes is to implement validating DNSSEC 845 aware resolvers. Trusting on validation done by a DNS server is a 846 possibility only if a node trusts the DNS server and can use a secure 847 channel for DNS messages. 849 10.2. Trust levels of network interfaces 851 Decision on trust levels of network interfaces depends very much on 852 deployment scenario and types of network interfaces. For example, 853 unmanaged WLAN may be considered less trustworthy than managed 854 cellular or VPN connections. An implementation may not be able to 855 determine trust levels without explicit configuration provided by 856 user or administrator. Therefore, for example, an implementation may 857 not by default trust configuration received even over VPN interfaces. 859 The decision on levels of trust may be made by implementation, by 860 node administrators, or for example by other standards defining 861 organizations as part of system design work. 863 10.3. Importance of following the algorithm 865 The Section 4 uses normative language for describing node internal 866 behavior in order to ensure nodes would not open up new attack 867 vectors by accidental use of DNS server selection options. During 868 the standards work consensus was that it is safer to not to enable 869 this option always by default, but only when deemed useful and safe. 871 11. References 873 11.1. Normative References 875 [RFC1533] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 876 Extensions", RFC 1533, October 1993. 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", BCP 14, RFC 2119, March 1997. 881 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 882 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. 884 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 885 August 2001. 887 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 888 and M. Carney, "Dynamic Host Configuration Protocol for 889 IPv6 (DHCPv6)", RFC 3315, July 2003. 891 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 892 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 893 November 2002. 895 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 896 (DHCP) Service for IPv6", RFC 3736, April 2004. 898 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 899 Time Option for Dynamic Host Configuration Protocol for 900 IPv6 (DHCPv6)", RFC 4242, November 2005. 902 11.2. Informative References 904 [I-D.ietf-mif-problem-statement] 905 Blanchet, M. and P. Seite, "Multiple Interfaces and 906 Provisioning Domains Problem Statement", 907 draft-ietf-mif-problem-statement-15 (work in progress), 908 May 2011. 910 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 911 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 912 Wing, "IPv6 Multihoming without Network Address 913 Translation", 914 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01 (work 915 in progress), August 2011. 917 [I-D.wing-behave-dns64-config] 918 Wing, D., "IPv6-only and Dual Stack Hosts on the Same 919 Network with DNS64", draft-wing-behave-dns64-config-03 920 (work in progress), February 2011. 922 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 923 E. Lear, "Address Allocation for Private Internets", 924 BCP 5, RFC 1918, February 1996. 926 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 927 Protocol (DHCP) Domain Search Option", RFC 3397, 928 November 2002. 930 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 931 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 932 December 2003. 934 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 935 More-Specific Routes", RFC 4191, November 2005. 937 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 938 Addresses", RFC 4193, October 2005. 940 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 941 "IPv6 Router Advertisement Options for DNS Configuration", 942 RFC 6106, November 2010. 944 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 945 Beijnum, "DNS64: DNS Extensions for Network Address 946 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 947 April 2011. 949 Appendix A. Possible alternative practices for DNS server selection 951 On some private namespace deployments explicit policies for DNS 952 server selection are not available. This section describes ways for 953 nodes to mitigate the problem by sending wide-spread queries and by 954 utilizing possibly existing indirect information elements as hints. 956 A.1. Sending queries out on multiple interfaces in parallel 958 A possible current practice is to send DNS queries out of multiple 959 interfaces and pick up the best out of the received responses. A 960 node SHOULD implement DNSSEC in order to be able to reject responses 961 that cannot be validated. Selection between legitimate answers is 962 implementation specific, but replies from trusted servers should be 963 preferred. 965 A downside of this approach is increased consumption of resources. 966 Namely power consumption if an interface, e.g. wireless, has to be 967 brought up just for the DNS query that could have been resolved also 968 via cheaper interface. Also load on DNS servers is increased. 969 However, local caching of results mitigates these problems, and a 970 node might also learn interfaces that seem to be able to provide 971 'better' responses than other and prefer those - without forgetting 972 fallback required for cases when node is connected to more than one 973 network using private namespaces. 975 A.2. Search list option for DNS forward lookup decisions 977 A node can learn the special domains of attached network interfaces 978 from IPv6 Router Advertisement DNS Search List Option [RFC6106] or 979 DHCP search list options; DHCPv4 Domain Search Option number 119 980 [RFC3397] and DHCPv6 Domain Search List Option number 24 [RFC3646]. 981 The node behavior is very similar as is illustrated in the example at 982 Section 5. While these options are not intended to be used in DNS 983 server selection, they may be used by the nodes as hints for smarter 984 DNS server prioritization purposes in order to increase likelihood of 985 fast and successful DNS query. 987 Overloading of existing DNS search list options is not without 988 problems: resolvers would obviously use the domains learned from 989 search lists also for name resolution purposes. This may not be a 990 problem in deployments where DNS search list options contain few 991 domains like 'example.com, private.example.com', but can become a 992 problem if many domains are configured. 994 A.3. More specific routes for reverse lookup decision 996 [RFC4191] defines how more specific routes can be provisioned for 997 nodes. This information is not intended to be used in DNS server 998 selection, but nevertheless a node can use this information as a hint 999 about which interface would be best to try first for reverse lookup 1000 procedures. A DNS server configured via the same interface as more 1001 specific routes is more likely capable to answer reverse lookup 1002 questions correctly than DNS server of an another interface. The 1003 likelihood of success is possibly higher if DNS server address is 1004 received in the same RA [RFC6106] as the more specific route 1005 information. 1007 A.4. Longest matching prefix for reverse lookup decision 1009 A node may utilize the longest matching prefix approach when deciding 1010 which DNS server to contact for reverse lookup purposes. Namely, the 1011 node may send a DNS query to a DNS server learned over an interface 1012 having longest matching prefix to the address being queried. This 1013 approach can help in cases where ULA [RFC4193] addresses are used and 1014 when the queried address belongs to a node or server within the same 1015 network (for example intranet). 1017 Appendix B. DNSSEC and multiple answers validating with different trust 1018 anchors 1020 When validating DNS answers with DNSSEC, a validator might order the 1021 list of trust anchors it uses to start validation chains, in terms of 1022 the node's preferences for those trust anchors. A node could use 1023 this ability in order to select among alternative DNS results from 1024 different interfaces. Suppose that a node has a trust anchor for the 1025 public DNS root, and also has a special-purpose trust anchor for 1026 example.com. An answer is received on interface i1 for 1027 www.example.com, and the validation for that succeeds by using the 1028 public trust anchor. Also, an answer is received on interface i2 for 1029 www.example.com, and the validation for that succeeds by using the 1030 trust anchor for example.com. In this case, the node has evidence 1031 for relying on i2 for answers in the example.com zone. 1033 Authors' Addresses 1035 Teemu Savolainen 1036 Nokia 1037 Hermiankatu 12 D 1038 TAMPERE, FI-33720 1039 FINLAND 1041 Email: teemu.savolainen@nokia.com 1043 Jun-ya Kato 1044 NTT 1045 9-11, Midori-Cho 3-Chome Musashino-Shi 1046 TOKYO, 180-8585 1047 JAPAN 1049 Email: kato@syce.net 1050 Ted Lemon 1051 Nominum, Inc. 1052 2000 Seaport Boulevard 1053 Redwood City, CA 94063 1054 USA 1056 Phone: +1 650 381 6000 1057 Email: Ted.Lemon@nominum.com