idnits 2.17.1 draft-savolainen-mif-dns-server-selection-03.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 (June 7, 2010) is 5069 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: 'RFC3315' is defined on line 567, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-09 == Outdated reference: A later version (-12) exists of draft-ietf-mif-current-practices-00 == Outdated reference: A later version (-15) exists of draft-ietf-mif-problem-statement-04 == 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: 1 error (**), 0 flaws (~~), 6 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 June 7, 2010 5 Expires: December 9, 2010 7 Improved DNS Server Selection for Multi-Homed Hosts 8 draft-savolainen-mif-dns-server-selection-03 10 Abstract 12 A multi-homed host may receive DNS server configuration information 13 from multiple physical and/or virtual network interfaces. In split 14 DNS scenarios some DNS servers have information others do not have. 15 When the multi-homed host needs to utilize DNS, it has to select 16 which of the servers to contact to. This document describes a policy 17 based method for selecting DNS server for both forward and reverse 18 DNS lookup procedures with help of DNS suffix and IPv6 prefix 19 information received via DHCPv6. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 9, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Problem description for split DNS with multi-homed hosts . . . 4 58 2.1. Private fully qualified domain names . . . . . . . . . . . 4 59 2.2. Network interface specific IP addresses . . . . . . . . . 5 60 3. DNS server selection procedure . . . . . . . . . . . . . . . . 6 61 3.1. DNS server selection policy distribution with a DHCPv6 62 option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.2. Changes to DNS resolution procedures . . . . . . . . . . . 10 64 3.3. Example of a host behavior . . . . . . . . . . . . . . . . 10 65 4. Considerations for network administrators . . . . . . . . . . 12 66 5. Further considerations . . . . . . . . . . . . . . . . . . . . 13 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Best effort DNS server selection . . . . . . . . . . 15 74 A.1. Search list option for DNS forward lookup decisions . . . 15 75 A.2. More specific routes for reverse lookup decision . . . . . 15 76 A.3. Longest matching prefix for reverse lookup decision . . . 16 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 A multi-homed host faces several problems over single-homed host as 82 is described in [I-D.ietf-mif-problem-statement]. This document 83 studies in detail the problems split DNS may cause for multi-homed 84 hosts in the IPv4 and IPv6 domains. However, as the IPv4 is being 85 phased out, this document describes a solution only for the IPv6 86 domain. 88 In the split DNS scenario some DNS servers have information other 89 servers do not have. Because of that, a multi-homed host cannot 90 assume every DNS server is able to provide any piece of information, 91 but instead it must be able to ask right server for the information 92 it needs. 94 If an application and its DNS queries are bound to utilize only a 95 single network interface, the problems of split DNS are avoided. If 96 all applications in a host are administratively bound to use a only 97 single network interface, even if the used network interfaces were 98 different for different applications, the problems are avoided. 99 Please see MIF current practices [I-D.ietf-mif-current-practices] for 100 more information. However, benefits of multi-homing are lost if 101 applications are forced to use only a single netowork interface. The 102 procedure described in chapter 3 applies when applications are 103 allowed to utilize multiple network interfaces in parallel. 105 An example of an application that benefits from multi-homing is a web 106 browser that commonly accesses many different destinations and should 107 be able to dynamically communicate over different network interfaces. 109 In deployments where split DNS is present, selection of the correct 110 destination and source addresses for the actual IP connection becomes 111 crucial, as the resolved destination's IP address may be only usable 112 on the network interface over which it was resolved on. It may be an 113 useful optimization for a host to remember which destination address 114 was resolved based on a matching DNS suffix, and for such addresses 115 follow tighter source address selection logic. However, the source 116 address selection logic is out of scope of this document. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2. Problem description for split DNS with multi-homed hosts 126 This chapter describes two multi-homing related split DNS problem 127 scenarios for which the procedure described in chapter 3 provides a 128 solution. (DISCUSS: Even more more known problem scenarios caused by 129 split DNS for multi-homed hosts?) 131 2.1. Private fully qualified domain names 133 A multi-homed host may be connecting to one or more networks that are 134 using private fully qualified domain names. As an example, the host 135 may have simultaneously open a wireless LAN (WLAN) connection to 136 public Internet, cellular connection to an operator network, and a 137 virtual private network (VPN) connection to a corporate network. 138 When an application initiates a connection establishment to an FQDN, 139 the host needs to be able to choose the right network interface for 140 making a successful DNS query. This is illustrated in the figure 1. 141 An FQDN for a public name can be resolved with any DNS server of any 142 network interface, but for an FQDN of corporation's or operator's 143 service's private name the host would need to be able to correctly 144 select the right network interface for the DNS resolution, i.e. do 145 interface selection already before destination's IP address is known. 147 +---------------+ 148 | DNS server w/ | | Corporate 149 +------+ | public + |----| Intranet 150 | | | corporation's | | 151 | |===== VPN =======| private names | | 152 | | +---------------+ +----+ 153 | MIF | | FW | 154 | host | +----+ 155 | | +---------------+ | 156 | |----- WLAN ------| DNS server w/ |----| Public 157 | | | public names | | Internet 158 | | +---------------+ +----+ 159 | | | FW | 160 | | +---------------+ +----+ 161 | |---- cellular ---| DNS server w/ | | 162 +------+ | public + | | Operator 163 | operator's |----| Intranet 164 | private names | | 165 +---------------+ 167 Split DNS and private names illustrated 169 Figure 1 171 2.2. Network interface specific IP addresses 173 In the second problem an FQDN as such is valid and resolvable via 174 different network interfaces, but to different and not necessarily 175 globally reachable IP addresses, as is illustrated in the figure 2. 176 This is a problem when a host is single-homed, but for multi-homed 177 host this results in additional challenges: the host's source and 178 destination address selection mechanism must ensure the destination's 179 IP address is only used in combination with source IP addresses of 180 the network interface the name was resolved on. 182 +--------------------| | 183 +------+ IPv6 | DNS server A |------| IPv6 184 | |-- interface 1 --| saying Peer is | | 185 | | | at: 2001:0db8:0::1 | | 186 | MIF | +--------------------+ +------+ 187 | host | | Peer | 188 | | +--------------------+ +------+ 189 | | IPv6 | DNS server B | | 190 | |-- interface 2 --| saying Peer is | | 191 +------+ | at: 2001:0db8:1::1 |------| IPv6 192 +--------------------+ | 194 Split DSN and different IP addresses for an FQDN on interfaces 1 and 195 2. 197 Figure 2 199 Similar situation can happen when IPv6 protocol translation is used 200 in combination with AAAA record synthesis proceduce 201 [I-D.ietf-behave-dns64]. A synthesised AAAA record is guaranteed to 202 be valid only on a network interface it was synthesized on. Figure 3 203 illustrates a scenario where the peer's IPv4 address is synthesized 204 into different IPv6 addresses by DNS servers A and B. The same 205 problem can happen in the IPv4 domain as well if A record synthesis 206 is done, for example as described in Bump-In-the-Stack [RFC2767]. 208 For a related problem for dual-stack hosts in a network with DNS64, 209 where IPv4 should be prioritized over synthesized IPv6, please see 210 [I-D.wing-behave-dns64-config]. 212 +-------------------| +-------+ 213 +------+ IPv6 | DNS server A |----| NAT64 | 214 | |-- interface 1 --| saying Peer is | +-------+ 215 | | | at: A_Pref96:IPv4 | | 216 | MIF | +-------------------+ | +------+ 217 | host | IPv4 +---| Peer | 218 | | +-------------------+ | +------+ 219 | | IPv6 | DNS server B | | 220 | |-- interface 2 --| saying Peer is | +-------+ 221 +------+ | at: B_Pref96:IPv4 |----| NAT64 | 222 +-------------------+ +-------+ 224 AAAA synthesis results in interface specific IPv6 addresses. 226 Figure 3 228 A more complex scenario is an FQDN, which in addition to resolving 229 into network interface specific IP addresses, identifies on different 230 network interfaces completely different peer entities with 231 potentially different set of service offering. In even more complex 232 scenario, an FQDN identifies unique peer entity, but one that 233 provides different services on its different network interfaces. The 234 solution described in this document is not able to tackle these 235 higher layer issues. 237 A thing worth noting is that interface specific IP addresses can 238 cause problems also for a single-homed host, if the host retains its 239 DNS cache during movement from one network interface to another. 240 After the interface change a host could have DNS cache entries 241 invalid for the new network interface. Because of this the cached 242 DNS information should be considered network interface local instead 243 of node global. 245 3. DNS server selection procedure 247 This chapter documents a procedure a (stub) resolver may utilize for 248 DNS server selection on split-DNS scenarios. 250 Essentially, the resolver shall dynamically build for each DNS query 251 a priority list of DNS servers it will try to contact to. The 252 resolver shall cycle through the list until a positive reply is 253 received, or until all selected DNS servers have been contacted or 254 timed out. (DISCUSS: What about those DNS servers that instead of 255 negative answer always return positive reply with an IP address of 256 some default HTTP server, which purpose is just to say 'authenticate' 257 or 'page not found'? Maybe DNSSEC would help here, i.e. roll through 258 DNS servers until one provides a response that can be validated?) 260 To prioritize DNS servers in an optimal way, the resolver may learn 261 with DHCPv6 which DNS servers are most likely able to successfully 262 serve forward lookup requests matching to specific DNS suffixes or 263 reverse (PTR record) lookup requests matching to specific IPv6 264 prefixes. 266 By default, the resolver shall assume that all information is 267 available from any DNS server of any network interface. 269 Additionally, the resolver can utilize any other information it may 270 have, e.g. possible user's preferences, host's general preferences 271 between network interfaces, differences on trust levels of network 272 interfaces (see Security Considerations), or any other piece of 273 information. 275 When a resource record is to be resolved, the resolver shall give 276 highest precedence to the DNS servers explicitly known to serve 277 matching suffixes or prefixes. A host may need to remember when a 278 query succeeds that matched to a DNS suffix in order to be able to 279 perform source address selection better. 281 For the scenario where an FQDN maps to same service but different IP 282 addresses on different network interfaces, the source address 283 selection algorithm must be able to pick a source address from the 284 network interface that was used for DNS resolution. 286 In private FQDN deployments a negative reply from a DNS server 287 implies only that the particular DNS server was not able to serve the 288 query. However, it is not probable that the secondary DNS servers on 289 the same network interface, on a same administrative domain, would be 290 able to serve either. Therefore, the next DNS server resolver 291 contacts should be from another network interface. 293 The resolver may optimize its behaviour by sending DNS requests in 294 parallel to multiple DNS servers of different network interfaces, but 295 this approach is not always practical: 297 o It may unnecessary trigger activation of a radio and thus increase 298 battery consumption. 300 o It may unnecessarily reveal private names to third parties. 302 o It may be a privacy issue as it would reveal all names host is 303 resolving to all DNS servers. 305 3.1. DNS server selection policy distribution with a DHCPv6 option 307 A DHCPv6 option is defined to assist in DNS server selection. The 308 option informs clients about which DNS server should be contacted 309 when initiating forward or reverse DNS lookup procedures. 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | OPTION_DNS_SERVER_SELECT | option-len | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | | 317 | DNS-recursive-name-server (IPv6 address) | 318 | | 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | prefix-length | | 322 +-+-+-+-+-+-+-+-+ IPv6 prefix | 323 | (16 octets) | 324 | | 325 | | 326 | | 327 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | | 329 +-+-+-+-+-+-+-+-+ | 330 | DNS suffixes | 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 option-code: OPTION_DNS_SERVER_SELECT (TBD) 336 option-len: Lenght of the option in octets 338 DNS-recursive-name-server: An IPv6 address of a DNS server 340 prefix-length: Length of the IPv6 prefix in bits 342 IPv6 prefix: The IPv6 prefix DNS server has special reverse 343 lookup information for 345 DNS suffixes: The list of DNS suffixes the DNS server has 346 special knowledge about. Field MUST be encoded as 347 specified in section "Representation and use of 348 domain names" of . 350 DHCPv6 option for explicit DNS suffix configuration 352 Figure 4 354 The OPTION_DNS_SERVER_SELECT contains one or more DNS suffixes the 355 related DNS server has particular knowledge of (e.g. private 356 suffixes). The option can occur multiple times in a single DHCPv6 357 message, if multiple DNS servers are to be configured, or if a DNS 358 server has special reverse lookup knowledge for more than one 359 aggregatable IPv6 prefix. 361 The IPv6 prefix MUST cover all the DNS suffixes configured in this 362 option. The prefix SHOULD NOT be unnecessarily short, otherwise it 363 may accidentally collide with information received on other option 364 instances or with options received from DHCPv6 servers on other 365 interfaces. Overlapping IPv6 prefixes are interpreted so that the 366 resolver can use multiple DNS servers for queries mathing the 367 prefixes. 369 As the DNS options of [RFC3646], the OPTION_DNS_SERVER_SELECT option 370 MUST NOT appear in any other than the following messages: Solicit, 371 Advertise, Request, Renew, Rebind, Information-Request, and Reply. 373 For backwards compatibility reasons the DHCPv6 message containing 374 OPTION_DNS_SERVER_SELECT also likely contains OPTION_DNS_SERVERS 375 option. In case both options contain the same IPv6 addresses, only 376 one copy of the IPv6 address of DNS server SHALL be added to the DNS 377 server list. 379 In the case of a DNS server replying negatively to a question having 380 matching suffix, it will be for implementation to decide whether to 381 consider that as a final response, or whether to ask also from other 382 DNS servers. The implementation decision may be based, for example, 383 on deployment or trust models. (DISCUSS: When DNSSEC is used, in 384 split-DNS case it is probably possible to have authoritative answers 385 for both existence and non-existence of a record, depending on the 386 interface question is sent on?) 388 3.2. Changes to DNS resolution procedures 390 When a stub DNS resolver in a host is requested by an application to 391 do forward or reverse DNS lookup, the resolver should look if any of 392 the configured DNS servers is known to have, or likely have, 393 information matching to the particular query. If there is a match, 394 then explicitly configured DNS server(s) or DNS server(s) of the 395 particular interface should be priorized higher, i.e. be used for 396 name resolution procedures. To avoid accidental use of synthesized 397 IPv6 addresses in the dual-stack case, the resolver may prioritize 398 DNS servers' IPv4 addresses over IPv6 addresses. 400 3.3. Example of a host behavior 402 Figure 5 illustrates host behavior when it initializes two network 403 interfaces for parallel usage and learns DNS suffix and prefix 404 information from DHCPv6 servers. 406 Application Host DHCPv6 server DHCPv6 server 407 on interface 1 on interface 2 408 | | | 409 | +-----------+ | 410 (1) | | open | | 411 | | interface | | 412 | +-----------+ | 413 | | | 414 (2) | |---option REQ-->| 415 | |<--option RESP--| 416 | | | 417 | +-----------+ | 418 (3) | | store | | 419 | | suffixes | | 420 | +-----------+ | 421 | | | 422 | +-----------+ | 423 (4) | | open | | 424 | | interface | | 425 | +-----------+ | 426 | | | | 427 (5) | |---option REQ------------------->| 428 | |<--option RESP-------------------| 429 | | | | 430 | +----------+ | | 431 (6) | | store | | | 432 | | suffixes | | | 433 | +----------+ | | 434 | | | | 436 Illustration of learning DNS suffixes 438 Figure 5 440 Flow explanations: 442 1. A host opens its first network interface 444 2. The host obtains DNS suffix and IPv6 prefix information for the 445 new interface 1 from DHCPv6 server 447 3. The host stores the learned DNS suffixes and IPv6 prefixes for 448 later use 450 4. The host opens its seconds network interface 2 452 5. The host obtains DNS suffix, say 'example.com', and IPv6 prefix 453 information for the new interface 2 from DHCPv6 server 455 6. The host stores the learned DNS suffixes for later use 457 Figure 6 below illustrates how a resolver uses the learned suffix 458 information. Prefix information use for reverse lookups is not 459 illustrated, but that would go as the figure 6 example. 461 Application Host DHCPv6 server DHCPv6 server 462 on interface 1 on interface 2 463 | | | | 464 (1) |--Name REQ-->| | | 465 | | | | 466 | +----------------+ | | 467 (2) | | DNS server | | | 468 | | prioritization | | | 469 | +----------------+ | | 470 | | | | 471 (3) | |------------DNS resolution------>| 472 | |<--------------------------------| 473 | | | | 474 (4) |<--Name resp-| | | 475 | | | | 477 Example on choosing interface based on DNS suffix 479 Figure 6 481 Flow explanations: 483 1. An application makes a request for resolving an FQDN, e.g. 484 'private.example.com' 486 2. A host creates list of DNS servers to contact to and uses 487 configured DNS server information and stored DNS suffix 488 information on priorization decisions. 490 3. The host has chosen interface 2, as from DHCPv6 it was learned 491 earlier that the interface 2 has DNS suffix 'example.com'. The 492 host then resolves the requested name using interface 2's DNS 493 server to an IPv6 address 495 4. The host replies to application with the resolved IPv6 address 497 4. Considerations for network administrators 499 Due to the problems caused by split DNS for multi-homed hosts, 500 network administrators should consider carefully deployment of split 501 DNS. 503 Network administrators deploying split DNS should assist advanced 504 hosts in the DNS server selection by configuring their DHCP servers 505 with proper DNS suffix and prefix information. To ensure hosts' 506 source and destination IP address selection works correctly, network 507 administrators should also consider deployment of additional 508 technologies to help with that. 510 5. Further considerations 512 Overloading of existing DNS search list options as described in 513 Appendix A is not without problems: resolvers would obviously use the 514 DNS suffixes learned from search lists also for name resolution 515 purposes. This may not be a problem in deployments where DNS search 516 list options contain few DNS suffixes like 'example.com, 517 private.example.com', but can become a problem if many suffixes are 518 configured. To avoid overloading of existing options, this document 519 proposes standardization of a completely new DHCPv6 option. 521 6. Acknowledgements 523 The author would like to thank following people for their valuable 524 comments: Jari Arkko, Marcelo Bagnulo, Lars Eggert, Kurtis Lindqvist, 525 Fabien Rapin, Dave Thaler, Margaret Wasserman, Dec Wojciech, Suresh 526 Krishnan, Arifumi Matsumoto, Tomohiro Fujisaki, Peter Koch and Dan 527 Wing. 529 This document was prepared using xml2rfc template and related web- 530 tool. 532 7. IANA Considerations 534 This memo includes a new DHCPv6 option that requires allocation of a 535 new code point. 537 8. Security Considerations 539 An attacker may try to lure traffic from multi-homed host to his 540 network by advertising DNS suffixes and prefixes attacker wishes to 541 intercept or deny service of. The host's security should not be 542 based on correct functionality of DNS server selection, but 543 nevertheless risks of this attack can be mitigated by using DNSSEC 544 and additionally properly prioritizing network interfaces with 545 conflicting policies. The prioritization could be based on trust 546 level of a network interface over which policy was learned from, like 547 for example: 549 1. Managed tunnel interfaces (such as VPN) considered most 550 trustworthy 552 2. Managed networks being on the middle 554 3. Unmanaged networks having lowest priority 556 Now, for example, if all of the three abovementioned networks would 557 advertise 'corporation.com' DNS suffix, the host would prefer the VPN 558 network interface for related DNS resolution requests. 560 9. References 562 9.1. Normative References 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, March 1997. 567 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 568 and M. Carney, "Dynamic Host Configuration Protocol for 569 IPv6 (DHCPv6)", RFC 3315, July 2003. 571 9.2. Informative References 573 [I-D.ietf-behave-dns64] 574 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 575 "DNS64: DNS extensions for Network Address Translation 576 from IPv6 Clients to IPv4 Servers", 577 draft-ietf-behave-dns64-09 (work in progress), March 2010. 579 [I-D.ietf-mif-current-practices] 580 Wasserman, M., "Current Practices for Multiple Interface 581 Hosts", draft-ietf-mif-current-practices-00 (work in 582 progress), October 2009. 584 [I-D.ietf-mif-problem-statement] 585 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 586 Statement", draft-ietf-mif-problem-statement-04 (work in 587 progress), May 2010. 589 [I-D.wing-behave-dns64-config] 590 Wing, D., "DNS64 Resolvers and Dual-Stack Hosts", 591 draft-wing-behave-dns64-config-02 (work in progress), 592 February 2010. 594 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 595 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 596 RFC 2767, February 2000. 598 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 599 Protocol (DHCP) Domain Search Option", RFC 3397, 600 November 2002. 602 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 603 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 604 December 2003. 606 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 607 More-Specific Routes", RFC 4191, November 2005. 609 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 610 Addresses", RFC 4193, October 2005. 612 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 613 "IPv6 Router Advertisement Option for DNS Configuration", 614 RFC 5006, September 2007. 616 Appendix A. Best effort DNS server selection 618 On some split-DNS deployments explicit policies for DNS server 619 selection may not be available. This section proposes ways for hosts 620 to mitigate the problem by using possibly existing indirect 621 information elements for the same purposes as the explicit DHCPv6 622 option. 624 A.1. Search list option for DNS forward lookup decisions 626 A host can learn the special DNS suffixes of attached network 627 interfaces from DHCP search list options; DHCPv4 Domain Search Option 628 number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24 629 [RFC3646]. The host behavior is very similar as is illustrated in 630 the example at section 3.3. While these DHCP options are not 631 intented to be used in DNS server selection, they may be used by the 632 host for smart DNS server prioritization purposes in order to 633 increase likelyhood of fast and successful DNS query. 635 A.2. More specific routes for reverse lookup decision 637 [RFC4191] defines how more specific routes can be provisioned for 638 hosts. This information is not intented to be used in DNS server 639 selection, but nevertheless a host can use this information as a hint 640 about which interface would be best to try first for reverse lookup 641 procedures. A DNS server configured via the same interface as more 642 specific routes is likely more capable to answer reverse lookup 643 questions than DNS server of an another interface. The likelyhood of 644 success is possibly higher if DNS server address is received in the 645 same RA [RFC5006] as the more specific route information. 647 A.3. Longest matching prefix for reverse lookup decision 649 A host may utilize the longest matching prefix approach when deciding 650 which DNS server to contact for reverse lookup purposes. Namely, the 651 host may send a DNS query to a DNS server learned over an interface 652 having longest matching prefix to the address being queried. This 653 approach can help in cases where ULA [RFC4193] addresses are used and 654 when the queried address belongs to a host or server within the same 655 network (for example intranet). 657 Author's Address 659 Teemu Savolainen 660 Nokia 661 Hermiankatu 12 D 662 TAMPERE, FI-33720 663 FINLAND 665 Email: teemu.savolainen@nokia.com