idnits 2.17.1 draft-savolainen-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 17, 2010) is 4963 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 (-11) exists of draft-ietf-behave-dns64-10 == Outdated reference: A later version (-15) exists of draft-ietf-mif-problem-statement-07 == 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 (~~), 4 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: March 21, 2011 NTT 6 September 17, 2010 8 Improved DNS Server Selection for Multi-Homed Nodes 9 draft-savolainen-mif-dns-server-selection-04 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 selecting DNS server for both forward and 20 reverse DNS lookup procedures with help of DNS suffix and IPv6 prefix 21 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 March 21, 2011. 40 Copyright Notice 42 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Fully qualified domain names with limited scopes . . . . . 4 62 2.2. Network interface specific IP addresses . . . . . . . . . 4 63 3. Improved DNS server selection procedure . . . . . . . . . . . 6 64 3.1. DNS server selection option . . . . . . . . . . . . . . . 7 65 4. Example of a node behavior . . . . . . . . . . . . . . . . . . 9 66 5. Scalability considerations . . . . . . . . . . . . . . . . . . 12 67 6. Considerations for network administrators . . . . . . . . . . 12 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9.1. Suffix matching example . . . . . . . . . . . . . . . . . 13 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Appendix A. Best Current Practice for DNS server selection . . . 15 76 A.1. Search list option for DNS forward lookup decisions . . . 15 77 A.2. More specific routes for reverse lookup decision . . . . . 15 78 A.3. Longest matching prefix for reverse lookup decision . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 A multi-homed node faces several problems over single-homed node as 84 is described in [I-D.ietf-mif-problem-statement]. This document 85 studies in detail the problems local namespaces may cause for multi- 86 homed nodes in the IPv4 and IPv6 domains and provides a solution. 87 The node may be implemented as a host, or as a router such as 88 Consumer Premises Equipment. 90 When multiple namespaces are visible for a node, some DNS servers 91 have information other servers do not have. Because of that, a 92 multi-homed node cannot assume every DNS server is able to provide 93 any piece of information, but instead the node must be able to ask 94 right server for the information it needs. 96 An example of an application that benefits from multi-homing is a web 97 browser that commonly accesses many different destinations and should 98 be able to dynamically communicate over different network interfaces. 100 However, as the IPv4 is being phased out and often uses NATs to 101 achieve similar functions, this document describes a solution only 102 for the IPv6 domain. 104 In deployments where multiple namespaces are present, selection of 105 the correct destination and source addresses for the actual IP 106 connection is usually crucial as well, as the resolved destination's 107 IP address may be only usable on the network interface over which it 108 was resolved on. Hence solution described in this document is 109 assumed to be often used in combination of tools delivering source 110 and destination address selection policies. 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Problem description for local namespaces with multi-homed nodes 120 This chapter describes two host multi-homing related local namespace 121 scenarios for which the procedure described in chapter 3 provides a 122 solution. Essentially the same challenges may be faced by Consumer 123 Premises Equipment as is described in 124 [I-D.troan-multihoming-without-nat66]. 126 2.1. Fully qualified domain names with limited scopes 128 A multi-homed host may be connecting to one or more networks that are 129 using local namespaces. As an example, the host may have 130 simultaneously open a wireless LAN (WLAN) connection to public 131 Internet, cellular connection to an operator network, and a virtual 132 private network (VPN) connection to a corporate network. When an 133 application initiates a connection establishment to an FQDN, the host 134 needs to be able to choose the right network interface for making a 135 successful DNS query. This is illustrated in the figure 1. An FQDN 136 for a public name can be resolved with any DNS server of any network 137 interface, but for an FQDN of corporation's or operator's service's 138 local name the host would need to be able to correctly select the 139 right network interface for the DNS resolution, i.e. do interface 140 selection already before destination's IP address is known. 142 +---------------+ 143 | DNS server w/ | | Corporate 144 +------+ | public + |----| Intranet 145 | | | corporation's | | 146 | |===== VPN =======| local names | | 147 | | +---------------+ +----+ 148 | MIF | | FW | 149 | host | +----+ 150 | | +---------------+ | 151 | |----- WLAN ------| DNS server w/ |----| Public 152 | | | public names | | Internet 153 | | +---------------+ +----+ 154 | | | FW | 155 | | +---------------+ +----+ 156 | |---- cellular ---| DNS server w/ | | 157 +------+ | public + | | Operator 158 | operator's |----| Intranet 159 | local names | | 160 +---------------+ 162 Split DNS and locally scoped names illustrated 164 Figure 1 166 2.2. Network interface specific IP addresses 168 In the second problem an FQDN as such is valid and resolvable via 169 different network interfaces, but to different and not necessarily 170 globally reachable IP addresses, as is illustrated in the figure 2. 171 This is a problem when a host is single-homed, but for multi-homed 172 host this results in additional challenges: the host's source and 173 destination address selection mechanism must ensure the destination's 174 IP address is only used in combination with source IP addresses of 175 the network interface the name was resolved on. 177 +--------------------| | 178 +------+ IPv6 | DNS server A |------| IPv6 179 | |-- interface 1 --| saying Peer is | | 180 | | | at: 2001:0db8:0::1 | | 181 | MIF | +--------------------+ +------+ 182 | host | | Peer | 183 | | +--------------------+ +------+ 184 | | IPv6 | DNS server B | | 185 | |-- interface 2 --| saying Peer is | | 186 +------+ | at: 2001:0db8:1::1 |------| IPv6 187 +--------------------+ | 189 Split DSN and different IP addresses for an FQDN on interfaces 1 and 190 2. 192 Figure 2 194 Similar situation can happen when IPv6 protocol translation is used 195 in combination with AAAA record synthesis proceduce 196 [I-D.ietf-behave-dns64]. A synthesised AAAA record is guaranteed to 197 be valid only on a network interface it was synthesized on. Figure 3 198 illustrates a scenario where the peer's IPv4 address is synthesized 199 into different IPv6 addresses by DNS servers A and B. The same 200 problem can happen in the IPv4 domain as well if A record synthesis 201 is done, for example as described in Bump-In-the-Stack [RFC2767]. 203 For a related problem for dual-stack hosts in a network with DNS64, 204 where IPv4 should be prioritized over synthesized IPv6, please see 205 [I-D.wing-behave-dns64-config]. 207 +-------------------| +-------+ 208 +------+ IPv6 | DNS server A |----| NAT64 | 209 | |-- interface 1 --| saying Peer is | +-------+ 210 | | | at: A_Pref96:IPv4 | | 211 | MIF | +-------------------+ | +------+ 212 | host | IPv4 +---| Peer | 213 | | +-------------------+ | +------+ 214 | | IPv6 | DNS server B | | 215 | |-- interface 2 --| saying Peer is | +-------+ 216 +------+ | at: B_Pref96:IPv4 |----| NAT64 | 217 +-------------------+ +-------+ 219 AAAA synthesis results in interface specific IPv6 addresses. 221 Figure 3 223 A more complex scenario is an FQDN, which in addition to resolving 224 into network interface specific IP addresses, identifies on different 225 network interfaces completely different peer entities with 226 potentially different set of service offering. In even more complex 227 scenario, an FQDN identifies unique peer entity, but one that 228 provides different services on its different network interfaces. The 229 solution described in this document is not able to tackle these 230 higher layer issues. In fact, some of the problems may be solvable 231 only by user intervention. 233 A thing worth noting is that interface specific IP addresses can 234 cause problems also for a single-homed host, if the host retains its 235 DNS cache during movement from one network interface to another. 236 After the interface change a host could have both positive and 237 negative DNS cache entries invalid for the new network interface. 238 Because of this the cached DNS information should be considered 239 network interface local instead of node global. 241 3. Improved DNS server selection procedure 243 This chapter documents a procedure a (stub / proxy) resolver may 244 utilize for DNS server selection in face of multiple namespaces. 246 Essentially, the resolver shall dynamically build for each DNS query 247 a priority list of DNS servers it will try to contact to. The 248 resolver shall cycle through the list until a positive reply is 249 received, or until all selected DNS servers have been contacted or 250 timed out. (DISCUSS: What about those DNS servers that instead of 251 negative answer always return positive reply with an IP address of 252 some default HTTP server, which purpose is just to say 'authenticate' 253 or 'page not found'? Maybe DNSSEC would help here, i.e. roll through 254 DNS servers until one provides a response that can be validated?) 256 To prioritize DNS servers in an optimal way, the resolver should ask 257 with DHCPv6 which DNS servers are most likely able to successfully 258 serve forward lookup requests matching to specific DNS suffixes or 259 reverse (PTR record) lookup requests matching to specific IPv6 260 prefixes. 262 A resolver lacking more explicit information shall assume that all 263 information is available from any DNS server of any network 264 interface. 266 Additionally, the resolver may utilize any other information it may 267 have, e.g. possible user's preferences, node's general preferences 268 between network interfaces, differences on trust levels of network 269 interfaces (see Security Considerations), or any other piece of 270 information. 272 When a resource record is to be resolved, the resolver MUST give 273 highest precedence to the DNS servers explicitly known to serve 274 matching suffixes or prefixes. A node may need to remember the 275 interface used for successfuly query in order to be able to improve 276 source address selection. 278 For the scenario where an FQDN maps to same service but different IP 279 addresses on different network interfaces, the source address 280 selection algorithm must be able to pick a source address from the 281 network interface that was used for DNS resolution. 283 When local namespace are present a negative reply from a DNS server 284 implies only that the particular DNS server was not able to serve the 285 query. However, it is not probable that the secondary DNS servers on 286 the same network interface, on a same administrative domain, would be 287 able to serve either. Therefore, the next DNS server resolver 288 contacts should be from another network interface. 290 3.1. DNS server selection option 292 A DHCPv6 option described below is used to inform nodes which DNS 293 server should be contacted when initiating forward or reverse DNS 294 lookup procedures. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | OPTION_DNS_SERVER_SELECT | option-len | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 | DNS-recursive-name-server (IPv6 address) | 303 | | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |prf| Reserved | | 307 +-+-+-+-+-+-+-+-+ DNS suffixes and prefixes | 308 | (variable length) | 309 | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 option-code: OPTION_DNS_SERVER_SELECT (TBD) 314 option-len: Lenght of the option in octets 316 DNS-recursive-name-server: An IPv6 address of a DNS server 318 prf: DNS server preference: 320 01 High 321 00 Medium 322 11 Low 323 10 Reserved - MUST NOT be sent 325 Reserved: Flags reserved for the future. MUST be set to 326 zero. 328 DNS suffixes and prefixes: The list of DNS suffixes for forward DNS 329 lookup and prefixes for reverse DNS lookup the DNS server 330 has special knowledge about. Field MUST be encoded as 331 specified in section "Representation and use of 332 domain names" of [RFC3315]. 333 Additionally, special suffix of "." is used to indicate 334 capability to resolve global names. Lack of "." 335 suffix on the list indicates DNS server has only local 336 information. Prefixes for reverse mapping are encoded as 337 defined for ip6.arpa [RFC3152]. 339 DHCPv6 option for explicit DNS suffix configuration 341 Figure 4 343 The OPTION_DNS_SERVER_SELECT contains one or more DNS suffixes the 344 related DNS server has particular knowledge of (i.e.. local 345 namespaces). The option can occur multiple times in a single DHCPv6 346 message, if multiple DNS servers are to be configured. 348 A node can prioritize DNS servers with help of preference field. 350 IPv6 prefixes should cover all the DNS suffixes configured in this 351 option. Prefixes should be as long as possible to avoid collision 352 with information received on other option instances or with options 353 received from DHCPv6 servers of other network interfaces. 354 Overlapping IPv6 prefixes are interpreted by a node so that the 355 resolver can use multiple DNS servers for queries mathing the 356 prefixes. 358 As the DNS options of [RFC3646], the OPTION_DNS_SERVER_SELECT option 359 MUST NOT appear in any other than the following messages: Solicit, 360 Advertise, Request, Renew, Rebind, Information-Request, and Reply. 362 For backwards compatibility reasons the DHCPv6 message containing 363 OPTION_DNS_SERVER_SELECT also likely contains OPTION_DNS_SERVERS 364 option. In case both options contain the same IPv6 addresses, only 365 one copy of the IPv6 address of DNS server shall be added to the DNS 366 server list. 368 In the case of a DNS server replying negatively to a question having 369 matching suffix, it will be for implementation to decide whether to 370 consider that as a final response, or whether to ask also from other 371 DNS servers. The implementation decision may be based, for example, 372 on deployment or trust models. 374 4. Example of a node behavior 376 Figure 5 illustrates node behavior when it initializes two network 377 interfaces for parallel usage and learns DNS suffix and prefix 378 information from DHCPv6 servers. 380 Application Node DHCPv6 server DHCPv6 server 381 on interface 1 on interface 2 382 | | | 383 | +-----------+ | 384 (1) | | open | | 385 | | interface | | 386 | +-----------+ | 387 | | | 388 (2) | |---option REQ-->| 389 | |<--option RESP--| 390 | | | 391 | +-----------+ | 392 (3) | | store | | 393 | | suffixes | | 394 | +-----------+ | 395 | | | 396 | +-----------+ | 397 (4) | | open | | 398 | | interface | | 399 | +-----------+ | 400 | | | | 401 (5) | |---option REQ------------------->| 402 | |<--option RESP-------------------| 403 | | | | 404 | +----------+ | | 405 (6) | | store | | | 406 | | suffixes | | | 407 | +----------+ | | 408 | | | | 410 Illustration of learning DNS suffixes 412 Figure 5 414 Flow explanations: 416 1. A node opens its first network interface 418 2. The node obtains DNS suffix and IPv6 prefix information for the 419 new interface 1 from DHCPv6 server 421 3. The node stores the learned DNS suffixes and IPv6 prefixes for 422 later use 424 4. The node opens its seconds network interface 2 426 5. The node obtains DNS suffix, say 'example.com', and IPv6 prefix 427 information, say '8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 428 2 from DHCPv6 server 430 6. The node stores the learned DNS suffixes and prefixes for later 431 use 433 Figure 6 below illustrates how a resolver uses the learned suffix 434 information. Prefix information use for reverse lookups is not 435 illustrated, but that would go as the figure 6 example. 437 Application Node DHCPv6 server DHCPv6 server 438 on interface 1 on interface 2 439 | | | | 440 (1) |--Name REQ-->| | | 441 | | | | 442 | +----------------+ | | 443 (2) | | DNS server | | | 444 | | prioritization | | | 445 | +----------------+ | | 446 | | | | 447 (3) | |------------DNS resolution------>| 448 | |<--------------------------------| 449 | | | | 450 (4) |<--Name resp-| | | 451 | | | | 453 Example on choosing interface based on DNS suffix 455 Figure 6 457 Flow explanations: 459 1. An application makes a request for resolving an FQDN, e.g. 460 'private.example.com' 462 2. A node creates list of DNS servers to contact to and uses 463 configured DNS server information and stored DNS suffix 464 information on priorization decisions. 466 3. The node has chosen interface 2, as from DHCPv6 it was learned 467 earlier that the interface 2 has DNS suffix 'example.com'. The 468 node then resolves the requested name using interface 2's DNS 469 server to an IPv6 address 471 4. The node replies to application with the resolved IPv6 address 473 5. Scalability considerations 475 The size limitations of DHCPv6 messages limit the number of suffixes 476 and prefixes that can be carried in a configuration option. 477 Including the suffixes and prefixes in a DHCPv6 option is best suited 478 for deployments where relatively few carefully selected suffixes and 479 prefixes are adequate. 481 6. Considerations for network administrators 483 Network administrators deploying private namespaces should assist 484 advanced hosts in the DNS server selection by providing information 485 described in this memo for nodes. To ensure nodes' source and 486 destination IP address selection also works correctly, network 487 administrators should also deploy related technologies for that 488 purpose. 490 The solution described herein is best for selecting a DNS server 491 having knowledge of some namespaces. The solution is not able to 492 make the right decision in a scenario where same name points to 493 different services on different network interfaces. Network 494 administrators are recommended to avoid overloading of namespaces in 495 such manner. 497 7. Acknowledgements 499 The author would like to thank following people for their valuable 500 feedback and improvement ideas: Mark Andrews, Jari Arkko, Marcelo 501 Bagnulo, Stuart Cheshire, Lars Eggert, Tomohiro Fujisaki, Peter Koch, 502 Suresh Krishnan, Ted Lemon, Edward Lewis, Kurtis Lindqvist, Arifumi 503 Matsumoto, Erik Nordmark, Steve Padgett, Fabien Rapin, Dave Thaler, 504 Margaret Wasserman, Dan Wing, and Dec Wojciech. 506 This document was prepared using xml2rfc template and the related 507 web-tool. 509 8. IANA Considerations 511 This memo includes a new DHCPv6 option that requires allocation of a 512 new code point. 514 9. Security Considerations 516 An attacker may try to lure traffic from multi-homed host to his 517 network by advertising DNS suffixes and prefixes attacker wishes to 518 intercept or deny service of. The node's security should not be 519 based on correct functionality of DNS server selection. Use of 520 DNSSEC is recommended to mitigates risks of forgery. 522 Additionally nodes may employ heuristics to more wisely prioritize 523 network interfaces with conflicting policies. The prioritization 524 may, for example, be based on trust level of a network interface over 525 which policy was learned from. To avoid problem of attacker 526 advertising suffix with wide scope (such as .com) or intentionally 527 narrow scope (such as mail.example.com), the node may want to first 528 match suffixes of highest priority interface and if such match is 529 found, consider information from other interface as lower priority. 531 9.1. Suffix matching example 533 In this example a host has three interfaces (in decreasing order of 534 priority): 536 1. Managed tunnel interfaces (such as VPN) considered most 537 trustworthy. Advertises suffix 'example.com' 539 2. Cellular network advertising default suffix '.' 541 3. WLAN hotspot with attacker advertising suffixes 542 'mail.example.com' and '.com' 544 When a host resolves name 'mail.example.com', it will notice the 545 highest priority interface has matching non-default suffix. As the 546 'example.com' matches to 'mail.example.com', the tunnel interface 547 will be used. Simple longest matching or shortest matching rules 548 would have resulted in the host using attackers network. 550 When a host resolves name 'example2.com', it will find highest 551 matching non-default prefix from WLAN hotspot. While it would have 552 been safer to use cellular network's DNS server, security level is 553 not decreased from what any single interface node would have. 555 The multi-homed host may also choose to always use the most 556 trustworthy interface it has for DNS queries. 558 10. References 560 10.1. Normative References 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, 566 August 2001. 568 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 569 and M. Carney, "Dynamic Host Configuration Protocol for 570 IPv6 (DHCPv6)", RFC 3315, July 2003. 572 10.2. Informative References 574 [I-D.ietf-behave-dns64] 575 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 576 "DNS64: DNS extensions for Network Address Translation 577 from IPv6 Clients to IPv4 Servers", 578 draft-ietf-behave-dns64-10 (work in progress), July 2010. 580 [I-D.ietf-mif-problem-statement] 581 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 582 Statement", draft-ietf-mif-problem-statement-07 (work in 583 progress), August 2010. 585 [I-D.troan-multihoming-without-nat66] 586 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 587 Wing, "IPv6 Multihoming without Network Address 588 Translation", draft-troan-multihoming-without-nat66-01 589 (work in progress), July 2010. 591 [I-D.wing-behave-dns64-config] 592 Wing, D., "DNS64 Resolvers and Dual-Stack Hosts", 593 draft-wing-behave-dns64-config-02 (work in progress), 594 February 2010. 596 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 597 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 598 RFC 2767, February 2000. 600 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 601 Protocol (DHCP) Domain Search Option", RFC 3397, 602 November 2002. 604 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 605 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 606 December 2003. 608 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 609 More-Specific Routes", RFC 4191, November 2005. 611 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 612 Addresses", RFC 4193, October 2005. 614 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 615 "IPv6 Router Advertisement Option for DNS Configuration", 616 RFC 5006, September 2007. 618 Appendix A. Best Current Practice for DNS server selection 620 On some split-DNS deployments explicit policies for DNS server 621 selection are not available. This section describes ways for hosts 622 to mitigate the problem by utilizing possibly existing indirect 623 information elements as hints. The approach to ask everything from 624 everyone remains always as last resort option. 626 A.1. Search list option for DNS forward lookup decisions 628 A host can learn the special DNS suffixes of attached network 629 interfaces from DHCP search list options; DHCPv4 Domain Search Option 630 number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24 631 [RFC3646]. The host behavior is very similar as is illustrated in 632 the example at section 3.3. While these DHCP options are not 633 intented to be used in DNS server selection, they may be used by the 634 host for smart DNS server prioritization purposes in order to 635 increase likelyhood of fast and successful DNS query. 637 Overloading of existing DNS search list options is not without 638 problems: resolvers would obviously use the DNS suffixes learned from 639 search lists also for name resolution purposes. This may not be a 640 problem in deployments where DNS search list options contain few DNS 641 suffixes like 'example.com, private.example.com', but can become a 642 problem if many suffixes are configured. 644 A.2. More specific routes for reverse lookup decision 646 [RFC4191] defines how more specific routes can be provisioned for 647 hosts. This information is not intented to be used in DNS server 648 selection, but nevertheless a host can use this information as a hint 649 about which interface would be best to try first for reverse lookup 650 procedures. A DNS server configured via the same interface as more 651 specific routes is likely more capable to answer reverse lookup 652 questions than DNS server of an another interface. The likelyhood of 653 success is possibly higher if DNS server address is received in the 654 same RA [RFC5006] as the more specific route information. 656 A.3. Longest matching prefix for reverse lookup decision 658 A host may utilize the longest matching prefix approach when deciding 659 which DNS server to contact for reverse lookup purposes. Namely, the 660 host may send a DNS query to a DNS server learned over an interface 661 having longest matching prefix to the address being queried. This 662 approach can help in cases where ULA [RFC4193] addresses are used and 663 when the queried address belongs to a host or server within the same 664 network (for example intranet). 666 Authors' Addresses 668 Teemu Savolainen 669 Nokia 670 Hermiankatu 12 D 671 TAMPERE, FI-33720 672 FINLAND 674 Email: teemu.savolainen@nokia.com 676 Jun-ya Kato 677 NTT 678 9-11, Midori-Cho 3-Chome Musashino-Shi 679 TOKYO, 180-8585 680 JAPAN 682 Email: kato@syce.net