idnits 2.17.1 draft-savolainen-mif-dns-server-selection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 20, 2009) is 5301 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-01 == Outdated reference: A later version (-15) exists of draft-ietf-mif-problem-statement-00 ** Obsolete normative reference: RFC 2767 (Obsoleted by RFC 6535) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Savolainen 3 Internet-Draft Nokia 4 Intended status: Informational October 20, 2009 5 Expires: April 23, 2010 7 DNS Server Selection on Multi-Homed Hosts 8 draft-savolainen-mif-dns-server-selection-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 23, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 A multi-homed host may receive DNS server configuration information 47 from multiple physical and/or virtual network interfaces. In split 48 DNS scenarios not all DNS servers are able to provide the same 49 information. When the multi-homed host needs to utilize DNS, it has 50 to select which of the servers to contact to. This document 51 describes problems of split DNS for multi-homed hosts and also a 52 method for selecting the DNS server with help of DNS suffix 53 information received dynamically for each network interface. The 54 method is useful in split DNS scenarios where private names are used 55 and where correct DNS server selection is mandatory for successful 56 DNS resolution. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2. Problem description for split DNS with multi-homed hosts . . . 4 63 2.1. Private fully qualified domain names . . . . . . . . . . . 4 64 2.2. Network interface specific IP addresses . . . . . . . . . 5 65 3. DNS server selection procedure . . . . . . . . . . . . . . . . 7 66 3.1. DNS suffixes as hints . . . . . . . . . . . . . . . . . . 8 67 3.1.1. Learning of the DNS suffixes . . . . . . . . . . . . . 8 68 3.1.2. Changes to DNS resolution procedures . . . . . . . . . 10 69 4. Considerations for network administrators . . . . . . . . . . 11 70 5. Further considerations . . . . . . . . . . . . . . . . . . . . 11 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 A multi-homed host faces several problems over single-homed host as 80 described in [I-D.ietf-mif-problem-statement]. This document studies 81 in detail problems split DNS may cause for multi-homed hosts and for 82 which optimized behaviour should be defined. The problems are mostly 83 the same in IPv4 and IPv6 domains. 85 In the split DNS scenario different DNS servers have different 86 information. Therefore DNS related information, which otherwise 87 could be consider global for a single-homed host, in a multi-homed 88 host has to be handled as local to a network interface. DNS record 89 synthesis, as described in DNS64 [I-D.ietf-behave-dns64] and Bump-In- 90 the-Stack [RFC2767], can be consider as one manifestation of split 91 DNS. 93 An obvious solution for the problem would be for network 94 administrators to cease utilizing any form of split DNS, or have 95 split DNS used only in deployments where hosts are not allowed to 96 multi-home. However, currently split DNS is deployed and multi-homed 97 hosts have to cope with that. 99 If an application is bound to utilize only a specific network 100 interface at a time, it essentially makes the host behave single- 101 interface way for that particular application and avoids the problems 102 of split DNS, if also application's DNS requests are handled strictly 103 with DNS service available in that particular network interface. If 104 all applications in a host are bound to use only single network 105 interface at a time, even if the used network interfaces were 106 different, the problems are generally avoided. Please see MIF 107 current practices for more information. The procedure described in 108 chapter 3 applies when applications are allowed to utilize multiple 109 interfaces in parallel. 111 An example of an application that would benefit from multi-homing is 112 a web browser, which commonly accesses many different destinations 113 and should be able to dynamically communicate over different network 114 interfaces. 116 The solution presented in this memo is intended to be fully backwards 117 compatible and one that can be fully ignored by hosts and networks 118 that are not experiencing the described problem scenarios or that 119 does not implement the solution. 121 In deployments where split DNS is used, selection of the correct 122 destination and source addresses for the actual IP connection is 123 crucial, as the resolved destination's IP address may be only usable 124 on the network interface over which it was resolved on. However, the 125 actual IP address selection logic is not at the scope of this 126 document. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 2. Problem description for split DNS with multi-homed hosts 136 This chapter describes two multi-homing related split DNS problem 137 scenarios for which the procedure described in chapter 3 is targeted 138 at. (DISCUSS: Even more more known problem scenarios caused by split 139 DNS for multi-homed hosts?) 141 2.1. Private fully qualified domain names 143 A multi-homed host may be connecting to one or more networks that are 144 using private fully qualified domain names. As an example, the host 145 may have simultaneously open a wireless LAN (WLAN) connection to open 146 Internet, cellular connection to an operator network, and virtual 147 private network (VPN) connection to a corporate network. When an 148 application initiates connection to an FQDN, the host needs to be 149 able to choose the right network interface for making successful DNS 150 query. This is illustrated in figure 1. If the FQDN is for a public 151 name, in figure 1 scenario it could be resolved with any DNS server 152 of any network interface, but if the FQDN would be corporation's or 153 operator's service's private name, the host would need to be able to 154 correctly select the right network interface for DNS procedures, i.e. 155 already before destination's IP address is known. 157 +---------------+ 158 | DNS server w/ | | Corporate 159 +------+ | public + |----| Intranet 160 | | | corporation's | | 161 | |===== VPN =======| private names | | 162 | | +---------------+ +----+ 163 | MIF | | FW | 164 | host | +----+ 165 | | +---------------+ | 166 | |----- WLAN ------| DNS server w/ |----| Public 167 | | | public names | | Internet 168 | | +---------------+ +----+ 169 | | | FW | 170 | | +---------------+ +----+ 171 | |---- cellular ---| DNS server w/ | | 172 +------+ | public + | | Operator 173 | operator's |----| Intranet 174 | private names | | 175 +---------------+ 177 Split DNS and private names illustrated 179 Figure 1 181 2.2. Network interface specific IP addresses 183 In the second problem an FQDN as such is valid and resolvable via 184 different network interfaces, but to different and not necessarily 185 globally reachable IP addresses, as illustrated in figure 2. This is 186 not so much a problem when a host is single-homed, but for multi- 187 homed host this results in additional challenges: the host's source 188 and destination address selection mechanism must ensure the 189 destination's IP address is only used in combination with source IP 190 addresses of the network interface the name was resolved on. 192 +----------------| | 193 +------+ IPv4 | DNS server A |------| IPv4 194 | |-- interface 1 --| saying Peer is | | 195 | | | at: 192.0.2.1 | | 196 | MIF | +----------------+ +------+ 197 | host | | Peer | 198 | | +----------------+ +------+ 199 | | IPv4 | DNS server B | | 200 | |-- interface 2 --| saying Peer is | | 201 +------+ | at: 10.0.0.1 |------| IPv4 202 +----------------+ | 204 Split DSN and different IP addresses for an FQDN on interfaces 1 and 205 2. 207 Figure 2 209 Similar situation can happen when IPv6 protocol translation is used 210 in combination with AAAA record synthesis proceduce 211 [I-D.ietf-behave-dns64]. A synthesised AAAA record is guaranteed to 212 be valid only on a network interface it was synthesized on. Figure 3 213 illustrates a scenario where the peer's IPv4 address is synthesized 214 into different IPv6 addresses by DNS servers A and B. The same 215 problem can happen in the IPv4 domain as well if A record synthesis 216 is done, for example as described in Bump-In-the-Stack [RFC2767]. 218 +------------------| +-------+ 219 +------+ IPv6 | DNS server A |----| NAT64 | 220 | |-- interface 1 --| saying Peer is | +-------+ 221 | | | at: A_Pref64::/n | | 222 | MIF | +------------------+ | +------+ 223 | host | IPv4 +---| Peer | 224 | | +------------------+ | +------+ 225 | | IPv6 | DNS server B | | 226 | |-- interface 2 --| saying Peer is | +-------+ 227 +------+ | at: B_Pref64::/n |----| NAT64 | 228 +------------------+ +-------+ 230 AAAA synthesis results in interface specific IPv6 addresses. 232 Figure 3 234 More complex scenario is an FQDN, which in addition to resolving into 235 network interface specific IP addresses, identifies on different 236 network interfaces completely different peer entities with 237 potentially different set of service offering. In even more complex 238 scenario, an FQDN identifies unique peer entity, but one that 239 provides different services on its different network interfaces. The 240 solution described in this document is not able to tackle these 241 higher layer issues. 243 A thing worth noting is that interface specific IP addresses can 244 cause problems also for a single-homed host, if the host retains its 245 DNS cache during movement from one network interface to another, and 246 thus on the new network interface host has cache entries invalid for 247 that network interface. Because of this the cached DNS information 248 should be considered network interface local instead of node global. 250 3. DNS server selection procedure 252 This chapter documents a possible procedure a host may utilize for 253 DNS server selection on multi-homing scenarios. 255 Essentially, the host shall build dynamically for each DNS query a 256 list of DNS servers it will try to contact to. The host shall cycle 257 through the list until a positive reply is received, or until all 258 selected DNS servers have been contacted or timed out. (DISCUSS: 259 What about those DNS servers that instead of negative answer always 260 return positive reply with an IP address of some default HTTP server, 261 which purpose is just to say 'page not found'?) 263 When building the list, the host shall prioritize DNS servers in a 264 optimal way for the query at hand. Host can utilize any information 265 it may have, e.g. possible user's preferences, host's general 266 preferences between network interfaces, differences on trust levels 267 of network interfaces (see Security Considerations), DNS suffix 268 information possibly available, or any other piece of information. 270 For the scenario where an FQDN maps to same service but different IP 271 addresses on different network interfaces, the source address 272 selection algorithm must be able to pick a source address from the 273 network interface that was used for DNS resolution. 275 In private FQDN deployments a negative reply from a DNS server 276 implies only that the DNS server at hand is not able to serve the 277 query. However, it is not probable that the secondary DNS servers on 278 the same network interface would be able to serve either, due likely 279 being in the same administrative domain. Therefore the next DNS 280 server host contacts should be from another network interface. 282 A host may optimize its behaviour by sending DNS requests in parallel 283 to multiple DNS servers of different network interfaces, but this 284 approach is not always practical: 286 o It may unnecessary trigger activation of a radio and thus increase 287 battery consumption. 289 o It may unnecessarily reveal private names to outsiders. 291 o It may be a privacy issue as it would reveal all names host is 292 resolving to all DNS servers. 294 3.1. DNS suffixes as hints 296 To help prioritize DNS servers in an optimal way, a host may learn 297 which DNS servers are most likely able to successfully serve requests 298 related to specific DNS suffixes. 300 By default, a host should assume all information is available via all 301 DNS servers of any network interface. 303 When a resource record is to be resolved, a host shall give higher 304 precedence to DNS servers of the network interface(s) advertising 305 corresponding DNS suffix. 307 For example, when a resolution of an FQDN has been requested and the 308 host is prioritizing DNS servers of different network interfaces, the 309 host may prioritize higher DNS server(s) of the network interface(s) 310 with matching DNS suffix than it otherwise would have. 312 3.1.1. Learning of the DNS suffixes 314 A host can learn the DNS suffixes of attached network interfaces from 315 DHCP search list options; DHCPv4 Domain Search Option number 119 316 [RFC3397] and DHCPv6 Domain Search List Option number 24 [RFC3646]. 317 This is illustrated in example figure 4 below. 319 Application Host DHCP server of DHCP server of 320 interface 1 interface 2 321 | | | 322 | +-----------+ | 323 (1) | | open | | 324 | | interface | | 325 | +-----------+ | 326 | | | 327 (2) | |---option REQ-->| 328 | |<--option RESP--| 329 | | | 330 | +-----------+ | 331 (3) | | store | | 332 | | suffixes | | 333 | +-----------+ | 334 | | | 335 | +-----------+ | 336 (4) | | open | | 337 | | interface | | 338 | +-----------+ | 339 | | | | 340 (5) | |---option REQ------------------->| 341 | |<--option RESP-------------------| 342 | | | | 343 | +----------+ | | 344 (6) | | store | | | 345 | | suffixes | | | 346 | +----------+ | | 347 | | | | 349 Learning DNS suffixes 351 Figure 4 353 Flow explanations: 355 1. A host opens its first network interface 357 2. The host obtains DNS suffix information for the new interface 1 358 from DHCP server 360 3. The host stores the learned DNS suffixes for later use 362 4. The host opens its seconds network interface 2 364 5. The host obtains DNS suffix, say 'example.com' information for 365 the new interface 2 from DHCP server 367 6. The host stores the learned DNS suffixes for later use 369 3.1.2. Changes to DNS resolution procedures 371 When a DNS resolver in a host is requested by an application to do 372 DNS resolution for an FQDN to an IP address, the host should look if 373 any of the available network interfaces is known to advertise DNS 374 suffix matching to the FQDN. If there is a matching DNS suffix, then 375 DNS server(s) of that that particular interface should be priorized 376 higher, i.e. be used for name resolution procedures. This is 377 illustrated in figure 5 below. 379 Application Host DHCP server of DHCP server of 380 interface 1 interface 2 381 | | | | 382 (1) |--Name REQ-->| | | 383 | | | | 384 | +----------------+ | | 385 (2) | | DNS server | | | 386 | | prioritization | | | 387 | +----------------+ | | 388 | | | | 389 (3) | |------------DNS resolution------>| 390 | |<--------------------------------| 391 | | | | 392 (4) |<--Name resp-| | | 393 | | | | 395 Choosing interface based on DNS suffix 397 Figure 5 399 Flow explanations: 401 1. An application makes a request for resolving an FQDN, e.g. 402 'private.example.com' 404 2. A host creates list of DNS servers to contact to and uses stored 405 DNS suffix information on priorization decisions. 407 3. The host has chosen interface 2, as from DHCP it was learned 408 earlier that the interface 2 has DNS suffix 'example.com'. The 409 host then resolves the requested name using interface 2's DNS 410 server to IP 192.0.2.1 412 4. The host replies to application with resolved IP address 413 192.0.2.1 415 4. Considerations for network administrators 417 Due to the problems caused by split DNS for multi-homed hosts, 418 network administrators should consider carefully deployment of split 419 DNS. 421 Network administrators deploying split DNS should assist hosts in DNS 422 server selection by configuring their DHCP servers with proper DNS 423 suffix information, which hosts then can use as hints. To ensure 424 hosts' source and destination IP address selection works correctly, 425 network administrators should also consider deployment of additional 426 technologies to help with that. 428 Network administrators can continue using DHCP DNS search list 429 options as before, but administrators should take into account that 430 multi-homed hosts may choose to use the DNS suffix information also 431 for DNS server selection purposes. 433 5. Further considerations 435 Overloading of existing DNS search list options is not without 436 problems, though: hosts would obviously use the DNS suffixes learned 437 from search lists also for name resolution purposes. This may not be 438 a problem in deployments where DNS search list options contain few 439 DNS suffixes like 'example.com, private.example.com', but can become 440 a problem if many suffixes are configured. 442 6. Acknowledgements 444 The author would like to thank following people for their valuable 445 comments: Jari Arkko, Marcelo Bagnulo, Lars Eggert, Kurtis Lindqvist, 446 Fabien Rapin, Dave Thaler, Margaret Wasserman, Dec Wojciech, Suresh 447 Krishnan, and Arifumi Matsumoto. 449 This document was prepared using xml2rfc template and related web- 450 tool. 452 7. IANA Considerations 454 This memo includes no request to IANA. 456 8. Security Considerations 458 An attacker may try to lure traffic from multi-homed host to his 459 network by advertising DNS suffixes attacker wishes to intercept or 460 deny service of. The host's security should not be based on correct 461 functionality of DNS server selection, but nevertheless risks of this 462 attack can be mitigated by using DNSSEC and additionally properly 463 prioritizing network interfaces with conflicting DNS suffix 464 advertisements. The prioritization could be based on trust level of 465 a network interface over which DNS suffix was learned from, like for 466 example: 468 1. Managed tunnel interfaces (such as VPN) considered most 469 trustworthy 471 2. Managed networks being on the middle 473 3. Unmanaged networks having lowest priority 475 Now, for example, if all of the three abovementioned networks would 476 advertise 'corporation.com' DNS suffix, the host would prefer the VPN 477 network interface for related DNS resolution requests. 479 9. Normative References 481 [I-D.ietf-behave-dns64] 482 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 483 "DNS64: DNS extensions for Network Address Translation 484 from IPv6 Clients to IPv4 Servers", 485 draft-ietf-behave-dns64-01 (work in progress), 486 October 2009. 488 [I-D.ietf-mif-problem-statement] 489 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 490 Statement", draft-ietf-mif-problem-statement-00 (work in 491 progress), October 2009. 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 497 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 498 RFC 2767, February 2000. 500 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 501 Protocol (DHCP) Domain Search Option", RFC 3397, 502 November 2002. 504 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 505 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 506 December 2003. 508 Author's Address 510 Teemu Savolainen 511 Nokia 512 Hermiankatu 12 D 513 TAMPERE, FI-33720 514 FINLAND 516 Email: teemu.savolainen@nokia.com