idnits 2.17.1 draft-ietf-mif-dns-server-selection-04.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 (September 13, 2011) is 4608 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 876, but no explicit reference was found in the text == Unused Reference: 'I-D.wing-behave-dns64-config' is defined on line 898, but no explicit reference was found in the text ** 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 5006 (Obsoleted by RFC 6106) Summary: 4 errors (**), 0 flaws (~~), 4 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: March 16, 2012 NTT 6 T. Lemon 7 Nominum, Inc. 8 September 13, 2011 10 Improved DNS Server Selection for Multi-Interfaced Nodes 11 draft-ietf-mif-dns-server-selection-04 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 option 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 March 16, 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 . . . . . . . . . . . . . . . . . 16 77 4.6. Interactions with OPTION_DOMAIN_LIST and pre-DNS 78 hostnames . . . . . . . . . . . . . . . . . . . . . . . . 17 79 4.7. Considerations on follow-up queries . . . . . . . . . . . 17 80 5. Example of a node behavior . . . . . . . . . . . . . . . . . . 17 81 6. Scalability considerations . . . . . . . . . . . . . . . . . . 20 82 7. Considerations for network administrators . . . . . . . . . . 20 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 89 Appendix A. Best Current Practice for DNS server selection . . . 23 90 A.1. Sending queries out on multiple interfaces in parallel . . 23 91 A.2. Search list option for DNS forward lookup decisions . . . 23 92 A.3. More specific routes for reverse lookup decision . . . . . 24 93 A.4. Longest matching prefix for reverse lookup decision . . . 24 94 Appendix B. DNSSEC and multiple answers validating with 95 different trust anchors . . . . . . . . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 99 1. Introduction 101 A multi-interfaced node faces several problems a single-homed node 102 does not encounter, as is described in 103 [I-D.ietf-mif-problem-statement]. This document studies in detail 104 the problems private namespaces may cause for multi-interfaced nodes 105 and provides a solution. The node may be implemented as a host or as 106 a router. 108 We start from the premise that network operators sometimes include 109 private namespaces in the answers they provide from DNS servers, and 110 that those private namespaces are at least as useful to nodes as the 111 answers from the public DNS. When private namespaces are visible for 112 a node, some DNS servers have information other servers do not have. 113 The node ought to be able to ask right server for the information it 114 needs. 116 An example of an application that benefits from multi-interfacing is 117 a web browser that commonly accesses many different destinations, 118 each of which is available only on one network. The browser 119 therefore needs to be able to communicate over different network 120 interfaces, depending on the destination it is trying to reach. 122 In deployments where private namespaces are present, selection of 123 correct route and destination and source addresses for the actual IP 124 connection is crucial as well, as the resolved destination's IP 125 addresses may be only usable on the network interface over which the 126 name was resolved on. Hence solution described in this document is 127 assumed to be commonly used in combination with tools for delivering 128 additional routing and source and destination address selection 129 policies. 131 This document is organized in the following manner. Background 132 information about problem descriptions and example deployment 133 scenarios are included in sections 2 and 3. Section 4 contains all 134 normative descriptions for DHCP options and node behavior. 135 Informative section 5 illustrates behavior of a node implementing 136 functionality described in the section 4. Section 6 contains 137 informational considerations about scalability. Section 7 contains 138 normative guidelines related to creation of private namespaces. 139 Informational section 10 summarizes identified security 140 considerations. 142 The Appendix A describes best current practices possible with tools 143 preceding this document and that may be possibilities on networks not 144 supporting the solution described in this document. 146 1.1. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 2. Private namespaces and problems for multi-interfaced nodes 154 This chapter describes two node multi-interfacing related private 155 namespace scenarios for which the procedure described in chapter 4 156 provides a solution for. Additionally, section 2.3 describes a 157 problem for which this document provides only partial solution. 159 2.1. Fully qualified domain names with limited scopes 161 A multi-interfaced node may be connected to one or more networks that 162 are using private namespaces. As an example, the node may have 163 simultaneously open a wireless LAN (WLAN) connection to the public 164 Internet, cellular connection to an operator network, and a virtual 165 private network (VPN) connection to a corporate network. When an 166 application initiates a connection establishment to an FQDN, the node 167 needs to be able to choose the right DNS server for making a 168 successful DNS query. This is illustrated in the figure 1. An FQDN 169 for a public name can be resolved with any DNS server, but for an 170 FQDN of corporation's or operator's service's private name the node 171 needs to be able to correctly select the right DNS server for the DNS 172 resolution, i.e. do also network interface selection already before 173 destination's IP address is known. 175 +---------------+ 176 | DNS server w/ | | Corporate 177 +------+ | public + |----| Intranet 178 | | | corporation's | | 179 | |===== VPN =======| private names | | 180 | | +---------------+ +----+ 181 | MIF | | FW | 182 | node | +----+ 183 | | +---------------+ | 184 | |----- WLAN ------| DNS server w/ |----| Public 185 | | | public names | | Internet 186 | | +---------------+ +----+ 187 | | | FW | 188 | | +---------------+ +----+ 189 | |---- cellular ---| DNS server w/ | | 190 +------+ | public + | | Operator 191 | operator's |----| Intranet 192 | private names | | 193 +---------------+ 195 Private DNS namespaces illustrated 197 Figure 1 199 2.2. Network interface specific IP addresses 201 In the second problem an FQDN is valid and resolvable via different 202 network interfaces, but to different and not necessarily globally 203 reachable IP addresses, as is illustrated in the figure 2. Node's 204 routing and source and destination address selection mechanism must 205 ensure the destination's IP address is only used in combination with 206 source IP addresses of the network interface the name was resolved 207 on. 209 +--------------------| | 210 +------+ IPv6 | DNS server A |------| IPv6 211 | |-- interface 1 --| saying Peer is | | 212 | | | at: 2001:0db8:0::1 | | 213 | MIF | +--------------------+ +------+ 214 | node | | Peer | 215 | | +--------------------+ +------+ 216 | | IPv6 | DNS server B | | 217 | |-- interface 2 --| saying Peer is | | 218 +------+ | at: 2001:0db8:1::1 |------| IPv6 219 +--------------------+ | 221 Private DNS namespaces and different IP addresses for an FQDN on 222 interfaces 1 and 2. 224 Figure 2 226 Similar situation can happen with IPv6 protocol translation and AAAA 227 record synthesis [RFC6147]. A synthetic AAAA record is guaranteed to 228 be valid only on a network interface it was synthesized on. Figure 3 229 illustrates a scenario where the peer's IPv4 address is synthesized 230 into different IPv6 addresses by DNS servers A and B. 232 +-------------------| +-------+ 233 +------+ IPv6 | DNS server A |----| NAT64 | 234 | |-- interface 1 --| saying Peer is | +-------+ 235 | | | at: A_Pref96:IPv4 | | 236 | MIF | +-------------------+ | +------+ 237 | node | IPv4 +---| Peer | 238 | | +-------------------+ | +------+ 239 | | IPv6 | DNS server B | | 240 | |-- interface 2 --| saying Peer is | +-------+ 241 +------+ | at: B_Pref96:IPv4 |----| NAT64 | 242 +-------------------+ +-------+ 244 AAAA synthesis results in interface specific IPv6 addresses. 246 Figure 3 248 A thing worth noting is that interface specific IP addresses can 249 cause problems also for a single-homed node, if the node retains DNS 250 cache during movement from one network interface to another. After 251 the interface change a node could have both positive and negative DNS 252 cache entries no longer valid on the new network interface. Because 253 of this the cached DNS information should be considered network 254 interface local instead of node global. 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 may 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 chapter 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 suffixes or reverse (PTR record) 351 lookup requests matching to specific network addresses (later 352 referred as "domain" and "network"). For security reasons the DNS 353 server selection information MUST be used only when it is safe to do 354 so, see 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. 387 A resolver SHOULD prioritize between equally trusted DNS servers with 388 help of the DHCP option preference field. The resolver MUST NOT 389 prioritize less trusted DNS servers higher than trusted, even in the 390 case of less trusted server would apparently have additional 391 information. In the case of all other things being equal the 392 resolver shall make the prioritization decision based on its internal 393 preferences. 395 Information from | Information from | Resulting DNS 396 more trusted | less trusted | server priority 397 interface A | interface B | selection 398 --------------------------+------------------------+-------------------- 399 1. Medium priority | Medium priority | Default: A, then B 400 default | default | 401 --------------------------+------------------------+-------------------- 402 2. Medium priority | High priority default | Default: A, then B 403 default | High priority specific | Specific: A, then B 404 --------------------------+------------------------+-------------------- 405 3. Low priority default | Medium priority | Default: B, then A 406 | default | 407 --------------------------+------------------------+-------------------- 408 4. Low priority default | Medium priority | Default: B, then A 409 High priority specific | default | Specific: A, then B 410 --------------------------+------------------------+-------------------- 412 Figure 4: DNS server selection in the case of different trust levels 414 The resolver SHOULD avoid sending queries over different network 415 interfaces in parallel as that wastes resources such as energy. The 416 amount of wasted energy can be significant, for example when radio 417 interfaces has to be started just for the queries. Independently of 418 whether DNS queries are sent in series or parallel, replies for DNS 419 queries MUST be waited until acceptable positive reply is received, 420 all replies are received, or a time out occurs. 422 Because DNSSEC provides cryptographic assurance of the integrity of 423 DNS data, data that can be validated under DNSSEC is necessarily to 424 be preferred over data that cannot be. There are two ways that a 425 node can determine that data is valid under DNSSEC. The first is to 426 perform DNSSEC validation itself. The second is to have a secure 427 connection to an authenticated DNS server, and to rely on that DNS 428 server to perform DNSSEC validation (signalling that it has done so 429 using the AD bit). If a DNS response is not proven to be unmolested 430 using DNSSEC, then a node cannot make a decision to prefer data from 431 any interface with any great assurance: any response could be forged, 432 and there is no way to detect the forgery without DNSSEC. Therefore, 433 a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be 434 validated using DNSSEC if DNS queries sent to other servers are still 435 pending. 437 In the case of validated NXDOMAIN response being received from a DNS 438 server that can provide answers for the queried name a node MUST NOT 439 accept non-validated replies from other DNS servers (see Appendix B 440 for considerations related to multiple trust anchors. 442 A node that accepts DNS server selection rules from non-trusted 443 interfaces and implements DNSSEC validation SHOULD send queries also 444 to (all) other known DNS servers in case a non-validatable response 445 is received from the preferred DNS server. This protects against 446 possible redirection attacks. 448 4.2. DNS server selection DHCPv6 option 450 DHCPv6 option described below can be used to inform resolvers which 451 DNS server should be contacted when initiating forward or reverse DNS 452 lookup procedures. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | OPTION_DNS_SERVER_SELECT | option-len | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 | DNS-recursive-name-server (IPv6 address) | 461 | | 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |prf| Reserved | | 465 +-+-+-+-+-+-+-+-+ Domains and networks | 466 | (variable length) | 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 option-code: OPTION_DNS_SERVER_SELECT (TBD) 472 option-len: Length of the option in octets 474 DNS-recursive-name-server: An IPv6 address of a DNS server 476 prf: DNS server preference, for selecting between 477 equally trusted DNS servers: 478 01 High 479 00 Medium 480 11 Low 481 10 Reserved 483 Reserved: Flags reserved for the future. MUST be set to zero. 485 Domains and networks: The list of domains for forward DNS 486 lookup and networks for reverse DNS lookup the DNS server 487 has special knowledge about. Field MUST be encoded as 488 specified in section "Representation and use of 489 domain names" of [RFC3315]. 490 Special domain of "." is used to indicate 491 capability to resolve global names and act as a 492 default name server. Lack of "." 493 domain on the list indicates DNS server only has 494 information related to listed domains and networks. 495 Networks for reverse mapping are encoded as 496 defined for ip6.arpa [RFC3152] or in-addr.arpa [RFC2317]. 498 DHCPv6 option for explicit domain configuration 500 Figure 5 502 A node SHOULD include an OPTION_ORO option in a DHCPv6 request with 503 the OPTION_DNS_SERVER_SELECT option code to inform the DHCPv6 server 504 about the support for the improved DNS server selection logic. 505 DHCPv6 server receiving this information MAY then choose to provision 506 DNS server addresses only with the OPTION_DNS_SERVER_SELECT. 508 The OPTION_DNS_SERVER_SELECT contains one or more domains the related 509 DNS server has particular knowledge of. The option can occur 510 multiple times in a single DHCPv6 message, if multiple DNS servers 511 are to be configured. 513 IPv6 networks should cover all the domains configured in this option. 514 Networks should be as long as possible to avoid potential collision 515 with information received on other option instances or with options 516 received from DHCPv6 servers of other network interfaces. 517 Overlapping IPv6 networks are interpreted so that the resolver can 518 use any of the DNS servers for queries matching the networks. 520 If the OPTION_DNS_SERVER_SELECT contains a DNS server address already 521 learned from other DHCPv6 servers and possibly through other network 522 interfaces, the node MAY append new networks and domains to the 523 information received earlier. The node MUST NOT remove previously 524 obtained information. However, the node SHOULD NOT extent lifetime 525 of earlier information either. In the case conflicting DNS server 526 address and related information is learned from less trusted 527 interface, the node MAY choose to ignore the option. 529 As the DNS options of [RFC3646], the OPTION_DNS_SERVER_SELECT option 530 MUST NOT appear in any other than the following DHCPv6 messages: 531 Solicit, Advertise, Request, Renew, Rebind, Information-Request, and 532 Reply. 534 The information conveyed in OPTION_DNS_SERVER_SELECT is considered 535 valid until changed or refreshed by general events that trigger 536 DHCPv6 action. In the event that it is desired for the client to 537 request a refresh of the information, use of generic DHCPv6 538 Information Refresh Time Option, as specified in [RFC4242] is 539 envisaged. 541 4.3. DNS server selection DHCPv4 option 543 DHCPv4 option described below can be used to inform resolvers which 544 DNS server should be contacted when initiating forward or reverse DNS 545 lookup procedures. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | CODE | Len | Domain count | Reserved |prf| 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | DNS-recursive-name-server (IPv4 address) | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | | 555 + Domains and networks | 556 | (variable length) | 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 option-code: OPTION_DNS_SERVER_SELECT (TBD) 562 option-len: Length of the option in octets 564 Domain count: Number of domains and networks included 566 DNS-recursive-name-server: An IPv4 address of a DNS server 568 prf: DNS server preference, for selecting between 569 equally trusted DNS servers: 570 01 High 571 00 Medium 572 11 Low 573 10 Reserved 575 Reserved: Flags reserved for the future. MUST be set to zero. 577 Domains and networks: The list of domains for forward DNS 578 lookup and networks for reverse DNS lookup the DNS server 579 has special knowledge about. Field MUST be encoded as 580 specified in section "Representation and use of 581 domain names" of [RFC3315]. 582 Special domain of "." is used to indicate 583 capability to resolve global names and act as a 584 default name server. Lack of "." 585 domain on the list indicates DNS server only has 586 information related to listed domains and networks. 587 Networks for reverse mapping are encoded as 588 defined for ip6.arpa [RFC3152] or in-addr.arpa [RFC2317]. 589 Trailing zeros 590 shall be added until next octet boundary. 592 DHCPv4 option for explicit domain configuration 594 Figure 6 596 The OPTION_DNS_SERVER_SELECT contains one or more domains the related 597 DNS server has particular knowledge of. The option can occur 598 multiple times in a single DHCPv4 message, if multiple DNS servers 599 are to be configured. 601 If multiple instances of OPTION_DNS_SERVER_SELECT are present, then 602 the data portions of all the options are concatenated together as 603 specified in "Encoding Long DHCP Options in the Dynamic Host 604 Configuration Protocol (DHCPv4)" [RFC3396]. 606 If the OPTION_DNS_SERVER_SELECT contains a DNS server address already 607 learned from other DHCPv4 servers and possibly through other network 608 interfaces, the node MAY append new networks and domains to the 609 information received earlier. The node MUST NOT remove previously 610 obtained information. However, the node SHOULD NOT extent lifetime 611 of earlier information either. In the case conflicting DNS server 612 address and related information is learned from less trusted 613 interface, the node MAY choose to ignore the option. 615 4.4. Limitations on use 617 A node MAY use OPTION_DNS_SERVER_SELECT in any of the following four 618 cases. In other cases the node MUST NOT use OPTION_DNS_SERVER_SELECT 619 unless the node is specifically configured to do so. 621 1. The server selection option is delivered across a secure, trusted 622 channel. 624 2. The server selection option is not secured, but the client on a 625 node does DNSSEC validation. 627 3. The server selection option is not secured, the resolver does 628 DNSSEC validation, and the client communicates with the resolver 629 configured with server selection option over a secure, trusted 630 channel. 632 4. The DNS server IP address that is being recommended in the server 633 selection option is known and trusted by the client; that is, the 634 server selection option serves not to introduce the client to a new 635 server, but rather to inform it that a server it has already been 636 configured to trust is available to it for resolving certain domains. 638 4.5. Coexistence with RFC3646 640 The OPTION_DNS_SERVER_SELECT is designed to coexist with 641 OPTION_DNS_SERVERS defined in [RFC3646]. The DNS servers configured 642 via OPTION_DNS_SERVERS MUST be considered as default name servers 643 with medium preference. When both options are received from the same 644 network interface and the OPTION_DNS_SERVER_SELECT contains default 645 DNS server address, the resolver MUST make the decision which one to 646 prefer based on preferences. If OPTION_DNS_SERVER_SELECT defines 647 medium preference then DNS server from OPTION_DNS_SERVER_SELECT SHALL 648 be selected. 650 If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain the 651 same DNS server(s) IPv6 address(es), a node SHALL add the same 652 address of a DNS server to the server list only once. 654 If a node had indicated support for OPTION_DNS_SERVER_SELECT in 655 DHCPv6 request, the DHCPv6 server may choose to omit sending of 656 OPTION_DNS_SERVERS. This enables offloading use case where network 657 administrator wishes to only advertise low priority default DNS 658 servers. 660 4.6. Interactions with OPTION_DOMAIN_LIST and pre-DNS hostnames 662 A node may be configured with DNS search list with 663 OPTION_DOMAIN_LIST. 665 A bare name (a name without any dots) MUST be first treated as a pre- 666 DNS hostname, and only after that the name SHALL be appended with 667 suffix(es) and described DNS server selection logic be utilized. 669 Resolution for the name containing any dots SHOULD first be attempted 670 with DNS servers of all interfaces. Only if the resolution fails the 671 node SHOULD append the name with search list suffix(es) and then 672 again utilize improved DNS server selection algorithm to decide which 673 DNS server(s) to contact. 675 4.7. Considerations on follow-up queries 677 Any follow-up queries that are performed on the basis of an answer 678 received on an interface MUST continue to use the same interface, 679 irrespective of the DNS server selection settings on any other 680 interface. For example, if a node receives a reply with a canonical 681 name (CNAME) or delegation name (DNAME) the follow-up queries MUST be 682 sent to DNS server(s) of the same interface, or to same DNS server, 683 irrespectively of the FQDN received. Otherwise referrals may fail. 685 5. Example of a node behavior 687 Figure 7 illustrates node behavior when it initializes two network 688 interfaces for parallel usage and learns domain and network 689 information from DHCPv6 servers. 691 Application Node DHCPv6 server DHCPv6 server 692 on interface 1 on interface 2 693 | | | 694 | +-----------+ | 695 (1) | | open | | 696 | | interface | | 697 | +-----------+ | 698 | | | 699 (2) | |---option REQ-->| 700 | |<--option RESP--| 701 | | | 702 | +-----------+ | 703 (3) | | store | | 704 | | domains | | 705 | +-----------+ | 706 | | | 707 | +-----------+ | 708 (4) | | open | | 709 | | interface | | 710 | +-----------+ | 711 | | | | 712 (5) | |---option REQ------------------->| 713 | |<--option RESP-------------------| 714 | | | | 715 | +----------+ | | 716 (6) | | store | | | 717 | | domains | | | 718 | +----------+ | | 719 | | | | 721 Illustration of learning domains 723 Figure 7 725 Flow explanations: 727 1. A node opens its first network interface 729 2. The node obtains domain and IPv6 network information for the new 730 interface 1 from DHCPv6 server 732 3. The node stores the learned domains and IPv6 networks for later 733 use 735 4. The node opens its second network interface 2 737 5. The node obtains domain, say 'example.com', and IPv6 network 738 information, say '8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 739 2 from DHCPv6 server 741 6. The node stores the learned domains and networks for later use 743 Figure 8 below illustrates how a resolver uses the learned domain 744 information. Network information use for reverse lookups is not 745 illustrated, but that would go as the figure 7 example. 747 Application Node DHCPv6 server DHCPv6 server 748 on interface 1 on interface 2 749 | | | | 750 (1) |--Name REQ-->| | | 751 | | | | 752 | +----------------+ | | 753 (2) | | DNS server | | | 754 | | prioritization | | | 755 | +----------------+ | | 756 | | | | 757 (3) | |------------DNS resolution------>| 758 | |<--------------------------------| 759 | | | | 760 (4) |<--Name resp-| | | 761 | | | | 763 Example on choosing interface based on domain 765 Figure 8 767 Flow explanations: 769 1. An application makes a request for resolving an FQDN, e.g. 770 'private.example.com' 772 2. A node creates list of DNS servers to contact to and uses 773 configured DNS server information and stored domain information 774 on prioritization decisions. 776 3. The node has chosen interface 2, as from DHCPv6 it was learned 777 earlier that the interface 2 has domain 'example.com'. The node 778 then resolves the requested name using interface 2's DNS server 779 to an IPv6 address 781 4. The node replies to application with the resolved IPv6 address 783 6. Scalability considerations 785 The size limitations of DHCPv6 messages limit the number of domains 786 and networks that can be carried in a configuration option. 787 Including the domains and networks in a DHCPv6 option is best suited 788 for deployments where relatively few carefully selected domains and 789 networks are adequate. 791 7. Considerations for network administrators 793 Network administrators deploying private namespaces should assist 794 advanced nodes in their DNS server selection process by providing 795 information described within this document. 797 Private namespaces MUST be globally unique in order to keep DNS 798 unambiguous and henceforth avoiding caching related issues and 799 destination selection problems (see section 2.3). Exceptions to this 800 rule are domains utilized for local name resolution (such as .local). 802 Private namespaces MUST only consist of subdomains of domains for 803 which the relevant operator provides authoritative name service. 804 Thus, subdomains of example.com are permitted in the private 805 namespace served by an operator's DNS servers only if the same 806 operator provides an SOA record for example.com. 808 To counter against attacks against private namespaces, administrators 809 utilizing this tool SHOULD deploy DNSSEC for their zone. 811 8. Acknowledgements 813 The author would like to thank following people for their valuable 814 feedback and improvement ideas: Mark Andrews, Jari Arkko, Marcelo 815 Bagnulo, Stuart Cheshire, Lars Eggert, Tomohiro Fujisaki, Peter Koch, 816 Suresh Krishnan, Edward Lewis, Kurtis Lindqvist, Arifumi Matsumoto, 817 Erik Nordmark, Steve Padgett, Fabien Rapin, Dave Thaler, Margaret 818 Wasserman, Dan Wing, Brian Carpenter, and Dec Wojciech. Ted Lemon 819 and Julien Laganier receive special thanks for their contributions to 820 security considerations. 822 This document was prepared using xml2rfc template and the related 823 web-tool. 825 9. IANA Considerations 827 This memo includes a new DHCPv6 option and a new DHCPv4 option that 828 requires allocation of new code points. 830 10. Security Considerations 832 It is possible that attackers might try to utilize 833 OPTION_DNS_SERVER_SELECT option to redirect some or all DNS queries 834 sent by a resolver to undesired destinations. The purpose of an 835 attack might be denial-of-service, preparation for man-in-the-middle 836 attack, or something akin. 838 Attackers might try to lure specific traffic by advertising domains 839 and networks from very small to very large scope or simply by trying 840 to place attacker's DNS server as the highest priority default 841 server. 843 The main countermeasure against these attacks is to use this option 844 only when safe to do so, see section 4.4 for details. The safest 845 approach is for nodes to implement validating DNSSEC aware resolvers. 846 Trusting on validation done by a DNS server is a possibility only if 847 a node trusts the DNS server and can use a secure channel for DNS 848 messages. 850 Decision on trust levels of network interfaces depends very much on 851 deployment scenario and types of network interfaces. For example, 852 unmanaged WLAN may be considered less trustworthy than managed 853 cellular or VPN connections. 855 11. References 857 11.1. Normative References 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, March 1997. 862 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 863 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. 865 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 866 August 2001. 868 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 869 and M. Carney, "Dynamic Host Configuration Protocol for 870 IPv6 (DHCPv6)", RFC 3315, July 2003. 872 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 873 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 874 November 2002. 876 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 877 (DHCP) Service for IPv6", RFC 3736, April 2004. 879 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 880 Time Option for Dynamic Host Configuration Protocol for 881 IPv6 (DHCPv6)", RFC 4242, November 2005. 883 11.2. Informative References 885 [I-D.ietf-mif-problem-statement] 886 Blanchet, M. and P. Seite, "Multiple Interfaces and 887 Provisioning Domains Problem Statement", 888 draft-ietf-mif-problem-statement-15 (work in progress), 889 May 2011. 891 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 892 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 893 Wing, "IPv6 Multihoming without Network Address 894 Translation", 895 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01 (work 896 in progress), August 2011. 898 [I-D.wing-behave-dns64-config] 899 Wing, D., "IPv6-only and Dual Stack Hosts on the Same 900 Network with DNS64", draft-wing-behave-dns64-config-03 901 (work in progress), February 2011. 903 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 904 Protocol (DHCP) Domain Search Option", RFC 3397, 905 November 2002. 907 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 908 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 909 December 2003. 911 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 912 More-Specific Routes", RFC 4191, November 2005. 914 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 915 Addresses", RFC 4193, October 2005. 917 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 918 "IPv6 Router Advertisement Option for DNS Configuration", 919 RFC 5006, September 2007. 921 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 922 Beijnum, "DNS64: DNS Extensions for Network Address 923 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 924 April 2011. 926 Appendix A. Best Current Practice for DNS server selection 928 On some private namespace deployments explicit policies for DNS 929 server selection are not available. This section describes ways for 930 nodes to mitigate the problem by sending wide-spread queries and by 931 utilizing possibly existing indirect information elements as hints. 933 A.1. Sending queries out on multiple interfaces in parallel 935 A possible current practice is to send DNS queries out of multiple 936 interfaces and pick up the best out of the received responses. A 937 node SHOULD implement DNSSEC in order to be able to reject responses 938 that cannot be validated. Selection between legitimate answers is 939 implementation specific, but replies from trusted servers should be 940 preferred. 942 A downside of this approach is increased consumption of resources. 943 Namely power consumption if an interface, e.g. wireless, has to be 944 brought up just for the DNS query that could have been resolved also 945 via cheaper interface. Also load on DNS servers is increased. 946 However, local caching of results mitigates these problems, and a 947 node might also learn interfaces that seem to be able to provide 948 'better' responses than other and prefer those - without forgetting 949 fallback required for cases when node is connected to more than one 950 network using private namespaces. 952 A.2. Search list option for DNS forward lookup decisions 954 A node can learn the special DNS suffixes of attached network 955 interfaces from DHCP search list options; DHCPv4 Domain Search Option 956 number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24 957 [RFC3646]. The node behavior is very similar as is illustrated in 958 the example at section 5. While these DHCP options are not intended 959 to be used in DNS server selection, they may be used by the nodes as 960 hints for smarter DNS server prioritization purposes in order to 961 increase likelihood of fast and successful DNS query. 963 Overloading of existing DNS search list options is not without 964 problems: resolvers would obviously use the DNS suffixes learned from 965 search lists also for name resolution purposes. This may not be a 966 problem in deployments where DNS search list options contain few DNS 967 suffixes like 'example.com, private.example.com', but can become a 968 problem if many suffixes are configured. 970 A.3. More specific routes for reverse lookup decision 972 [RFC4191] defines how more specific routes can be provisioned for 973 nodes. This information is not intended to be used in DNS server 974 selection, but nevertheless a node can use this information as a hint 975 about which interface would be best to try first for reverse lookup 976 procedures. A DNS server configured via the same interface as more 977 specific routes is more likely capable to answer reverse lookup 978 questions correctly than DNS server of an another interface. The 979 likelihood of success is possibly higher if DNS server address is 980 received in the same RA [RFC5006] as the more specific route 981 information. 983 A.4. Longest matching prefix for reverse lookup decision 985 A node may utilize the longest matching prefix approach when deciding 986 which DNS server to contact for reverse lookup purposes. Namely, the 987 node may send a DNS query to a DNS server learned over an interface 988 having longest matching prefix to the address being queried. This 989 approach can help in cases where ULA [RFC4193] addresses are used and 990 when the queried address belongs to a node or server within the same 991 network (for example intranet). 993 Appendix B. DNSSEC and multiple answers validating with different trust 994 anchors 996 When validating DNS answers with DNSSEC, a validator might order the 997 list of trust anchors it uses to start validation chains, in terms of 998 the node's preferences for those trust anchors. A node could use 999 this ability in order to select among alternative DNS results from 1000 different interfaces. Suppose that a node has a trust anchor for the 1001 public DNS root, and also has a special-purpose trust anchor for 1002 example.com. An answer is received on interface i1 for 1003 www.example.com, and the validation for that succeeds by using the 1004 public trust anchor. Also, an answer is received on interface i2 for 1005 www.example.com, and the validation for that succeeds by using the 1006 trust anchor for example.com. In this case, the node has evidence 1007 for relying on i2 for answers in the example.com zone. 1009 Authors' Addresses 1011 Teemu Savolainen 1012 Nokia 1013 Hermiankatu 12 D 1014 TAMPERE, FI-33720 1015 FINLAND 1017 Email: teemu.savolainen@nokia.com 1019 Jun-ya Kato 1020 NTT 1021 9-11, Midori-Cho 3-Chome Musashino-Shi 1022 TOKYO, 180-8585 1023 JAPAN 1025 Email: kato@syce.net 1027 Ted Lemon 1028 Nominum, Inc. 1029 2000 Seaport Boulevard 1030 Redwood City, CA 94063 1031 USA 1033 Phone: +1 650 381 6000 1034 Email: Ted.Lemon@nominum.com