idnits 2.17.1 draft-ietf-mif-dns-server-selection-12.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 (Aug 2012) is 4265 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1284 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: February 2, 2013 NTT 6 T. Lemon 7 Nominum, Inc. 8 Aug 2012 10 Improved Recursive DNS Server Selection for Multi-Interfaced Nodes 11 draft-ietf-mif-dns-server-selection-12 13 Abstract 15 A multi-interfaced node is connected to multiple networks, some of 16 which might be utilizing private DNS namespaces. A node commonly 17 receives recursive DNS server configuration information from all 18 connected networks. Some of the recursive DNS servers might have 19 information about namespaces other servers do not have. When a 20 multi-interfaced node needs to utilize DNS, the node has to choose 21 which of the recursive DNS servers to use. This document describes 22 DHCPv4 and DHCPv6 options that can be used to configure nodes with 23 information required to perform informed recursive DNS server 24 selection decisions. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 2, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 62 2. Private Namespaces and Problems for Multi-Interfaced Nodes . . 5 63 2.1. Fully Qualified Domain Names With Limited Scopes . . . . . 5 64 2.2. Network Interface Specific IP Addresses . . . . . . . . . 6 65 2.3. A Problem Not Fully Solved by the Described Solution . . . 8 66 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 8 67 3.1. CPE Deployment Scenario . . . . . . . . . . . . . . . . . 8 68 3.2. Cellular Network Scenario . . . . . . . . . . . . . . . . 9 69 3.3. VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.4. Dual-Stack Accesses . . . . . . . . . . . . . . . . . . . 10 71 4. Improved RDNSS Selection . . . . . . . . . . . . . . . . . . . 10 72 4.1. Procedure for Prioritizing RDNSSes and Handling 73 Responses . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.2. RDNSS Selection DHCPv6 Option . . . . . . . . . . . . . . 12 75 4.3. RDNSS Selection DHCPv4 Option . . . . . . . . . . . . . . 15 76 4.4. Scalability Considerations . . . . . . . . . . . . . . . . 17 77 4.5. Limitations on Use . . . . . . . . . . . . . . . . . . . . 17 78 4.6. Coexistence of Various RDNSS Configuration Tools . . . . . 17 79 4.7. Considerations on Follow-Up Queries . . . . . . . . . . . 18 80 4.8. Closing Network Interfaces and Local Caches . . . . . . . 18 81 5. Example of a Node Behavior . . . . . . . . . . . . . . . . . . 19 82 6. Considerations for Network Administrators . . . . . . . . . . 21 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 9.1. Attack vectors . . . . . . . . . . . . . . . . . . . . . . 22 87 9.2. Trust levels of Network Interfaces . . . . . . . . . . . . 22 88 9.3. Importance of Following the Algorithm . . . . . . . . . . 23 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 92 Appendix A. Possible Alternative Practices for RDNSS Selection . 24 93 A.1. Sending Queries Out on Multiple Interfaces in Parallel . . 25 94 A.2. Search List Option for DNS Forward Lookup Decisions . . . 25 95 A.3. More Specific Routes for Reverse Lookup Decisions . . . . 25 96 A.4. Longest Matching Prefix for Reverse Lookup Decisions . . . 26 97 Appendix B. DNSSEC and Multiple Answers Validating with 98 Different Trust Anchors . . . . . . . . . . . . . . . 26 99 Appendix C. Pseudo Code for RDNSS Selection . . . . . . . . . . . 26 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 102 1. Introduction 104 A multi-interfaced node faces several problems a single-homed node 105 does not encounter, as is described in [RFC6418]. This document 106 studies in detail the problems private namespaces might cause for 107 multi-interfaced nodes and provides a solution. The node might be 108 implemented as a host or as a router. 110 We start from the premise that network operators sometimes include 111 private, but still globally unique, namespaces in the answers they 112 provide from Recursive DNS Servers (RDNSS), and that those private 113 namespaces are at least as useful to nodes as the answers from the 114 public DNS. When private namespaces are visible for a node, some 115 RDNSSes have information other RDNSSes do not have. The node ought 116 to be able to query the RDNSS that can resolve the query regardless 117 of whether the answer comes from the public DNS or a private 118 namespace. 120 An example of an application that benefits from multi-interfacing is 121 a web browser that commonly accesses many different destinations, 122 each of which is available only on one network. The browser 123 therefore needs to be able to communicate over different network 124 interfaces, depending on the destination it is trying to reach. 126 Selection of the correct interface and source address is often 127 crucial in the networks using private namespaces. In such 128 deployments, the destination's IP addresses might only be reachable 129 on the network interface over which the destination's name was 130 resolved on. Henceforth, the solution described in this document is 131 assumed to be commonly used in combination with tools for delivering 132 additional routing and source and destination address selection 133 policies (e.g. [RFC4191] and [RFC3442]. 135 This document is organized in the following manner. Background 136 information about problem descriptions and example deployment 137 scenarios are included in Section 2 and Section 3. Section 4 138 contains all normative descriptions for DHCP options and node 139 behavior. Informative Section 5 illustrates behavior of a node 140 implementing functionality described in the Section 4. Section 4.4 141 contains informational considerations about scalability. Section 6 142 contains normative guidelines related to creation of private 143 namespaces. Informational Section 9 summarizes identified security 144 considerations. 146 The Appendix A describes best current practices possible with tools 147 preceding this document and that can be possibilities on networks not 148 supporting the solution described in this document. 150 1.1. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 2. Private Namespaces and Problems for Multi-Interfaced Nodes 158 This section describes two node multi-interfacing related private 159 namespace scenarios for which the procedure described in Section 4 160 provides a solution for. Additionally, Section 2.3 describes a 161 problem for which this document provides only partial solution. 163 2.1. Fully Qualified Domain Names With Limited Scopes 165 A multi-interfaced node can be connected to one or more networks that 166 are using private namespaces. As an example, the node can have 167 simultaneously open a Wireless LAN (WLAN) connection to the public 168 Internet, cellular connection to an operator network, and a virtual 169 private network (VPN) connection to an enterprise network. When an 170 application initiates a connection establishment to a Fully Qualified 171 Domain Name (FQDN), the node needs to be able to choose the right 172 RDNSS for making a successful DNS query. This is illustrated in the 173 figure 1. An FQDN for a public name can be resolved with any RDNSS, 174 but for an FQDN of enterprise's or operator's service's private name 175 the node needs to be able to correctly select the right RDNSS for the 176 DNS resolution, i.e. do also network interface selection already 177 before destination's IP address is known. 179 +---------------+ 180 | RDNSS with | | Enterprise 181 +------+ | public + |----| Intranet 182 | | | enterprise's | | 183 | |===== VPN =======| private names | | 184 | | +---------------+ +----+ 185 | MIF | | FW | 186 | node | +----+ 187 | | +---------------+ | 188 | |----- WLAN ------| RDNSS with |----| Public 189 | | | public names | | Internet 190 | | +---------------+ +----+ 191 | | | FW | 192 | | +---------------+ +----+ 193 | |---- cellular ---| RDNSS with | | 194 +------+ | public + | | Operator 195 | operator's |----| Intranet 196 | private names | | 197 +---------------+ 199 Private DNS namespaces illustrated 201 Figure 1 203 2.2. Network Interface Specific IP Addresses 205 In the second problem an FQDN is valid and resolvable via different 206 network interfaces, but to different and not necessarily globally 207 reachable IP addresses, as is illustrated in the figure 2. Node's 208 routing and source and destination address selection mechanism has to 209 ensure the destination's IP address is only used in combination with 210 source IP addresses of the network interface the name was resolved 211 on. 213 +--------------------| | 214 +------+ IPv6 | RDNSS A |------| IPv6 215 | |-- interface 1 --| saying Peer is | | 216 | | | at: 2001:0db8:0::1 | | 217 | MIF | +--------------------+ +------+ 218 | node | | Peer | 219 | | +--------------------+ +------+ 220 | | IPv6 | RDNSS B | | 221 | |-- interface 2 --| saying Peer is | | 222 +------+ | at: 2001:0db8:1::1 |------| IPv6 223 +--------------------+ | 225 Private DNS namespaces and different IP addresses for an FQDN on 226 interfaces 1 and 2. 228 Figure 2 230 Similar situation can happen with IPv6 protocol translation and AAAA 231 record synthesis [RFC6147]. A synthetic AAAA record is guaranteed to 232 be valid only on a network it was synthesized on. Figure 3 233 illustrates a scenario where the peer's IPv4 address is synthesized 234 into different IPv6 addresses by RDNSSes A and B. 236 +-------------------| +-------+ 237 +------+ IPv6 | RDNSS A |----| NAT64 | 238 | |-- interface 1 --| saying Peer is | +-------+ 239 | | | at: A_Pref96:IPv4 | | 240 | MIF | +-------------------+ | +------+ 241 | node | IPv4 +---| Peer | 242 | | +-------------------+ | +------+ 243 | | IPv6 | RDNSS B | | 244 | |-- interface 2 --| saying Peer is | +-------+ 245 +------+ | at: B_Pref96:IPv4 |----| NAT64 | 246 +-------------------+ +-------+ 248 AAAA synthesis results in network interface specific IPv6 addresses. 250 Figure 3 252 It is worth noting that network specific IP addresses can cause 253 problems also for a single-homed node, if the node retains DNS cache 254 during movement from one network to another. After the network 255 change, a node can have entries in its DNS cache that are no longer 256 correct or appropriate for its new network position. 258 2.3. A Problem Not Fully Solved by the Described Solution 260 A more complex scenario is an FQDN, which in addition to possibly 261 resolving into network interface specific IP addresses, identifies on 262 different network interfaces completely different peer entities with 263 potentially different set of service offerings. In even more complex 264 scenario, an FQDN identifies unique peer entity, but one that 265 provides different services on its different network interfaces. The 266 solution described in this document is not able to tackle these 267 higher layer issues. In fact, these problems might be solvable only 268 by manual user intervention. 270 However, when DNSSEC is used, the DNSSEC validation procedure can 271 provide assistance for selecting correct responses for some, but not 272 all, use cases. A node might prefer to use the DNS answer that 273 validates with the preferred trust anchor. 275 3. Deployment Scenarios 277 This document has been written with three particular deployment 278 scenarios in mind. First being a Consumer Premises Equipment (CPE) 279 with two or more uplink Virtual Local Area Network (VLAN) 280 connections. Second scenario involves a cellular device with two 281 uplink Internet connections: WLAN and cellular. Third scenario is 282 for VPNs, where use of local RDNSS might be preferred for latency 283 reasons, but enterprise's RDNSS has to be used to resolve private 284 names used by the enterprise. 286 In this section we are referring to the RDNSS reference values 287 defined in the Section 4. The purpose of that is to illustrate when 288 administrators might choose to utilize the different preference 289 values. 291 3.1. CPE Deployment Scenario 293 A home gateway can have two uplink connections leading to different 294 networks, as is described in 295 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. In the two 296 uplinks scenario only one uplink connection leads to the Internet, 297 while another uplink connection leads to a private network utilizing 298 private namespaces. 300 It is desirable that the CPE does not have to send DNS queries over 301 both uplink connections, but instead CPE need only send default 302 queries to the RDNSS of the interface leading to the Internet, and 303 queries related to private namespace to the RDNSS of the private 304 network. This can be configured by setting the RDNSS of the private 305 network to know about listed domains and networks, but not to be a 306 default RDNSS. 308 In this scenario the legacy hosts can be supported by deploying DNS 309 proxy on the CPE and configuring hosts in the LAN to talk to the DNS 310 proxy. However, updated hosts would be able to talk directly to the 311 correct RDNSS of each uplink ISP's RDNSS. It is deployment decision 312 whether the updated hosts would be pointed to DNS proxy or to actual 313 RDNSSes. 315 Depending on actual deployments, all VLAN connections might be 316 considered as trusted. 318 3.2. Cellular Network Scenario 320 A cellular device can have both WLAN and cellular network interfaces 321 up. In such a case it is often desirable to use WLAN by default, 322 except for those connections cellular network operator wants to go 323 over cellular interface. The use of WLAN for DNS queries likely 324 improves cellular devices power consumption and also often provides 325 lower latency. The cellular network might utilize private names and 326 hence the cellular device needs to ask for those through the cellular 327 interface. This can be configured by setting the RDNSS of the 328 cellular network to be of low preference and listing the domains and 329 networks related to cellular network's private namespaces being 330 available via the cellular network's RDNSS. This will cause a node 331 to send DNS queries by default to the RDNSS of the WLAN interface 332 (that is by default considered to be of medium preference), and 333 queries related to private namespaces to the RDNSS of the cellular 334 interface. 336 In this scenario cellular interface can be considered trusted and 337 WLAN oftentimes untrusted. 339 3.3. VPN Scenario 341 Depending on a deployment, there might be interest to use VPN only 342 for the traffic destined to a enterprise network. The enterprise 343 might be using private namespace, and hence related DNS queries need 344 to be sent over VPN to the enterprise's RDNSS, while by default RDNSS 345 of a local access network might be used for all other traffic. This 346 can be configured by setting the RDNSS of the VPN interface to be of 347 low preference and listing the domains and networks related to 348 enterprise network's private namespaces being available via the RDNSS 349 of the VPN interface. This will cause a node to send DNS queries by 350 default directly to the RDNSS of the WLAN interface (that is by 351 default considered to be of medium preference), and queries related 352 to private namespaces to the RDNSS of the VPN interface. 354 In this scenario VPN interface can be considered trusted and local 355 access network untrusted. 357 3.4. Dual-Stack Accesses 359 In all three scenarios one or more of the connected networks can 360 support both IPv4 and IPv6. In such a case both or either of DHCPv4 361 and DHCPv6 can be used to learn RDNSS selection information. 363 4. Improved RDNSS Selection 365 This section describes DHCP options and a procedure that a (stub / 366 proxy) resolver can utilize for improved RDNSS selection in the face 367 of private namespaces and multiple simultaneously active network 368 interfaces. The procedure is subject to limitations of use as 369 described in the Section 4.5. The pseudo code at section Appendix C 370 illustrates how the improved RDNSS selection works. 372 4.1. Procedure for Prioritizing RDNSSes and Handling Responses 374 A resolver SHALL build a preference list of RDNSSes it will contact 375 to depending on the query. To build the list in an optimal way, a 376 node SHALL ask with DHCP options defined in the Section 4.2 and the 377 Section 4.3 which RDNSSes of each network interface are most likely 378 to be able to successfully serve forward lookup requests matching to 379 specific domain or reverse (PTR record) lookup requests matching to 380 specific network addresses (later referred as "network"). 382 A resolver lacking more specific information can assume that all 383 information is available from any RDNSS of any network interface. 384 The RDNSSes learnt by other RDNSS address configuration methods MUST 385 be handled as default, the medium, preference default RDNSSes (see 386 also Section 4.6). 388 When a DNS query needs to be made, the resolver MUST give highest 389 preference to the RDNSSes explicitly known to serve matching domain 390 or network. The resolver MUST take into account differences in trust 391 levels (see Section 9.2) of pieces of received RDNSS selection 392 information. The resolver MUST prefer RDNSSes of trusted interfaces. 393 The RDNSSes of untrusted interfaces can be of highest preference only 394 if the trusted interfaces specifically configures low preference 395 RDNSSes. The non-exhaustive list of cases on figure 4 illustrates 396 how the different trust levels of received RDNSS selection 397 information influences the RDNSS selection logic. In the figure 4, 398 "Medium", "High", and "Low" indicates the explicitly configured 399 RDNSS's preference over other RDNSSes. The "Medium" preference is 400 also used with RDNSS for which no explicit preference configuration 401 information is available. The "Specific domains" on figure 4 402 indicates the explicitly configured "Domains and networks" private 403 namespace information that a particular RDNSS has. 405 A resolver MUST prioritize between equally trusted RDNSSes with help 406 of the DHCP option preference field. The resolver MUST NOT 407 prioritize less trusted RDNSSes higher than trusted, even in the case 408 when less trusted RDNSS would apparently have additional information. 409 In the case of all other things being equal, the resolver can make 410 the prioritization decision based on its internal preferences. 412 Information from | Information from | Resulting RDNSS 413 more trusted | less trusted | preference 414 interface A | interface B | selection 415 --------------------------+------------------------+-------------------- 416 1. Medium preference | Medium preference | Default: A, then B 417 default | default | 418 --------------------------+------------------------+-------------------- 419 2. Medium preference | High preference default| Default: A, then B 420 default | Specific domains | Specific: A, then B 421 --------------------------+------------------------+-------------------- 422 3. Low preference default | Medium preference | Default: B, then A 423 | default | 424 --------------------------+------------------------+-------------------- 425 4. Low preference default | Medium preference | Default: B, then A 426 Specific domains | default | Specific: A, then B 427 --------------------------+------------------------+-------------------- 429 Figure 4: RDNSS selection in the case of different trust levels 431 Because DNSSEC provides cryptographic assurance of the integrity of 432 DNS data, data that can be validated under DNSSEC is necessarily to 433 be preferred over data that cannot be. There are two ways that a 434 node can determine that data is valid under DNSSEC. The first is to 435 perform DNSSEC validation itself. The second is to have a secure 436 connection to an authenticated RDNSS, and to rely on that RDNSS to 437 perform DNSSEC validation (signalling that it has done so using the 438 AD bit). DNSSEC is necessary to detect forged responses, and without 439 it any DNS response could be forged or altered. Unless the DNS 440 responses have been validated with DNSSEC, a node cannot make a 441 decision to prefer data from any interface with any great assurance. 443 A node SHALL send requests to RDNSSes in the order defined by the 444 preference list until an acceptable reply is received, all replies 445 are received, or a timeout occurs. In the case of a requested name 446 matching to a specific domain or network rule accepted from any 447 interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that 448 cannot be validated using DNSSEC until all RDNSSes on the preference 449 list have been contacted or timed out. This protects against 450 possible redirection attacks. In the case of the requested name not 451 matching to any specific domain or network, first received response 452 from any RDNSS can be considered acceptable. A DNSSEC-aware node MAY 453 always contact all RDNSSes in an attempt to receive a response that 454 can be validated, but contacting all RDNSSes is not mandated for the 455 default case as in some deployments that would consume excess 456 resources. 458 In the case of validated NXDOMAIN response being received from a 459 RDNSS that can provide answers for the queried name, a node MUST NOT 460 accept non-validated replies from other RDNSSes (see Appendix B for 461 considerations related to multiple trust anchors. 463 4.2. RDNSS Selection DHCPv6 Option 465 DHCPv6 option described below can be used to inform resolvers what 466 RDNSS can be contacted when initiating forward or reverse DNS lookup 467 procedures. This option is DNS record type agnostic and applies, for 468 example, equally to both A and AAAA queries. 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | OPTION_DNS_SERVER_SELECT | option-len | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | | 476 | DNS-recursive-name-server (IPv6 address) | 477 | | 478 | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Reserved |prf| | 481 +-+-+-+-+-+-+-+-+ Domains and networks | 482 | (variable length) | 483 | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 option-code: OPTION_DNS_SERVER_SELECT (TBD) 488 option-len: Length of the option in octets 490 DNS-recursive-name-server: An IPv6 address of RDNSS 492 Reserved: Field reserved for the future. MUST be set to zero 493 and MUST be ignored on receipt. 495 prf: RDNSS preference: 496 01 High 497 00 Medium 498 11 Low 499 10 Reserved 501 Reserved preference value (10) MUST NOT be sent. 502 On receipt the Reserved value MUST be treated 503 as Medium preference (00). 505 Domains and networks: The list of domains for forward DNS 506 lookup and networks for reverse DNS lookup the RDNSS 507 has special knowledge about. Field MUST be encoded as 508 specified in Section "Representation and use of 509 domain names" of [RFC3315]. 510 Special domain of "." is used to indicate 511 capability to resolve global names and act as a 512 default RDNSS. Lack of "." 513 domain on the list indicates RDNSS only has 514 information related to listed domains and networks. 515 Networks for reverse mapping are encoded as 516 defined for ip6.arpa [RFC3596] or in-addr.arpa [RFC2317]. 518 DHCPv6 option for explicit domain configuration 520 Figure 5 522 A node SHOULD include the Option Request Option (OPTION_ORO, 523 [RFC3315]) in a DHCPv6 request with the OPTION_DNS_SERVER_SELECT 524 option code to inform the DHCPv6 server about the support for the 525 improved RDNSS selection logic. DHCPv6 server receiving this 526 information can then choose to provision RDNSS addresses only with 527 the OPTION_DNS_SERVER_SELECT. 529 The OPTION_DNS_SERVER_SELECT contains one or more domains the related 530 RDNSS has particular knowledge of. The option can occur multiple 531 times in a single DHCPv6 message, if multiple RDNSSes are to be 532 configured. This can be the case, for example, if a network link has 533 multiple RDNSSes for reliability purposes. 535 The list of networks MUST cover all the domains configured in this 536 option. The length of the included networks SHOULD be as long as 537 possible to avoid potential collision with information received on 538 other option instances or with options received from DHCP servers of 539 other network interfaces. Overlapping networks are interpreted so 540 that the resolver can use any of the RDNSSes for queries matching the 541 networks. 543 If the OPTION_DNS_SERVER_SELECT contains a RDNSS address already 544 learned from other DHCPv6 servers of the same network, and contains 545 new domains or networks, the node SHOULD append the information to 546 the information received earlier. The node MUST NOT remove 547 previously obtained information. However, the node SHOULD NOT extend 548 lifetime of earlier information either. When a conflicting RDNSS 549 address is learned from less trusted interface, the node MUST ignore 550 the option. 552 As the RDNSS options of [RFC3646], the OPTION_DNS_SERVER_SELECT 553 option MUST NOT appear in any other than the following DHCPv6 554 messages: Solicit, Advertise, Request, Renew, Rebind, Information- 555 Request, and Reply. 557 The client SHALL periodically refresh information learned with the 558 OPTION_DNS_SERVER_SELECT. The information SHALL be refreshed on 559 link-state changes, such as those caused by node mobility, and when 560 renewing lifetimes of IPv6 addresses configured with DHCPv6. 561 Additionally, the DHCPv6 Information Refresh Time Option. as 562 specified in [RFC4242], can be used to control the update frequency. 564 4.3. RDNSS Selection DHCPv4 Option 566 DHCPv4 option described below can be used to inform resolvers which 567 RDNSS can be contacted when initiating forward or reverse DNS lookup 568 procedures. This option is DNS record type agnostic and applies, for 569 example, equally to both A and AAAA queries. 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | CODE | Len | Reserved |prf| Primary .. | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | .. DNS-recursive-name-server's IPv4 address | Secondary .. | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | .. DNS-recursive-name-server's IPv4 address | | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 580 | | 581 + Domains and networks | 582 | (variable length) | 583 | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 option-code: OPTION_DNS_SERVER_SELECT (TBD) 588 option-len: Length of the option in octets 590 Reserved: Field reserved for the future. MUST be set to zero 591 and MUST be ignored on receipt. 593 prf: RDNSS preference: 594 01 High 595 00 Medium 596 11 Low 597 10 Reserved 599 Reserved preference value (10) MUST NOT be sent. 600 On receipt the Reserved value MUST be treated 601 as Medium preference (00). 603 Primary DNS-recursive-name-server's IPv4 address: Address of 604 a primary RDNSS 606 Secondary DNS-recursive-name-server's IPv4 address: Address of 607 a secondary RDNSS or 0.0.0.0 if not configured 609 Domains and networks: The list of domains for forward DNS lookup 610 and networks for reverse DNS lookup the RDNSSes 611 have special knowledge about. Field MUST be encoded as 612 specified in Section "Representation and use of 613 domain names" of [RFC3315]. 614 Special domain of "." is used to indicate 615 capability to resolve global names and act as 616 default RDNSS. Lack of "." 617 domain on the list indicates RDNSSes only have 618 information related to listed domains and networks. 619 Networks for reverse mapping are encoded as 620 defined for ip6.arpa [RFC3596] or in-addr.arpa [RFC2317]. 622 DHCPv4 option for explicit domain configuration 624 Figure 6 626 The OPTION_DNS_SERVER_SELECT contains one or more domains the primary 627 and secondary RDNSSes have particular knowledge of. If the length of 628 the domains and networks field causes option length to exceed the 629 maximum permissible for a single option (255 octets), then multiple 630 options MAY be used, as described in "Encoding Long Options in the 631 Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396]. When 632 multiple options are present, the data portions of all option 633 instances are concatenated together. 635 The list of networks MUST cover all the domains configured in this 636 option. The length of the included networks SHOULD be as long as 637 possible to avoid potential collision with information received on 638 other option instances or with options received from DHCP servers of 639 other network interfaces. Overlapping networks are interpreted so 640 that the resolver can use any of the RDNSSes for queries matching the 641 networks. 643 If the OPTION_DNS_SERVER_SELECT contains a RDNSS address already 644 learned from other DHCPv4 servers of the same network, and contains 645 new domains or networks, the node SHOULD append the information to 646 the information received earlier. The node MUST NOT remove 647 previously obtained information. However, the node SHOULD NOT extend 648 lifetime of earlier information either. When a conflicting RDNSS 649 address is learned from less trusted interface, the node MUST ignore 650 the option. 652 The client SHALL periodically refresh information learned with the 653 OPTION_DNS_SERVER_SELECT. The information SHALL be refreshed on 654 link-state changes, such as those caused by node mobility, and when 655 extending lease of IPv4 addresses configured with DHCPv4. 657 4.4. Scalability Considerations 659 The general size limitations of the DHCP messages limit the number of 660 domains and networks that can be carried inside of these RDNSS 661 selection options. The DHCP options for RDNSS selection are best 662 suited for those deployments where relatively few and carefully 663 selected domains and networks are enough. 665 4.5. Limitations on Use 667 The option OPTION_DNS_SERVER_SELECT SHOULD NOT be enabled by default. 668 The option can be used in the following environments: 670 1. The RDNSS selection option is delivered across a secure, trusted 671 channel. 673 2. The RDNSS selection option is not secured, but the client on a 674 node does DNSSEC validation. 676 3. The RDNSS selection option is not secured, the resolver does 677 DNSSEC validation, and the client communicates with the resolver 678 configured with RDNSS selection option over a secure, trusted 679 channel. 681 4. The IP address of RDNSS that is being recommended in the RDNSS 682 selection option is known and trusted by the client; that is, the 683 RDNSS selection option serves not to introduce the client to a new 684 RDNSS, but rather to inform it that RDNSS it has already been 685 configured to trust is available to it for resolving certain domains. 687 As the DHCP by itself cannot tell whether it is using secure, trusted 688 channel, or whether the client on a node is performing DNSSEC 689 validation, this option cannot be used without being explicitly 690 enabled. The functionality can be enabled for an interface via 691 administrative means, such as by provisioning tools or manual 692 configuration. Furthermore, the functionality can be automatically 693 enabled by a client on a node that knows it is performing DNSSEC 694 validation, or by a node that is configured or hard-coded to trust 695 certain interfaces (see Section 9.2). 697 4.6. Coexistence of Various RDNSS Configuration Tools 699 The DHCPv4 and DHCPv6 OPTION_DNS_SERVER_SELECT options are designed 700 to coexist between each other and with other tools used for RDNSS 701 address configuration. 703 For RDNSS selection purposes information received from all tools MUST 704 be combined together into a single list, as discussed in Section 4.1. 706 It can happen that the DHCPv4 and the DHCPv6 are providing 707 conflicting RDNSS selection information on the same or on the equally 708 trusted interfaces. In such a case, DHCPv6 MUST be preferred unless 709 DHCPv4 is utilizing additional security frameworks for protecting the 710 messages. 712 The RDNSSes learned via other tools than OPTION_DNS_SERVER_SELECT 713 MUST be handled as default RDNSSes, with medium preference, when 714 building a list of RDNSSes to talk to (see Section 4.1). 716 The non-exhaustive list of possible other sources for RDNSS address 717 configuration are: 719 (1) DHCPv6 OPTION_DNS_SERVERS defined in [RFC3646]. 721 (2) DHCPv4 Domain Name Server Option defined in [RFC2132]. 723 (3) IPv6 Router Advertisement RDNSS Option defined in [RFC6106]. 725 When the OPTION_DNS_SERVER_SELECT contains default RDNSS address and 726 other sources are providing RNDSS addresses, the resolver MUST make 727 the decision which one to prefer based on RDNSS preference field 728 value. If OPTION_DNS_SERVER_SELECT defines medium preference then 729 RDNSS from OPTION_DNS_SERVER_SELECT SHALL be selected. 731 If multiple sources are providing same RDNSS(es) IP address(es), each 732 address MUST be added to the RDNSS list only once. 734 If a node had indicated support for OPTION_DNS_SERVER_SELECT in 735 DHCPv6 request, the DHCPv6 server MAY omit sending of 736 OPTION_DNS_SERVERS. This enables offloading use case where network 737 administrator wishes to only advertise low preference default 738 RDNSSes. 740 4.7. Considerations on Follow-Up Queries 742 Any follow-up queries that are performed on the basis of an answer 743 received on an interface MUST continue to use the same interface, 744 irrespective of the RDNSS selection settings on any other interface. 745 For example, if a node receives a reply with a canonical name (CNAME) 746 or delegation name (DNAME) the follow-up queries MUST be sent to 747 RDNSS(es) of the same interface, or to same RDNSS, irrespectively of 748 the FQDN received. Otherwise referrals can fail. 750 4.8. Closing Network Interfaces and Local Caches 752 All information related to private namespaces can become obsolete 753 after the network interface over which the information was learned on 754 is closed (Section 2.2). Therefore, during network interface 755 closure, a node SHOULD flush its DNS cache at least from the entries 756 that might relate to private namespaces: the names that were learned 757 via RDNSS that had matching "Domains and Networks". 759 5. Example of a Node Behavior 761 Figure 7 illustrates node behavior when it initializes two network 762 interfaces for parallel usage and learns domain and network 763 information from DHCPv6 servers. 765 Application Node DHCPv6 server DHCPv6 server 766 on interface 1 on interface 2 767 | | | 768 | +-----------+ | 769 (1) | | open | | 770 | | interface | | 771 | +-----------+ | 772 | | | 773 (2) | |---option REQ-->| 774 | |<--option RESP--| 775 | | | 776 | +-----------+ | 777 (3) | | store | | 778 | | domains | | 779 | +-----------+ | 780 | | | 781 | +-----------+ | 782 (4) | | open | | 783 | | interface | | 784 | +-----------+ | 785 | | | | 786 (5) | |---option REQ------------------->| 787 | |<--option RESP-------------------| 788 | | | | 789 | +----------+ | | 790 (6) | | store | | | 791 | | domains | | | 792 | +----------+ | | 793 | | | | 795 Illustration of learning domains 797 Figure 7 799 Flow explanations: 801 1. A node opens its first network interface 803 2. The node obtains domain 'domain1.example.com' and IPv6 network 804 '0.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 1 from DHCPv6 805 server 807 3. The node stores the learned domains and IPv6 networks for later 808 use 810 4. The node opens its second network interface 2 812 5. The node obtains domain 'domain2.example.com' and IPv6 network 813 information, say '1.8.b.d.0.1.0.0.2.ip6.arpa' for the new 814 interface 2 from DHCPv6 server 816 6. The node stores the learned domains and networks for later use 818 Figure 8 below illustrates how a resolver uses the learned domain 819 information. Network information use for reverse lookups is not 820 illustrated, but that would go as the figure 7 example. 822 Application Node RDNSS RDNSS 823 on interface 1 on interface 2 824 | | | | 825 (1) |--Name REQ-->| | | 826 | | | | 827 | +----------------+ | | 828 (2) | | RDNSS | | | 829 | | prioritization | | | 830 | +----------------+ | | 831 | | | | 832 (3) | |------------DNS resolution------>| 833 | |<--------------------------------| 834 | | | | 835 (4) |<--Name resp-| | | 836 | | | | 838 Example on choosing interface based on domain 840 Figure 8 842 Flow explanations: 844 1. An application makes a request for resolving an FQDN, e.g. 845 'private.domain2.example.com' 847 2. A node creates list of RDNSSes to contact to and uses configured 848 RDNSS selection information and stored domain information on 849 prioritization decisions. 851 3. The node has chosen interface 2, as from DHCPv6 it was learned 852 earlier that the interface 2 has domain 'domain2.example.com'. 853 The node then resolves the requested name using interface 2's 854 RDNSS to an IPv6 address 856 4. The node replies to application with the resolved IPv6 address 858 6. Considerations for Network Administrators 860 Network administrators deploying private namespaces can assist 861 advanced nodes in their RDNSS selection process by providing 862 information described within this document. 864 Private namespaces MUST be globally unique in order to keep DNS 865 unambiguous and henceforth avoiding caching related issues and 866 destination selection problems (see Section 2.3). Exceptions to this 867 rule are domains utilized for local name resolution (such as .local). 869 Private namespaces MUST only consist of subdomains of domains for 870 which the relevant operator provides authoritative name service. 871 Thus, subdomains of example.com are permitted in the private 872 namespace served by an operator's RDNSSes only if the same operator 873 provides an SOA record for example.com. 875 It is RECOMMENDED for administrators utilizing this tool to deploy 876 DNSSEC for their zone in order to counter attacks against private 877 namespaces. 879 7. Acknowledgements 881 The author would like to thank following people for their valuable 882 feedback and improvement ideas: Mark Andrews, Jari Arkko, Marcelo 883 Bagnulo, Brian Carpenter, Stuart Cheshire, Lars Eggert, Stephan 884 Farrell, Tomohiro Fujisaki, Brian Haberman, Peter Koch, Suresh 885 Krishnan, Murray Kucherawy, Barry Leiba, Edward Lewis, Kurtis 886 Lindqvist, Arifumi Matsumoto, Erik Nordmark, Steve Padgett, Fabien 887 Rapin, Matthew Ryan, Robert Sparks, Dave Thaler, Sean Turner, 888 Margaret Wasserman, Dan Wing, and Dec Wojciech. Ted Lemon and Julien 889 Laganier receive special thanks for their contributions to security 890 considerations. 892 This document was prepared using xml2rfc template and the related 893 web-tool. 895 8. IANA Considerations 897 This memo requests IANA to assign two new option codes. 899 The first option code is requested to be assigned for the DHCPv4 900 RDNSS Selection option (TBD) from the "BOOTP Vendor Extensions and 901 DHCP Options" registry in the group "Dynamic Host Configuration 902 Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters". 904 The second option code is requested to be assigned for the DHCPv6 905 RDNSS Selection option (TBD) from the "DHCP Option Codes" registry in 906 the group "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)". 908 9. Security Considerations 910 9.1. Attack vectors 912 It is possible that attackers might try to utilize 913 OPTION_DNS_SERVER_SELECT option to redirect some or all DNS queries 914 sent by a resolver to undesired destinations. The purpose of an 915 attack might be denial-of-service, preparation for man-in-the-middle 916 attack, or something akin. 918 Attackers might try to lure specific traffic by advertising domains 919 and networks from very small to very large scope or simply by trying 920 to place attacker's RDNSS as the highest preference default RDNSS. 922 The best countermeasure for nodes is to implement validating DNSSEC 923 aware resolvers. Trusting on validation done by a RDNSS is a 924 possibility only if a node trusts the RDNSS and can use a secure 925 channel for DNS messages. 927 9.2. Trust levels of Network Interfaces 929 Trustworthiness of an interface and configuration information 930 received over the interface is implementation and/or node deployment 931 dependent, and the details of determining that trust are beyond the 932 scope of this specification. Trust might, for example, be based on 933 the nature of the interface: an authenticated and encrypted VPN, or a 934 layer 2 connection to a trusted home network or to a trusted cellular 935 network, might be considered as trusted, while an unauthenticated and 936 unencrypted connection to an unknown visited network would likely be 937 considered as untrusted. 939 In many cases, an implementation might not be able to determine trust 940 levels without explicit configuration provided by the user or the 941 node's administrator. Therefore, for example, an implementation 942 might not by default trust configuration received even over VPN 943 interfaces. In some occasions, access network technology specific 944 standards defining organizations might be able to define trust levels 945 as part of the system design work. 947 9.3. Importance of Following the Algorithm 949 The Section 4 uses normative language for describing node internal 950 behavior in order to ensure nodes would not open up new attack 951 vectors by accidental use of RDNSS selection options. During the 952 standards work consensus was that it is safer to not to enable this 953 option always by default, but only when deemed useful and safe. 955 10. References 957 10.1. Normative References 959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", BCP 14, RFC 2119, March 1997. 962 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 963 Extensions", RFC 2132, March 1997. 965 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 966 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. 968 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 969 and M. Carney, "Dynamic Host Configuration Protocol for 970 IPv6 (DHCPv6)", RFC 3315, July 2003. 972 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 973 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 974 November 2002. 976 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 977 "DNS Extensions to Support IP Version 6", RFC 3596, 978 October 2003. 980 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 981 Time Option for Dynamic Host Configuration Protocol for 982 IPv6 (DHCPv6)", RFC 4242, November 2005. 984 10.2. Informative References 986 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 987 Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D. 988 Wing, "IPv6 Multihoming without Network Address 989 Translation", 990 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 (work 991 in progress), February 2012. 993 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 994 Protocol (DHCP) Domain Search Option", RFC 3397, 995 November 2002. 997 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 998 Static Route Option for Dynamic Host Configuration 999 Protocol (DHCP) version 4", RFC 3442, December 2002. 1001 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1002 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1003 December 2003. 1005 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1006 More-Specific Routes", RFC 4191, November 2005. 1008 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1009 Addresses", RFC 4193, October 2005. 1011 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1012 "IPv6 Router Advertisement Options for DNS Configuration", 1013 RFC 6106, November 2010. 1015 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1016 Beijnum, "DNS64: DNS Extensions for Network Address 1017 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1018 April 2011. 1020 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 1021 Provisioning Domains Problem Statement", RFC 6418, 1022 November 2011. 1024 Appendix A. Possible Alternative Practices for RDNSS Selection 1026 On some private namespace deployments explicit policies for RDNSS 1027 selection are not available. This section describes ways for nodes 1028 to mitigate the problem by sending wide-spread queries and by 1029 utilizing possibly existing indirect information elements as hints. 1031 A.1. Sending Queries Out on Multiple Interfaces in Parallel 1033 A possible current practice is to send DNS queries out of multiple 1034 interfaces and pick up the best out of the received responses. A 1035 node can implement DNSSEC in order to be able to reject responses 1036 that cannot be validated. Selection between legitimate answers is 1037 implementation specific, but replies from trusted RDNSSes is 1038 preferred. 1040 A downside of this approach is increased consumption of resources. 1041 Namely power consumption if an interface, e.g. wireless, has to be 1042 brought up just for the DNS query that could have been resolved also 1043 via cheaper interface. Also load on RDNSSes is increased. However, 1044 local caching of results mitigates these problems, and a node might 1045 also learn interfaces that seem to be able to provide 'better' 1046 responses than other and prefer those - without forgetting fallback 1047 required for cases when node is connected to more than one network 1048 using private namespaces. 1050 A.2. Search List Option for DNS Forward Lookup Decisions 1052 A node can learn the special domains of attached network interfaces 1053 from IPv6 Router Advertisement DNS Search List Option [RFC6106] or 1054 DHCP search list options; DHCPv4 Domain Search Option number 119 1055 [RFC3397] and DHCPv6 Domain Search List Option number 24 [RFC3646]. 1056 The node behavior is very similar as is illustrated in the example at 1057 Section 5. While these options are not intended to be used in RDNSS 1058 selection, they can be used by the nodes as hints for smarter RDNSS 1059 prioritization purposes in order to increase likelihood of fast and 1060 successful DNS query. 1062 Overloading of existing DNS search list options is not without 1063 problems: resolvers would obviously use the domains learned from 1064 search lists also for name resolution purposes. This might not be a 1065 problem in deployments where DNS search list options contain few 1066 domains like 'example.com, private.example.com', but can become a 1067 problem if many domains are configured. 1069 A.3. More Specific Routes for Reverse Lookup Decisions 1071 [RFC4191] defines how more specific routes can be provisioned for 1072 nodes. This information is not intended to be used in RDNSS 1073 selection, but nevertheless a node can use this information as a hint 1074 about which interface would be best to try first for reverse lookup 1075 procedures. A RDNSS configured via the same interface as more 1076 specific routes is more likely capable to answer reverse lookup 1077 questions correctly than RDNSS of an another interface. The 1078 likelihood of success is possibly higher if RDNSS address is received 1079 in the same RA [RFC6106] as the more specific route information. 1081 A.4. Longest Matching Prefix for Reverse Lookup Decisions 1083 A node can utilize the longest matching prefix approach when deciding 1084 which RDNSS to contact for reverse lookup purposes. Namely, the node 1085 can send a DNS query to a RDNSS learned over an interface having 1086 longest matching prefix to the address being queried. This approach 1087 can help in cases where ULA [RFC4193] addresses are used and when the 1088 queried address belongs to a node or server within the same network 1089 (for example intranet). 1091 Appendix B. DNSSEC and Multiple Answers Validating with Different Trust 1092 Anchors 1094 When validating DNS answers with DNSSEC, a validator might order the 1095 list of trust anchors it uses to start validation chains, in terms of 1096 the node's preferences for those trust anchors. A node could use 1097 this ability in order to select among alternative DNS results from 1098 different interfaces. Suppose that a node has a trust anchor for the 1099 public DNS root, and also has a special-purpose trust anchor for 1100 example.com. An answer is received on interface i1 for 1101 www.example.com, and the validation for that succeeds by using the 1102 public trust anchor. Also, an answer is received on interface i2 for 1103 www.example.com, and the validation for that succeeds by using the 1104 trust anchor for example.com. In this case, the node has evidence 1105 for relying on i2 for answers in the example.com zone. 1107 Appendix C. Pseudo Code for RDNSS Selection 1109 This section illustrates the RDNSS selection logic in C-style pseudo 1110 code. The code is not intended to be usable as such, but only here 1111 for illustration purposes. 1113 The beginning of the whole procedure is a call to "dns_query" 1114 function with a query and list of RDNSSes given as parameters. 1116 /* This is a structure that holds all information related to a RDNSS. */ 1117 /* Here we include only the information related for this illustration.*/ 1118 struct rdnss 1119 { 1120 int prf; /* Preference of a RDNSS. */ 1121 int interface; /* Type of an interface RDNSS was learned over. */ 1122 struct d_and_n; /* Domains and networks information for this RDNSS. */ 1123 }; 1124 int has_special_knowledge( const struct rdnss *rdnss, 1125 const char *query) 1126 { 1127 /* This function matches the query to the domains and networks 1128 information of the given RDNSS. The function returns TRUE 1129 if the query matches the domains and networks, otherwise FALSE. */ 1131 /* The implementation of this matching function 1132 is left for reader, or rather writer. */ 1134 /* return TRUE if query matches rdnss->d_and_n, otherwise FALSE. */ 1135 } 1137 const struct rdnss* compare_rdnss_prf( const struct rdnss *rdnss_1, 1138 const struct rdnss *rdnss_2 ) 1139 { 1140 /* This function compares preference values of two RDNSSes and 1141 returns the more preferred RDNSS. The function prefers rdnss_1 1142 in the case of equal preference values. */ 1144 if (rdnss_1->prf == HIGH_PRF) return rdnss_1; 1145 if (rdnss_2->prf == HIGH_PRF) return rdnss_2; 1146 if (rdnss_1->prf == MED_PRF) return rdnss_1; 1147 if (rdnss_2->prf == MED_PRF) return rdnss_2; 1148 return rdnss_1; 1149 } 1151 const struct rdnss* compare_rdnss_trust( const struct rdnss *rdnss_1, 1152 const struct rdnss *rdnss_2 ) 1153 { 1154 /* This function comparest trust of the two given RDNSSes. The trust is 1155 based on the trust on the interface RDNSS was learned on. */ 1157 /* If the interface is the same, the trust is also the same, 1158 and hence function will return NULL to indicate lack of 1159 difference in trust. */ 1161 if (rdnss_1->interface == rdnss_2->interface) return NULL; 1163 /* Otherwise, implementation specific rules define which interface 1164 is consider more secure than the other. The rules shown here 1165 are only for illustrative purposes, and must be overwritten by 1166 real implementation. */ 1168 if (rdnss_1->interface == IF_VPN) return rdnss_1; 1169 if (rdnss_2->interface == IF_VPN) return rdnss_2; 1170 if (rdnss_1->interface == IF_CELLULAR) return rdnss_1; 1171 if (rdnss_2->interface == IF_CELLULAR) return rdnss_2; 1172 if (rdnss_1->interface == IF_WLAN) return rdnss_1; 1173 if (rdnss_2->interface == IF_WLAN) return rdnss_2; 1175 /* Both RDNSSes are from unknown interfaces, so return NULL as 1176 trust based comparison is impossible. */ 1177 return NULL; 1178 } 1180 int compare_rdnsses ( const struct rdnss *rdnss_1, 1181 const struct rdnss *rdnss_2, 1182 const char *query) 1183 { 1184 /* This function compares two RDNSSes and decides which one is more 1185 preferrer for resolving the query. If the rdnss_1 is more 1186 preferred, the function returns TRUE, otherwise FALSE. */ 1188 const struct rdnss *more_trusted_rdnss = NULL; 1189 const struct rdnss *less_trusted_rdnss = NULL; 1191 /* Find out if either RDNSS is more trusted. */ 1192 more_trusted_rdnss = compare_rdnss_trust( rdnss_1, rdnss_2 ); 1194 /* Check if either was more trusted. */ 1195 if (more_trusted_rdnss) 1196 { 1198 /* Check which RDNSS was less trusted. */ 1199 less_trusted_rdnss = 1200 more_trusted_rdnss == rdnss_1 ? rdnss_2 : rdnss_1; 1202 /* If the more trusted interface is not of low preference or 1203 or it has special knowledge about the query, or the more 1204 trusted is more preferred and the less trusted has no special 1205 information, prefer more trusted. Otherwise prefer less trusted. */ 1206 if (more_trusted_rdnss->prf != LOW_PRF || 1207 has_special_knowledge( more_trusted_rdnss, query ) || 1208 (compare_rdnss_prf( more_trusted_rdnss, less_trusted_rdnss) 1209 == more_trusted_rdnss && 1210 !has_special_knowledge( less_trusted_rdnss, query))) 1211 { 1212 /* If the more_trusted_rdnss was rdnss_1, return TRUE. */ 1213 return more_trusted_rdnss == rdnss_1 ? TRUE : FALSE; 1214 } 1215 else 1216 { 1217 /* If the more_trusted_rdnss was rdnss_1, return TRUE. */ 1218 return less_trusted_rdnss == rdnss_1 ? TRUE : FALSE; 1219 } 1221 } 1222 else 1223 { 1224 /* There is no trust difference between RDNSSes, therefore prefer the 1225 RDNSS that has special knowledge. If both have specific knowledge, 1226 then prefer the rdnss_1. */ 1227 if (has_special_knowledge( rdnss_1, query )) return TRUE; 1228 if (has_special_knowledge( rdnss_2, query )) return FALSE; 1230 /* Neither had special knowledge. Therefore, return TRUE if 1231 rdnss_1 is more preferred, otherwise return FALSE */ 1232 return compare_rdnss_prf( rdnss_1 , rdnss_2 ) 1233 == rdnss_1 ? TRUE : FALSE; 1234 } 1235 } 1237 void bubble_sort_rdnsses( struct rdnss rdnss_list[], 1238 const int rdnsses, 1239 const char* query) 1240 { 1241 /* This function implements a bubble sort to arrange 1242 RDNSSes in rdnss_list into preference order. */ 1244 int i; 1245 int swapped = 0; 1246 struct rdnss rdnss_swap; 1248 do 1249 { 1250 /* Clear swapped-indicator. */ 1251 swapped = FALSE; 1253 /* Go through the RDNSS list. */ 1254 for (i = 0; i < rdnsses-1; i++) 1255 { 1256 /* Check if two next items are in the right order, i.e. 1257 more preferred before less preferred. */ 1258 if (compare_rdnsses( &rdnss_list[i], 1259 &rdnss_list[i+1], query) == FALSE) 1260 { 1261 /* The order between two was not right, so swap these two RDNSSes. */ 1262 rdnss_swap = rdnss_list[i]; 1263 rdnss_list[i] = rdnss_list[i+1]; 1264 rdnss_list[i+1] = rdnss_swap; 1265 swapped = TRUE; 1266 } 1267 } 1268 } while (swapped); 1270 /* No more swaps, which means the rdnss_list is now sorted 1271 into preference order. */ 1272 } 1274 struct hostent *dns_query( struct rdnss rdnss_list[], 1275 const int rdnsses, 1276 const char* query ) 1277 { 1278 /* Perform address resolution for the query. */ 1279 int i; 1280 struct hostent response; 1282 /* Sort the RDNSSes into preference order. */ 1283 /* This is the function this pseudo code starts with. */ 1284 bubble_sort_rdnsses( &rdnss_list[0], rdnsses, query ); 1286 /* Go thourgh all RDNSSes or until valid response is found. */ 1287 for (i = 0; i < rdnsses; i++) 1288 { 1290 /* Use the highest preference RDNSS first. */ 1291 response = send_and_vaidate_dns_query( rndss_list[i], query); 1293 /* If DNSSEC validation is used. */ 1294 if (dnssec_in_use) 1295 { 1296 response = dnssec_validate(response); 1298 /* If response is validated, use that. Otherwise proceed to next 1299 RDNSS. */ 1300 if (response) return response; 1301 else continue; 1302 } 1304 /* If acceptable response has been found, return it. */ 1305 if (response) return response; 1306 } 1307 return NULL; 1308 } 1309 Authors' Addresses 1311 Teemu Savolainen 1312 Nokia 1313 Hermiankatu 12 D 1314 TAMPERE, FI-33720 1315 FINLAND 1317 Email: teemu.savolainen@nokia.com 1319 Jun-ya Kato 1320 NTT 1321 9-11, Midori-Cho 3-Chome Musashino-Shi 1322 TOKYO, 180-8585 1323 JAPAN 1325 Email: kato@syce.net 1327 Ted Lemon 1328 Nominum, Inc. 1329 2000 Seaport Boulevard 1330 Redwood City, CA 94063 1331 USA 1333 Phone: +1 650 381 6000 1334 Email: Ted.Lemon@nominum.com