idnits 2.17.1 draft-savolainen-mif-dns-server-selection-06.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 (January 7, 2011) is 4859 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) ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-15) exists of draft-ietf-mif-problem-statement-09 == Outdated reference: A later version (-03) exists of draft-wing-behave-dns64-config-02 -- Obsolete informational reference (is this intentional?): RFC 2767 (Obsoleted by RFC 6535) -- Obsolete informational reference (is this intentional?): RFC 5006 (Obsoleted by RFC 6106) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: July 11, 2011 NTT 6 January 7, 2011 8 Improved DNS Server Selection for Multi-Homed Nodes 9 draft-savolainen-mif-dns-server-selection-06 11 Abstract 13 A multi-homed node can be connected to multiple networks that may 14 utilize different DNS namespaces. The node often receives DNS server 15 configuration information from all connected networks. Some of the 16 DNS servers may have information about namespaces other servers do 17 not have. When the multi-homed node needs to utilize DNS, it has to 18 choose which of the servers to contact to. This document describes a 19 policy based method for helping on selection of DNS server for both 20 forward and reverse DNS lookup procedures with help of DNS suffix and 21 IPv6 prefix information received via DHCPv6. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 11, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Problem description for local namespaces with multi-homed 60 nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Fully qualified domain names with limited scopes . . . . . 4 62 2.2. Network interface specific IP addresses . . . . . . . . . 5 63 3. Improved DNS server selection . . . . . . . . . . . . . . . . 7 64 3.1. Procedure for prioritizing DNS servers and handling 65 responses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.2. DNS server selection option . . . . . . . . . . . . . . . 9 67 3.3. Coexistence with RFC3646 . . . . . . . . . . . . . . . . . 11 68 4. Example of a node behavior . . . . . . . . . . . . . . . . . . 12 69 5. Scalability considerations . . . . . . . . . . . . . . . . . . 15 70 6. Considerations for network administrators . . . . . . . . . . 15 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 77 Appendix A. Best Current Practice for DNS server selection . . . 17 78 A.1. Sending queries out on multiple interfaces in parallel . . 18 79 A.2. Search list option for DNS forward lookup decisions . . . 18 80 A.3. More specific routes for reverse lookup decision . . . . . 19 81 A.4. Longest matching prefix for reverse lookup decision . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 A multi-homed node faces several problems over single-homed node as 87 is described in [I-D.ietf-mif-problem-statement]. This document 88 studies in detail the problems local namespaces may cause for multi- 89 homed nodes in the IPv4 and IPv6 domains and provides a solution. 90 The node may be implemented as a host, or as a router such as 91 Consumer Premises Equipment. 93 When multiple namespaces are visible for a node, some DNS servers 94 have information other servers do not have. Because of that, a 95 multi-homed node cannot assume every DNS server is able to provide 96 any piece of information, but instead the node must be able to ask 97 right server for the information it needs. 99 An example of an application that benefits from multi-homing is a web 100 browser that commonly accesses many different destinations and should 101 be able to dynamically communicate over different network interfaces. 103 However, as the IPv4 is being phased out and often uses NATs to 104 achieve similar functions, this document describes a solution only 105 for the IPv6 domain. 107 In deployments where multiple namespaces are present, selection of 108 the correct destination and source addresses for the actual IP 109 connection is usually crucial as well, as the resolved destination's 110 IP address may be only usable on the network interface over which it 111 was resolved on. Hence solution described in this document is 112 assumed to be often used in combination of tools delivering source 113 and destination address selection policies. 115 Node multihoming in general may introduce new attack vectors. This 116 document includes security considerations that will help against 117 possible new attack vectors and also to some existing attack vectors. 119 The Appendix A describes best current practices possible with tools 120 preceding this document and on networks not supporting this 121 specification. As it is possible to solve the problem with less 122 efficient and less explicit manners, this document can be considered 123 as an optimization. However, in some environments this optimization 124 is considered essential. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 2. Problem description for local namespaces with multi-homed nodes 134 This chapter describes two host multi-homing related local namespace 135 scenarios for which the procedure described in chapter 3 provides a 136 solution. Essentially the same challenges may be faced by Consumer 137 Premises Equipment as is described in 138 [I-D.troan-multihoming-without-nat66]. 140 2.1. Fully qualified domain names with limited scopes 142 A multi-homed host may be connecting to one or more networks that are 143 using local namespaces. As an example, the host may have 144 simultaneously open a wireless LAN (WLAN) connection to public 145 Internet, cellular connection to an operator network, and a virtual 146 private network (VPN) connection to a corporate network. When an 147 application initiates a connection establishment to an FQDN, the host 148 needs to be able to choose the right network interface for making a 149 successful DNS query. This is illustrated in the figure 1. An FQDN 150 for a public name can be resolved with any DNS server of any network 151 interface, but for an FQDN of corporation's or operator's service's 152 local name the host would need to be able to correctly select the 153 right network interface for the DNS resolution, i.e. do interface 154 selection already before destination's IP address is known. 156 +---------------+ 157 | DNS server w/ | | Corporate 158 +------+ | public + |----| Intranet 159 | | | corporation's | | 160 | |===== VPN =======| local names | | 161 | | +---------------+ +----+ 162 | MIF | | FW | 163 | host | +----+ 164 | | +---------------+ | 165 | |----- WLAN ------| DNS server w/ |----| Public 166 | | | public names | | Internet 167 | | +---------------+ +----+ 168 | | | FW | 169 | | +---------------+ +----+ 170 | |---- cellular ---| DNS server w/ | | 171 +------+ | public + | | Operator 172 | operator's |----| Intranet 173 | local names | | 174 +---------------+ 176 Split DNS and locally scoped names illustrated 178 Figure 1 180 2.2. Network interface specific IP addresses 182 In the second problem an FQDN as such is valid and resolvable via 183 different network interfaces, but to different and not necessarily 184 globally reachable IP addresses, as is illustrated in the figure 2. 185 This is a problem when a host is single-homed, but for multi-homed 186 host this results in additional challenges: the host's source and 187 destination address selection mechanism must ensure the destination's 188 IP address is only used in combination with source IP addresses of 189 the network interface the name was resolved on. 191 +--------------------| | 192 +------+ IPv6 | DNS server A |------| IPv6 193 | |-- interface 1 --| saying Peer is | | 194 | | | at: 2001:0db8:0::1 | | 195 | MIF | +--------------------+ +------+ 196 | host | | Peer | 197 | | +--------------------+ +------+ 198 | | IPv6 | DNS server B | | 199 | |-- interface 2 --| saying Peer is | | 200 +------+ | at: 2001:0db8:1::1 |------| IPv6 201 +--------------------+ | 203 Split DSN and different IP addresses for an FQDN on interfaces 1 and 204 2. 206 Figure 2 208 Similar situation can happen when IPv6 protocol translation is used 209 in combination with AAAA record synthesis proceduce 210 [I-D.ietf-behave-dns64]. A synthesised AAAA record is guaranteed to 211 be valid only on a network interface it was synthesized on. Figure 3 212 illustrates a scenario where the peer's IPv4 address is synthesized 213 into different IPv6 addresses by DNS servers A and B. The same 214 problem can happen in the IPv4 domain as well if A record synthesis 215 is done, for example as described in Bump-In-the-Stack [RFC2767]. 217 For a related problem for dual-stack hosts in a network with DNS64, 218 where IPv4 should be prioritized over synthesized IPv6, please see 219 [I-D.wing-behave-dns64-config]. 221 +-------------------| +-------+ 222 +------+ IPv6 | DNS server A |----| NAT64 | 223 | |-- interface 1 --| saying Peer is | +-------+ 224 | | | at: A_Pref96:IPv4 | | 225 | MIF | +-------------------+ | +------+ 226 | host | IPv4 +---| Peer | 227 | | +-------------------+ | +------+ 228 | | IPv6 | DNS server B | | 229 | |-- interface 2 --| saying Peer is | +-------+ 230 +------+ | at: B_Pref96:IPv4 |----| NAT64 | 231 +-------------------+ +-------+ 233 AAAA synthesis results in interface specific IPv6 addresses. 235 Figure 3 237 A more complex scenario is an FQDN, which in addition to resolving 238 into network interface specific IP addresses, identifies on different 239 network interfaces completely different peer entities with 240 potentially different set of service offering. In even more complex 241 scenario, an FQDN identifies unique peer entity, but one that 242 provides different services on its different network interfaces. The 243 solution described in this document is not able to tackle these 244 higher layer issues. In fact, some of the problems may be solvable 245 only by user intervention. 247 A thing worth noting is that interface specific IP addresses can 248 cause problems also for a single-homed host, if the host retains its 249 DNS cache during movement from one network interface to another. 250 After the interface change a host could have both positive and 251 negative DNS cache entries invalid for the new network interface. 252 Because of this the cached DNS information should be considered 253 network interface local instead of node global. 255 3. Improved DNS server selection 257 This chapter describes a procedure a (stub / proxy) resolver may 258 utilize for improved DNS server selection in face of multiple 259 namespaces and multiple simultaneously active network interfaces. 261 3.1. Procedure for prioritizing DNS servers and handling responses 263 The resolver SHALL dynamically build for each DNS query a priority 264 list of DNS servers it will contact to. To prioritize DNS servers in 265 safe and optimal way, a node SHOULD ask with DHCPv6 which DNS servers 266 of each network interface are most likely able to successfully serve 267 forward lookup requests matching to specific DNS suffixes or reverse 268 (PTR record) lookup requests matching to specific IPv6 prefixes. 270 A resolver lacking more explicit information shall assume that all 271 information is available from any DNS server of any network 272 interface. The DNS servers learnt by other DNS server address 273 configuration methods MUST be handled as medium priority default 274 servers. 276 When a resource record is to be resolved, the resolver SHOULD give 277 highest precedence to the DNS servers explicitly known to serve 278 matching suffixes or prefixes. However, the resolver MUST take into 279 account different trust levels of pieces of DNS server selection 280 information the resolver has received from node's network interfaces. 281 The resolver MUST generally prefer more trusted DNS servers and less 282 trusted DNS server MAY be of highest priority only if trusted 283 interfaces specifically configure DNS servers with low priority. The 284 non-exhaustive list on table 1 illustrates how the different trust 285 levels of received DNS server selection information MUST influence 286 the DNS server selection logic. 288 Information from | Information from | Resulting DNS 289 from more trusted | less trusted | server priority 290 interface A | interface B | selection 291 --------------------------+------------------------+-------------------- 292 1. Medium priority | Medium priority | Default: A, then B 293 default | default | 294 --------------------------+------------------------+-------------------- 295 2. Medium priority | High priority default | Default: A, then B 296 default | High priority specific | Specific: A, then B 297 --------------------------+------------------------+-------------------- 298 3. Low priority default | Medium priority | Default: B, then A 299 | default | 300 --------------------------+------------------------+-------------------- 301 4. Low priority default | Medium priority | Default: B, then A 302 High priority specific | default | Specific: A, then B 303 --------------------------+------------------------+-------------------- 305 Figure 4: DNS server selection in case of different trust levels 307 The resolver SHOULD avoid sending queries to different interfaces in 308 parallel as that may waste resources, sometimes significantly, and 309 would also unnecessary reveal information about ongoing 310 communications. Independently of whether DNS queries are sent in 311 series or parallel, replies for DNS queries MUST be waited until 312 acceptable positive reply is received, all replies are received, or 313 time out occurs. Specifically, the resolver MUST NOT proceed with a 314 positive reply from less trusted server that cannot be validated with 315 DNSSEC if the DNS query sent to more trusted server is still pending. 316 (DISCUSS: What about those DNS servers that instead of negative 317 answer always return positive reply with an IP address of some 318 captive portal?) 320 For the scenario where an FQDN maps to same service but different IP 321 addresses on different network interfaces, the source address 322 selection algorithm must be able to pick a source address from the 323 network interface that was used for DNS resolution. 325 When local namespace are present a negative reply from a DNS server 326 implies only that the particular DNS server was not able to serve the 327 query. However, it is not probable that the secondary DNS servers on 328 the same network interface, on a same administrative domain, would be 329 able to serve either. Therefore, the next DNS server resolver 330 contacts SHOULD be from another network interface. 332 Resolver SHOULD use DNSSEC to validate all received DNS replies. In 333 the case DNSSEC validation fails the resolver MUST resend the query 334 to the next preferred DNS server. 336 3.2. DNS server selection option 338 A DHCPv6 option described below is used to inform resolvers which DNS 339 server should be contacted when initiating forward or reverse DNS 340 lookup procedures. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | OPTION_DNS_SERVER_SELECT | option-len | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 | DNS-recursive-name-server (IPv6 address) | 349 | | 350 | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |prf| Reserved | | 353 +-+-+-+-+-+-+-+-+ DNS suffixes and prefixes | 354 | (variable length) | 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 option-code: OPTION_DNS_SERVER_SELECT (TBD) 360 option-len: Lenght of the option in octets 362 DNS-recursive-name-server: An IPv6 address of a DNS server 364 prf: DNS server preference: 366 01 High 367 00 Medium 368 11 Low 369 10 Reserved - MUST NOT be sent 371 The preference is used when selecting between 372 equally trusted DNS servers. 374 (Editor's note: this field is under consideration 375 - really needed or not?) 377 Reserved: Flags reserved for the future. MUST be set to 378 zero. 380 DNS suffixes and prefixes: The list of DNS suffixes for forward DNS 381 lookup and prefixes for reverse DNS lookup the DNS server 382 has special knowledge about. Field MUST be encoded as 383 specified in section "Representation and use of 384 domain names" of [RFC3315]. 385 Additionally, special suffix of "." is used to indicate 386 capability to resolve global names. Lack of "." 387 suffix on the list indicates DNS server has only local 388 information. Prefixes for reverse mapping are encoded as 389 defined for ip6.arpa [RFC3152]. 391 DHCPv6 option for explicit DNS suffix configuration 393 Figure 5 395 A node SHOULD include an OPTION_ORO option in DHCPv6 request with the 396 OPTION_DNS_SERVER_SELECT option code to inform the DHCPv6 server 397 about the support for the improved DNS server selection logic. 398 DHCPv6 server receiving this information MAY then choose to provision 399 DNS server addresses only with OPTION_DNS_SERVER_SELECT. 401 The OPTION_DNS_SERVER_SELECT contains one or more DNS suffixes the 402 related DNS server has particular knowledge of (i.e. local 403 namespaces). The option can occur multiple times in a single DHCPv6 404 message, if multiple DNS servers are to be configured. 406 A resolver SHOULD prioritize between equally trusted DNS servers with 407 help of the preference field. The resolver MUST NOT prioritize less 408 trusted DNS servers higher than trusted, even in the case of less 409 trusted server would apprently have additional information. In case 410 all other things being equal the resolver shall make the 411 prioritization decision based on its internal preferences. 413 IPv6 prefixes should cover all the DNS suffixes configured in this 414 option. Prefixes should be as long as possible to avoid collision 415 with information received on other option instances or with options 416 received from DHCPv6 servers of other network interfaces. 417 Overlapping IPv6 prefixes are interpreted so that the resolver can 418 use any or all of the DNS servers for queries mathing the prefixes. 420 As the DNS options of [RFC3646], the OPTION_DNS_SERVER_SELECT option 421 MUST NOT appear in any other than the following messages: Solicit, 422 Advertise, Request, Renew, Rebind, Information-Request, and Reply. 424 The node SHOULD create a host specific route for the DNS server 425 address. The route must point to the interface DNS server address 426 was learned on. This is required to ensure DNS queries are sent out 427 via the right interface. 429 In the case of a DNS server replying negatively to a question having 430 matching suffix, it will be for implementation to decide whether to 431 consider that as a final response, or whether to ask also from other 432 DNS servers. The implementation decision may be based, for example, 433 on deployment or trust models. 435 3.3. Coexistence with RFC3646 437 The OPTION_DNS_SERVER_SELECT is designed to coexist with 438 OPTION_DNS_SERVERS defined in [RFC3646]. The DNS servers configured 439 via OPTION_DNS_SERVERS MUST BE considered as default name servers 440 with medium preference. When both options are received from the same 441 network interface and the OPTION_DNS_SERVER_SELECT contains default 442 DNS server address, the resolver SHOULD make decision which one to 443 prefer based on preferences. If OPTION_DNS_SERVER_SELECT defines 444 medium preference then DNS server selection decision is 445 implementation specific. All default servers are assumed to be able 446 to resolve queries for global names. 448 If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain the 449 same DNS server(s) IPv6 address(es), only one instance of each DNS 450 servers' IPv6 addresses shall be added to the DNS server list. 452 If a node had indicated support for OPTION_DNS_SERVER_SELECT in 453 DHCPv6 request, the DHCPv6 server may choose to omit sending of 454 OPTION_DNS_SERVERS. This enables offloading use case where network 455 administrator wishes to only advertise low priority default DNS 456 servers. 458 4. Example of a node behavior 460 Figure 5 illustrates node behavior when it initializes two network 461 interfaces for parallel usage and learns DNS suffix and prefix 462 information from DHCPv6 servers. 464 Application Node DHCPv6 server DHCPv6 server 465 on interface 1 on interface 2 466 | | | 467 | +-----------+ | 468 (1) | | open | | 469 | | interface | | 470 | +-----------+ | 471 | | | 472 (2) | |---option REQ-->| 473 | |<--option RESP--| 474 | | | 475 | +-----------+ | 476 (3) | | store | | 477 | | suffixes | | 478 | +-----------+ | 479 | | | 480 | +-----------+ | 481 (4) | | open | | 482 | | interface | | 483 | +-----------+ | 484 | | | | 485 (5) | |---option REQ------------------->| 486 | |<--option RESP-------------------| 487 | | | | 488 | +----------+ | | 489 (6) | | store | | | 490 | | suffixes | | | 491 | +----------+ | | 492 | | | | 494 Illustration of learning DNS suffixes 496 Figure 6 498 Flow explanations: 500 1. A node opens its first network interface 502 2. The node obtains DNS suffix and IPv6 prefix information for the 503 new interface 1 from DHCPv6 server 505 3. The node stores the learned DNS suffixes and IPv6 prefixes for 506 later use 508 4. The node opens its seconds network interface 2 510 5. The node obtains DNS suffix, say 'example.com', and IPv6 prefix 511 information, say '8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 512 2 from DHCPv6 server 514 6. The node stores the learned DNS suffixes and prefixes for later 515 use 517 Figure 6 below illustrates how a resolver uses the learned suffix 518 information. Prefix information use for reverse lookups is not 519 illustrated, but that would go as the figure 6 example. 521 Application Node DHCPv6 server DHCPv6 server 522 on interface 1 on interface 2 523 | | | | 524 (1) |--Name REQ-->| | | 525 | | | | 526 | +----------------+ | | 527 (2) | | DNS server | | | 528 | | prioritization | | | 529 | +----------------+ | | 530 | | | | 531 (3) | |------------DNS resolution------>| 532 | |<--------------------------------| 533 | | | | 534 (4) |<--Name resp-| | | 535 | | | | 537 Example on choosing interface based on DNS suffix 539 Figure 7 541 Flow explanations: 543 1. An application makes a request for resolving an FQDN, e.g. 544 'private.example.com' 546 2. A node creates list of DNS servers to contact to and uses 547 configured DNS server information and stored DNS suffix 548 information on priorization decisions. 550 3. The node has chosen interface 2, as from DHCPv6 it was learned 551 earlier that the interface 2 has DNS suffix 'example.com'. The 552 node then resolves the requested name using interface 2's DNS 553 server to an IPv6 address 555 4. The node replies to application with the resolved IPv6 address 557 5. Scalability considerations 559 The size limitations of DHCPv6 messages limit the number of suffixes 560 and prefixes that can be carried in a configuration option. 561 Including the suffixes and prefixes in a DHCPv6 option is best suited 562 for deployments where relatively few carefully selected suffixes and 563 prefixes are adequate. 565 6. Considerations for network administrators 567 Network administrators deploying private namespaces should assist 568 advanced hosts in the DNS server selection by providing information 569 described in this memo for nodes. To ensure nodes' source and 570 destination IP address selection also works correctly, network 571 administrators should also deploy related technologies for that 572 purpose. 574 The solution described herein is best for selecting a DNS server 575 having knowledge of some namespaces. The solution is not able to 576 make the right decision in a scenario where same name points to 577 different services on different network interfaces. Network 578 administrators are recommended to avoid overloading of namespaces in 579 such manner. 581 To mitigate against attacks against local namespaces, administrators 582 utilizing this tool should deploy DNSSEC for their zone. 584 7. Acknowledgements 586 The author would like to thank following people for their valuable 587 feedback and improvement ideas: Mark Andrews, Jari Arkko, Marcelo 588 Bagnulo, Stuart Cheshire, Lars Eggert, Tomohiro Fujisaki, Peter Koch, 589 Suresh Krishnan, Edward Lewis, Kurtis Lindqvist, Arifumi Matsumoto, 590 Erik Nordmark, Steve Padgett, Fabien Rapin, Dave Thaler, Margaret 591 Wasserman, Dan Wing, and Dec Wojciech. Ted Lemon and Julien Laganier 592 receive special thanks for their contributions to security 593 considerations. 595 This document was prepared using xml2rfc template and the related 596 web-tool. 598 8. IANA Considerations 600 This memo includes a new DHCPv6 option that requires allocation of a 601 new code point. 603 9. Security Considerations 605 It is possible that attackers might try to utilize 606 OPTION_DNS_SERVER_SELECT option to redirect some or all DNS queries 607 sent by a resolver to undesired destinations. The purpose of an 608 attack might be denial-of-service, preparation for man-in-the-middle 609 attack, or something akin. 611 Attackers might try to lure specific traffic by advertising DNS 612 suffixes and prefixes from very small to very large scope or simply 613 by trying to place attacker's DNS server as the highest priority 614 default server. 616 The main countermeasure against these attacks is to systematically 617 prioritize more trusted DNS servers higher than less trusted ones. 618 Additionally, resolvers should implement DNSSEC to be able to 619 validate DNS responses received via any of its interfaces. 621 Decision on trust levels of network interfaces depends very much on 622 deployment scenario and types of network interfaces. For example, 623 unmanaged WLAN may be considered less trustworthy than managed 624 cellular or VPN connections. 626 A node MAY also choose, or be configured, to obtain DNS server 627 selection rules only from selected trusted interfaces, in which case 628 it would be in the hands of administrators of these trusted 629 interfaces whether or not to allow redirection, offloading, of DNS 630 queries to untrusted interfaces (case 4 of table 1). 632 10. References 634 10.1. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 640 August 2001. 642 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 643 and M. Carney, "Dynamic Host Configuration Protocol for 644 IPv6 (DHCPv6)", RFC 3315, July 2003. 646 10.2. Informative References 648 [I-D.ietf-behave-dns64] 649 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 650 "DNS64: DNS extensions for Network Address Translation 651 from IPv6 Clients to IPv4 Servers", 652 draft-ietf-behave-dns64-11 (work in progress), 653 October 2010. 655 [I-D.ietf-mif-problem-statement] 656 Blanchet, M. and P. Seite, "Multiple Interfaces and 657 Provisioning Domains Problem Statement", 658 draft-ietf-mif-problem-statement-09 (work in progress), 659 October 2010. 661 [I-D.troan-multihoming-without-nat66] 662 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 663 Wing, "IPv6 Multihoming without Network Address 664 Translation", draft-troan-multihoming-without-nat66-01 665 (work in progress), July 2010. 667 [I-D.wing-behave-dns64-config] 668 Wing, D., "DNS64 Resolvers and Dual-Stack Hosts", 669 draft-wing-behave-dns64-config-02 (work in progress), 670 February 2010. 672 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 673 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 674 RFC 2767, February 2000. 676 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 677 Protocol (DHCP) Domain Search Option", RFC 3397, 678 November 2002. 680 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 681 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 682 December 2003. 684 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 685 More-Specific Routes", RFC 4191, November 2005. 687 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 688 Addresses", RFC 4193, October 2005. 690 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 691 "IPv6 Router Advertisement Option for DNS Configuration", 692 RFC 5006, September 2007. 694 Appendix A. Best Current Practice for DNS server selection 696 On some split-DNS deployments explicit policies for DNS server 697 selection are not available. This section describes ways for hosts 698 to mitigate the problem by sending wide-spread queries and by 699 utilizing possibly existing indirect information elements as hints. 701 A.1. Sending queries out on multiple interfaces in parallel 703 A possible current practice is to send DNS queries out of multiple 704 interfaces and pick up the best out of the received responses. A 705 host SHOULD implement DNSSEC in order to be able to reject responses 706 that cannot be validated. Selection between legitimate answers is 707 implementation specific, but positive replies should be preferred. 709 A downside of this approach is increased consumption of resources. 710 Namely power consumption if an interface, e.g. wireless, has to be 711 brought up just for the DNS query that could have been resolved also 712 via cheaper interface. Also load on DNS servers is increased. 713 However, local caching of results mitigates these problems, and a 714 node might also learn interfaces that seem to be able to provide more 715 responses than other and prefer those - without forgetting fallback 716 required for cases when node is connected to more than one network 717 using local namespaces. 719 Another downside is revealing to all DNS servers the names a host is 720 connecting to. For example, a DNS server of public hotspot could 721 learn all the private names host is trying to connect on other 722 interfaces. 724 A.2. Search list option for DNS forward lookup decisions 726 A host can learn the special DNS suffixes of attached network 727 interfaces from DHCP search list options; DHCPv4 Domain Search Option 728 number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24 729 [RFC3646]. The host behavior is very similar as is illustrated in 730 the example at section 3.3. While these DHCP options are not 731 intented to be used in DNS server selection, they may be used by the 732 host for smart DNS server prioritization purposes in order to 733 increase likelyhood of fast and successful DNS query. 735 Overloading of existing DNS search list options is not without 736 problems: resolvers would obviously use the DNS suffixes learned from 737 search lists also for name resolution purposes. This may not be a 738 problem in deployments where DNS search list options contain few DNS 739 suffixes like 'example.com, private.example.com', but can become a 740 problem if many suffixes are configured. 742 A.3. More specific routes for reverse lookup decision 744 [RFC4191] defines how more specific routes can be provisioned for 745 hosts. This information is not intented to be used in DNS server 746 selection, but nevertheless a host can use this information as a hint 747 about which interface would be best to try first for reverse lookup 748 procedures. A DNS server configured via the same interface as more 749 specific routes is likely more capable to answer reverse lookup 750 questions than DNS server of an another interface. The likelyhood of 751 success is possibly higher if DNS server address is received in the 752 same RA [RFC5006] as the more specific route information. 754 A.4. Longest matching prefix for reverse lookup decision 756 A host may utilize the longest matching prefix approach when deciding 757 which DNS server to contact for reverse lookup purposes. Namely, the 758 host may send a DNS query to a DNS server learned over an interface 759 having longest matching prefix to the address being queried. This 760 approach can help in cases where ULA [RFC4193] addresses are used and 761 when the queried address belongs to a host or server within the same 762 network (for example intranet). 764 Authors' Addresses 766 Teemu Savolainen 767 Nokia 768 Hermiankatu 12 D 769 TAMPERE, FI-33720 770 FINLAND 772 Email: teemu.savolainen@nokia.com 774 Jun-ya Kato 775 NTT 776 9-11, Midori-Cho 3-Chome Musashino-Shi 777 TOKYO, 180-8585 778 JAPAN 780 Email: kato@syce.net