RFC 6731
Improved Recursive DNS Server Selection for Multi-Interfaced Nodes
Improved Recursive DNS Server Selection for Multi-Interfaced Nodes 🎀
okay bestie, so this is RFC 6731 💖 It's a Standards Track doc from December 2012 (ISSN 2070-1721), published by the IETF. The authors are T. Savolainen from Nokia, J. Kato from NTT, and T. Lemon from Nominum, Inc. 🫶 The title block doesn't list anything it obsoletes or updates, so it's not replacing or patching any older RFC. 🧚
Abstract 🦋
okay so picture a multi-interfaced node, a device connected to multiple networks at once 📱✨ some of those networks might be running private DNS namespaces. the node usually gets recursive DNS server config info from every network it's on 🌈 and here's the tea: some of those recursive DNS servers know stuff the others just don't 💀 so when the node needs DNS, it has to pick which server to ask 👑 this doc describes DHCPv4 and DHCPv6 options that give nodes the info they need to make smart, informed picks for recursive DNS server selection 💅
Status of This Memo 🌸
this is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶 if you want more on Internet Standards, check out Section 2 of RFC 5741 📚
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6731 🔗
Copyright Notice 🎀
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this doc was published 📜 please actually read them, because they spell out your rights and restrictions for this document 👀 any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🫶
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Private Namespaces and Problems for Multi-Interfaced Nodes . . 4
2.1. Fully Qualified Domain Names with Limited Scopes . . . . . 4
2.2. Network-Interface-Specific IP Addresses . . . . . . . . . 5
2.3. A Problem Not Fully Solved by the Described Solution . . . 6
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7
3.1. CPE Deployment Scenario . . . . . . . . . . . . . . . . . 7
3.2. Cellular Network Scenario . . . . . . . . . . . . . . . . 7
3.3. VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Dual-Stack Accesses . . . . . . . . . . . . . . . . . . . 8
4. Improved RDNSS Selection . . . . . . . . . . . . . . . . . . . 8
4.1. Procedure for Prioritizing RDNSSes and Handling
Responses . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. RDNSS Selection DHCPv6 Option . . . . . . . . . . . . . . 11
4.3. RDNSS Selection DHCPv4 Option . . . . . . . . . . . . . . 13
4.4. Scalability Considerations . . . . . . . . . . . . . . . . 15
4.5. Limitations on Use . . . . . . . . . . . . . . . . . . . . 15
4.6. Coexistence of Various RDNSS Configuration Tools . . . . . 16
4.7. Considerations on Follow-Up Queries . . . . . . . . . . . 17
4.8. Closing Network Interfaces and Local Caches . . . . . . . 17
5. Example of a Node Behavior . . . . . . . . . . . . . . . . . . 17
6. Considerations for Network Administrators . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Trust Levels of Network Interfaces . . . . . . . . . . . . 21
8.3. Importance of Following the Algorithm . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Possible Alternative Practices for RDNSS Selection . 23
A.1. Sending Queries Out on Multiple Interfaces in Parallel . . 23
A.2. Search List Option for DNS Forward Lookup Decisions . . . 23
A.3. More-Specific Routes for Reverse Lookup Decisions . . . . 24
A.4. Longest Matching Prefix for Reverse Lookup Decisions . . . 24
Appendix B. DNSSEC and Multiple Answers Validating with
Different Trust Anchors . . . . . . . . . . . . . . . 24
Appendix C. Pseudocode for RDNSS Selection . . . . . . . . . . . 24
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 291. Introduction ✨
okay so a multi-interfaced node (MIF node) runs into a bunch of problems that a single-homed node never has to deal with 🙈 those are covered in detail in [RFC6418] 💖 this doc digs into how private namespaces can cause trouble for MIF nodes, and then it fixes that 🔥 the node can be a host or a router, either one 🌸
here's the premise: network operators sometimes put private namespaces in the answers their Recursive DNS Servers (RDNSSes) send back 🦋 those namespaces are still globally unique, though 💅 and they're at least as useful to nodes as the answers from the public DNS ✨ when a node can see those private namespaces, some RDNSSes have info that other RDNSSes don't 👀 the node should be able to ask whichever RDNSS can actually resolve the query, whether the answer comes from the public DNS or from a private namespace 🫶
an example of an app that loves multi-interfacing is a web browser 🌐 it constantly hits lots of different destinations, and each one is only reachable on one network 💀 so the browser needs to talk over different network interfaces, depending on where it's trying to go 🧚
the important bit: picking the right interface and source address is super crucial on networks that use private namespaces 😭 in those setups, a destination's IP addresses might only be reachable over the interface the destination's name got resolved on 🙈
so from here on, this doc assumes the solution is being used together with tools that deliver extra routing and source and destination address selection policies (e.g., [RFC4191] and [RFC3442]. 🎀
here's the layout: background on the problems and example deployment scenarios are in Sections 2 and 3 🌈 Section 4 has all the normative stuff for DHCP options and node behavior 💅 Informative Section 5 shows how a node acting out Section 4 behaves 👑 Section 6 has the normative guidelines for creating private namespaces ✨ IANA considerations are in Section 7, and Informational Section 8 sums up the security considerations 🦋
Appendix A covers best current practices you can do with older tools, the ones that work on networks that don't support this solution 💖 Appendix B talks about a case where multiple answers can be validated but they use different trust anchors 🫶 Appendix C shows the Section 4 functionality in pseudocode 🧚
1.1. Requirements Language 💅
okay the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 📜
2. Private Namespaces and Problems for Multi-Interfaced Nodes 🫶
this section walks through two private namespace scenarios tied to multi-interfacing, and the procedure in Section 4 solves both of them 🔥 Section 2.3 also covers a problem this doc only partly solves 👀
2.1. Fully Qualified Domain Names with Limited Scopes 🌸
a multi-interfaced node can be connected to one or more networks that use private namespaces 💜 for example, the node can have a Wireless LAN (WLAN) connection to the public Internet, a cellular connection to an operator network, and a Virtual Private Network (VPN) connection to an enterprise network, all at the same time 📱✨ when an app starts a connection to a Fully Qualified Domain Name (FQDN), the node has to pick the right RDNSS to make a DNS query that actually works 🎀 Figure 1 shows this 🦋 an FQDN for a public name can go to any RDNSS 💅 but for an FQDN that's a private name in an enterprise's or operator's service, the node has to correctly pick the right RDNSS for DNS resolution 😭 which means the node also has to pick the network interface before it even knows the destination's IP address 🧚
+---------------+
| RDNSS with | | Enterprise
+------+ | public + |----| Intranet
| | | enterprise's | |
| |===== VPN =======| private names | |
| | +---------------+ +----+
| MIF | | FW |
| node | +----+
| | +---------------+ |
| |----- WLAN ------| RDNSS with |----| Public
| | | public names | | Internet
| | +---------------+ +----+
| | | FW |
| | +---------------+ +----+
| |---- cellular ---| RDNSS with | |
+------+ | public + | | Operator
| operator's |----| Intranet
| private names | |
+---------------+
Figure 1: Private DNS Namespaces Illustrated2.2. Network-Interface-Specific IP Addresses 🦋
Okay so the second problem is a bit sneaky 👀. An FQDN can be valid and resolvable on different network interfaces, but each interface can hand back a different IP address for it, and those addresses aren't necessarily reachable from everywhere on the Internet 🌐. The node's routing, source, and destination address selection mechanism has to make sure that a destination's IP address is only used together with the source IP addresses from the interface where the name was resolved. Bestie, that's literally the whole vibe 💅.
Here's how it looks (Figure 2 is the iconic diagram 🎀):
+--------------------| |
+------+ IPv6 | RDNSS A |------| IPv6
| |-- interface 1 --| saying Peer is | |
| | | at: 2001:0db8:0::1 | |
| MIF | +--------------------+ +------+
| node | | Peer |
| | +--------------------+ +------+
| | IPv6 | RDNSS B | |
| |-- interface 2 --| saying Peer is | |
+------+ | at: 2001:0db8:1::1 |------| IPv6
+--------------------+ |
Figure 2: Private DNS Namespaces and Different IP Addresses for an
FQDN on Interfaces 1 and 2A similar thing can happen with IPv6 protocol translation and AAAA record synthesis [RFC6147] ✨. A synthetic AAAA record is only guaranteed to be valid on the network where it was synthesized, so the same peer can end up with different synthetic addresses depending on which RDNSS you ask. Figure 3 shows the peer's IPv4 address getting synthesized into different IPv6 addresses by RDNSS A and RDNSS B 🧚.
+-------------------| +-------+
+------+ IPv6 | RDNSS A |----| NAT64 |
| |-- interface 1 --| saying Peer is | +-------+
| | | at: A_Pref96:IPv4 | |
| MIF | +-------------------+ | +------+
| node | IPv4 +---| Peer |
| | +-------------------+ | +------+
| | IPv6 | RDNSS B | |
| |-- interface 2 --| saying Peer is | +-------+
+------+ | at: B_Pref96:IPv4 |----| NAT64 |
+-------------------+ +-------+
Figure 3: AAAA Synthesis Results in
Network-Interface-Specific IPv6 AddressesIt's also worth knowing that network-specific IP addresses can cause problems for a single-homed node too 🙈, if the node keeps its DNS cache while it moves from one network to another. After the network changes, the node can have DNS cache entries that are no longer correct or appropriate for its new network position. Literally a cache glow-up gone wrong 💀.
2.3. A Problem Not Fully Solved by the Described Solution 😤
This one is the more complicated scenario. Imagine an FQDN that, on top of possibly resolving to network-interface-specific IP addresses, identifies completely different peer entities on different network interfaces, each with potentially different sets of services 🫠. It gets even messier when an FQDN identifies one unique peer entity that just offers different services on each of its network interfaces. The solution in this document is not able to tackle these higher-layer issues 🚫. Honestly, these problems might only be solvable with manual user intervention.
However, when DNS Security (DNSSEC) is used, the DNSSEC validation procedure can help select correct responses for some, but not all, use cases 🔐. For example, a node might prefer to use the DNS answer that validates with its preferred trust anchor. Helpful, but not a magic fix ✨.
3. Deployment Scenarios 🏡
This document was written with three particular deployment scenarios in mind 📍. The first is a Customer Premises Equipment (CPE) with two or more uplink Virtual Local Area Network (VLAN) connections. The second is a cellular device with two uplink Internet connections: WLAN and cellular 📱. The third is for VPNs, where a local RDNSS might be preferred for latency reasons, but the enterprise's RDNSS has to be used to resolve private names that belong to the enterprise 🏢.
In this section, we're pointing back to the RDNSS preference values defined in Section 4. The whole point is to show when administrators might pick the different preference values 🎯.
3.1. CPE Deployment Scenario 🏠
A home gateway can have two uplink connections leading to different networks, as described in [WITHOUT-IPV6NAT] 🌸. In the two-uplink scenario, only one uplink leads to the Internet, and the other leads to a private network that uses private namespaces.
It's desirable for the CPE to not have to send DNS queries over both uplink connections 🙅♀️. Instead, the CPE only needs to send default queries to the RDNSS of the interface leading to the Internet, and queries related to the private namespace to the RDNSS of the private network. This can be configured by setting the RDNSS of the private network to know about the listed domains and networks, but not to be a default RDNSS 💖.
In this scenario, legacy hosts can be supported by deploying a DNS proxy on the CPE and configuring hosts in the LAN to talk to that DNS proxy. Updated hosts, though, would be able to talk directly to the correct RDNSS of each uplink ISP's RDNSS 💅. Whether the updated hosts get pointed to a DNS proxy or to the actual RDNSSes is a deployment decision 🫶.
Depending on the actual deployment, all VLAN connections might be considered trusted 🔒.
3.2. Cellular Network Scenario 📶
A cellular device can have both WLAN and cellular network interfaces up at the same time 📲. In that case, it's often desirable to use WLAN by default, except for the connections the cellular network operator wants to go over the cellular interface. Using WLAN for DNS queries likely improves the power consumption of cellular devices and often gives lower latency ⚡. The cellular network might use private names, so the cellular device needs to ask for those through the cellular interface 🥺.
This can be configured by setting the RDNSS of the cellular network to low preference, and listing the domains and networks related to the cellular network's private namespaces as being available via the cellular network's RDNSS 🍓. The result is that a node sends DNS queries by default to the RDNSS of the WLAN interface (which, by default, is considered to be of medium preference), and queries related to private namespaces go to the RDNSS of the cellular interface 🦋.
In this scenario, the cellular interface can be considered trusted, and WLAN is often untrusted ☕.
3.3. VPN Scenario 🔐
Depending on the deployment, there might be interest in using a VPN only for traffic destined for an enterprise network 🏢. The enterprise might use private namespaces, so related DNS queries need to be sent over the VPN to the enterprise's RDNSS. By default, the RDNSS of a local access network might be used for all other traffic 🌈.
This can be configured by setting the RDNSS of the VPN interface to low preference, and listing the domains and networks related to an enterprise network's private namespaces as being available via the RDNSS of the VPN interface 💜. The result is that a node sends DNS queries by default directly to the RDNSS of the WLAN interface (which, by default, is considered to be of medium preference), and queries related to private namespaces go to the RDNSS of the VPN interface ✨.
In this scenario, the VPN interface can be considered trusted, and the local access network untrusted 🛡️.
3.4. Dual-Stack Accesses 🌗
In all three scenarios, one or more of the connected networks can support both IPv4 and IPv6 🙌. In that case, DHCPv4, DHCPv6, or both can be used to learn RDNSS selection information 💫.
4. Improved RDNSS Selection 👑
This section describes DHCP options and a procedure that a (stub/proxy) resolver can use for improved RDNSS selection when dealing with private namespaces and multiple simultaneously active network interfaces 🧚♀️. The procedure is subject to the limitations of use described in Section 4.5 🚧. The pseudocode in Appendix C shows how the improved RDNSS selection works 🎀.
4.1. Procedure for Prioritizing RDNSSes and Handling Responses ✨
okay so a resolver SHALL build a preference list of RDNSSes it's gonna contact, and it depends on the query 🎀 to make that list in the best way, a node SHALL ask for RDNSS selection info using the DHCP options in Sections 4.2 and 4.3 before any DNS queries happen 💅 once it has that info, the node can figure out whether any of the RDNSSes know stuff about specific domains (for forward lookups) or network addresses (for reverse lookups, which we'll just call "network" from here on) 🦋
a resolver that doesn't have more specific info can just assume that everything is available from any RDNSS on any network interface 🌸 RDNSSes learned through other address config methods can count as default RDNSSes, but for preference purposes they MUST be handled as medium preference RDNSSes (see also Section 4.6) 💜
when a DNS query needs to go out, the resolver MUST give the highest preference to RDNSSes that are explicitly known to serve a matching domain or network 🔥 it also MUST take into account the different trust levels (see Section 8.2) of the RDNSS selection info it received 😭 the resolver MUST prefer RDNSSes from trusted interfaces 🫶 an RDNSS on an untrusted interface can only be top priority if a trusted interface specifically configures its RDNSSes to be low preference 👑 Figure 4 is a not-exhaustive list of cases showing how these trust levels change the RDNSS selection logic 🧚 in that figure, "Medium", "High", and "Low" mean how strongly an RDNSS was explicitly configured compared to other RDNSSes 🌈 "Medium" is also used for RDNSSes with no explicit preference info at all 🍓 and "Specific domains" means the explicitly configured "Domains and networks" private namespace info that a particular RDNSS has ✨
ngl this next one is important: the resolver MUST sort equally trusted RDNSSes using the preference field in the DHCP option 💖 and the resolver MUST NOT rank a less trusted RDNSS higher than a trusted one, even if that less trusted RDNSS seems to have extra info 💀 if everything else is equal, the resolver can decide based on its own internal preferences 🙈
Information from | Information from | Resulting RDNSS
more trusted | less trusted | preference
interface A | interface B | selection
--------------------------+------------------------+-----------------
1. Medium preference | Medium preference | Default:
default | default | A, then B
--------------------------+------------------------+-----------------
2. Medium preference | High preference default| Default:
default | | A, then B
| Specific domains | Specific:
| | A, then B
--------------------------+------------------------+-----------------
3. Low preference default | Medium preference | Default:
| default | B, then A
--------------------------+------------------------+-----------------
4. Low preference default | Medium preference | Default:
| default | B, then A
Specific domains | | Specific:
| | A, then B
--------------------------+------------------------+-----------------
Figure 4: RDNSS Selection in the Case of Different Trust Levelswhy does this matter so much? 🥺 DNSSEC gives cryptographic proof that DNS data hasn't been messed with, so you HAVE to prefer data that can be validated under DNSSEC over data that can't 💅 there are two ways a node can tell that data is valid under DNSSEC 🌷 option one is doing the DNSSEC validation itself 🎀 option two is having a secure connection to an authenticated RDNSS and trusting that RDNSS to do the validation for it (it signals that it did by setting the AD bit) 🦋 DNSSEC is what catches forged responses, and without it any DNS response could be forged or altered 😱 so unless the DNS responses were validated with DNSSEC, a node can't really trust data from any interface with any real confidence 🫠
a node SHALL send requests to RDNSSes in the order of the preference list until it gets an acceptable reply, until all replies have come in, or until a timeout happens 🚀 if a requested name matches a specific domain or network rule that was accepted from any interface, a DNSSEC-aware resolver MUST NOT go with a reply that can't be validated using DNSSEC until every RDNSS on the preference list has been contacted or timed out 🛡️ that's what protects against possible redirection attacks 🙅♀️ if the requested name doesn't match any specific domain or network, the first response from any RDNSS can count as acceptable 🌼 a DNSSEC-aware node MAY always contact every RDNSS to try to get a response that can be validated, but contacting all of them isn't mandatory for the default case, since that would waste resources in some deployments 🍃
and lastly, if an RDNSS that can answer for the queried name sends a validated NXDOMAIN response, a node MUST NOT accept non-validated replies from other RDNSSes (see Appendix B for considerations about multiple trust anchors) 🚫 no cap, that one's serious 😤
4.2. RDNSS Selection DHCPv6 Option 🌷
this DHCPv6 option tells resolvers which RDNSS they can contact when they start forward or reverse DNS lookups 💖 it's DNS record type agnostic, so it works the same for things like A and AAAA queries 🎀
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RDNSS_SELECTION | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS-recursive-name-server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |prf| |
+-+-+-+-+-+-+-+-+ Domains and networks |
| (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DHCPv6 Option for Explicit Domain Configurationhere's the breakdown of each field 🧁
- option-code:
OPTION_RDNSS_SELECTION(74) 🌸 - option-len: the length of the option in octets 📏
- DNS-recursive-name-server: an IPv6 address of an RDNSS 🌐
- Reserved: this field is reserved for the future 🔮 it MUST be set to zero and MUST be ignored on receipt 🙈
- prf: the RDNSS preference 💅 the values are:
01 High
00 Medium
11 Low
10 Reservedthe Reserved preference value (10) MUST NOT be sent 🚫 and on receipt, the Reserved value MUST be treated as Medium preference (00) 💜
- Domains and networks: the list of domains for forward DNS lookup and networks for reverse DNS lookup that the RDNSS has special knowledge about 🦋 this field MUST be encoded as specified in Section 8 of [RFC3315] 🎀 a special domain of "." means the RDNSS can resolve global names and acts as a default RDNSS 👑 if there's no "." domain on the list, it means the RDNSS only has info about the listed domains and networks 🧚 networks for reverse mapping are encoded as defined for IP6.ARPA [RFC3596] or IN-ADDR.ARPA [RFC2317] 🌈
a node SHOULD include the Option Request Option (OPTION_ORO [RFC3315]) in a DHCPv6 request with the OPTION_RDNSS_SELECTION option code 🍓 that tells the DHCPv6 server the node supports the improved RDNSS selection logic ✨ a server that gets that info can then choose to only provision RDNSS addresses with OPTION_RDNSS_SELECTION 💖
OPTION_RDNSS_SELECTION contains one or more domains that the related RDNSS has particular knowledge about 🫶 the option can show up multiple times in a single DHCPv6 message if multiple RDNSSes are being configured 🌟 that can happen, for example, when a network link has several RDNSSes for reliability 🛟
the list of networks MUST cover all the domains configured in this option 💅 the networks should be as long as possible to avoid possible collisions with info received from other option instances or from DHCP servers on other network interfaces 🎯 overlapping networks are interpreted so the resolver can use any of the RDNSSes for queries that match those networks 🦋
if OPTION_RDNSS_SELECTION has an RDNSS address that was already learned from other DHCPv6 servers on the same network, and it also has new domains or networks, the node SHOULD append that info to what it got earlier 🌷 the node MUST NOT remove info it already got 😭 but the node SHOULD NOT extend the lifetime of earlier info either 🙅♀️ and when a conflicting RDNSS address shows up from a less trusted interface, the node MUST ignore the option 🚫
like the RDNSS options from [RFC3646], OPTION_RDNSS_SELECTION MUST NOT appear in any DHCPv6 messages other than these: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply 🍓
the client SHALL periodically refresh the info it learned from OPTION_RDNSS_SELECTION 🔄 it SHALL also refresh on link-state changes (like the ones caused by node mobility) and whenever it renews the lifetimes of IPv6 addresses configured with DHCPv6 🌈 and if you want to control how often that update happens, the DHCPv6 Information Refresh Time Option from [RFC4242] can be used 🧚
4.3. RDNSS Selection DHCPv4 Option ✨
okay bestie, this is the DHCPv4 version of the RDNSS Selection option 🦋 It tells resolvers which RDNSS they can reach out to when they kick off forward or reverse DNS lookups. The best part is that it's DNS record type agnostic, so it works the same for both A and AAAA queries 💅
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CODE | Len | Reserved |prf| Primary .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. DNS-recursive-name-server's IPv4 address | Secondary .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. DNS-recursive-name-server's IPv4 address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+ Domains and networks |
| (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: DHCPv4 Option for Explicit Domain ConfigurationHere's the breakdown of the fields 🎀
- option-code:
RDNSS Selection (146) - option-len: Length of the option in octets
- Reserved: Field reserved for the future. It MUST be set to zero and MUST be ignored on receipt.
- prf: RDNSS preference, encoded as:
01 High
00 Medium
11 Low
10 ReservedThe Reserved preference value (10) MUST NOT be sent. On receipt, the Reserved value MUST be treated as Medium preference (00). Not sending it, and treating it as Medium if it shows up anyway, is the vibe 🌸
- Primary DNS-recursive-name-server's IPv4 address: Address of a primary RDNSS 🧚
- Secondary DNS-recursive-name-server's IPv4 address: Address of a secondary RDNSS, or
0.0.0.0if not configured - Domains and networks: This is the list of domains for forward DNS lookup, plus networks for reverse DNS lookup, that the RDNSSes have special knowledge about. This field MUST be encoded as specified in Section 8 of [RFC3315]. A special domain of
"."is used to indicate that the RDNSS can resolve global names and acts as the default RDNSS 👑. If there's no"."domain on the list, that means the RDNSSes only know about the listed domains and networks 🫶. Networks for reverse mapping are encoded as defined for IP6.ARPA [RFC3596] or IN-ADDR.ARPA [RFC2317].
The RDNSS Selection option contains one or more domains that the primary and secondary RDNSSes know well. If the domains and networks field pushes the option length past the maximum for a single option (255 octets), then multiple options MAY be used, as described in "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396]. When there are multiple options, the data portions of all the instances get concatenated together 🧩
The list of networks MUST cover all the domains configured in this option. The included networks SHOULD be as long as possible, which helps avoid collisions with information received on other option instances or with options received from DHCP servers on other network interfaces. Overlapping networks are interpreted so that the resolver can use any of the RDNSSes for queries that match those networks ✨
If the RDNSS Selection option contains an RDNSS address that was already learned from other DHCPv4 servers on the same network, and it also brings new domains or networks, the node SHOULD append that information to what it received earlier. The node MUST NOT remove previously obtained information. However, the node SHOULD NOT extend the lifetime of earlier information either. When a conflicting RDNSS address is learned from a less trusted interface, the node MUST ignore the option 🙈
The client SHALL periodically refresh information learned with the RDNSS Selection option. That information SHALL also be refreshed on link-state changes, such as those caused by node mobility, and when extending the lease of IPv4 addresses configured with DHCPv4 🔥
4.4. Scalability Considerations 🌈
Real talk, DHCP messages have general size limits, and those limits cap how many domains and networks can fit inside these RDNSS selection options 💀 The DHCP options for RDNSS selection work best in deployments where relatively few, carefully picked domains and networks are enough 🍓
4.5. Limitations on Use 🔒
The RDNSS selection option SHOULD NOT be enabled by default. (In this section, "RDNSS selection option" refers to both the DHCPv4 RDNSS Selection option and the DHCPv6 OPTION_RDNSS_SELECTION.) The option can be used in the following environments:
- The RDNSS selection option is delivered across a secure, trusted channel.
- The RDNSS selection option is not secured, but the client on a node does DNSSEC validation.
- The RDNSS selection option is not secured, the resolver does DNSSEC validation, and the client communicates with the resolver configured with the RDNSS selection option over a secure, trusted channel.
- The IP address of the RDNSS that is being recommended in the RDNSS selection option is known and trusted by the client. In other words, the RDNSS selection option doesn't introduce the client to a new RDNSS. It just tells the client that an RDNSS it already trusts is available for resolving certain domains 🫶
As DHCP by itself can't tell whether it's using a secure, trusted channel, or whether the client on a node is doing DNSSEC validation, this option cannot be used without being explicitly enabled. The functionality can be enabled for an interface through administrative means, such as provisioning tools or manual configuration. It can also be automatically enabled by a client on a node that knows it's performing DNSSEC validation, or by a node that is configured or hard-coded to trust certain interfaces (see Section 8.2) 🛡️
4.6. Coexistence of Various RDNSS Configuration Tools 🤝
The DHCPv4 RDNSS Selection option and the DHCPv6 OPTION_RDNSS_SELECTION are designed to coexist with each other, and with other tools used for RDNSS address configuration 💜
For RDNSS selection purposes, information received from all tools MUST be combined into a single list, as discussed in Section 4.1.
It can happen that DHCPv4 and DHCPv6 provide conflicting RDNSS selection information on the same or on equally trusted interfaces. In that case, DHCPv6 MUST be preferred, unless DHCPv4 is using additional security frameworks to protect the messages 🔥
The RDNSSes learned through tools other than the DHCPv4 RDNSS Selection option and the DHCPv6 OPTION_RDNSS_SELECTION MUST be handled as default RDNSSes, with medium preference, when building a list of RDNSSes to talk to (see Section 4.1) ✨
The non-exhaustive list of other possible sources for RDNSS address configuration is:
- DHCPv6
OPTION_DNS_SERVERSdefined in [RFC3646]. - DHCPv4 Domain Server option defined in [RFC2132].
- IPv6 Router Advertisement RDNSS Option defined in [RFC6106].
When the RDNSS selection option contains a default RDNSS address and other sources are providing RDNSS addresses, the resolver MUST make the decision about which one to prefer based on the RDNSS preference field value. If the RDNSS selection option defines medium preference, then the RDNSS from the RDNSS selection option SHALL be selected 🎯
If multiple sources provide the same RDNSS IP address(es), each address MUST be added to the RDNSS list only once 🧼
If a node indicated support for OPTION_RDNSS_SELECTION in a DHCPv6 request, the DHCPv6 server MAY omit sending OPTION_DNS_SERVERS. This enables an offloading use case, where the network administrator wants to only advertise low preference default RDNSSes 🍓
4.7. Considerations on Follow-Up Queries 🔁
Any follow-up queries that are performed based on an answer received on an interface MUST continue to use that same interface, no matter what the RDNSS selection settings are on any other interface 💅 For example, if a node receives a reply with a canonical name (CNAME) or delegation name (DNAME), the follow-up queries MUST be sent to the RDNSS(es) of the same interface, or to the same RDNSS, regardless of the FQDN received. Otherwise, referrals can fail 😭
4.8. Closing Network Interfaces and Local Caches 🧹
Cached information related to private namespaces can go stale after the network interface it was learned over is closed (Section 2.2), or after a new parallel network interface is opened that changes RDNSS selection preferences. An implementation SHOULD ensure that obsolete information is not kept around in these events. One way to avoid unwanted or obsolete responses from the local cache is to manage per-interface DNS caches, or to store interface information in the DNS cache. An alternative approach is to perform DNS cache flushing on interface change events, possibly selectively 🦋
5. Example of a Node Behavior ✨
Okay so this section is giving walkthrough energy 💅 Figure 7 shows what a node does when it spins up two network interfaces for parallel use and learns domain and network info from DHCPv6 servers 🎀
Application Node DHCPv6 server DHCPv6 server
on interface 1 on interface 2
| | |
| +-----------+ |
(1) | | open | |
| | interface | |
| +-----------+ |
| | |
(2) | |---option REQ-->|
| |<--option RESP--|
| | |
| +-----------+ |
(3) | | store | |
| | domains | |
| +-----------+ |
| | |
| +-----------+ |
(4) | | open | |
| | interface | |
| +-----------+ |
| | | |
(5) | |---option REQ------------------->|
| |<--option RESP-------------------|
| | | |
| +----------+ | |
(6) | | store | | |
| | domains | | |
| +----------+ | |
| | | |
Figure 7: Illustration of Learning DomainsHere's the step-by-step tea ☕
- A node opens its first network interface.
- The node obtains domain
domain1.example.comand IPv6 network0.8.b.d.0.1.0.0.2.ip6.arpafor the new interface 1 from the DHCPv6 server. - The node stores the learned domains and IPv6 networks for later use.
- The node opens its second network interface 2.
- The node obtains domain
domain2.example.comand IPv6 network information, say1.8.b.d.0.1.0.0.2.ip6.arpafor the new interface 2 from the DHCPv6 server. - The node stores the learned domains and networks for later use.
Figure 8 shows how a resolver actually uses that learned domain info 🦋 Network info for reverse lookups isn't drawn out here, but it would look pretty similar to the Figure 8 example, so no need to worry about it.
Application Node RDNSS RDNSS
on interface 1 on interface 2
| | | |
(1) |--Name REQ-->| | |
| | | |
| +----------------+ | |
(2) | | RDNSS | | |
| | prioritization | | |
| +----------------+ | |
| | | |
(3) | |------------DNS resolution------>|
| |<--------------------------------|
| | | |
(4) |<--Name resp-| | |
| | | |
Figure 8: Example on Choosing Interface Based on DomainAnd the flow, 1 to 4 🍓
- An application makes a request for resolving an FQDN, e.g.,
private.domain2.example.com. - A node creates a list of RDNSSes to contact and uses configured RDNSS selection information and stored domain information on prioritization decisions.
- The node has chosen interface 2, because it learned earlier from DHCPv6 that interface 2 has the domain
domain2.example.com. The node then resolves the requested name using interface 2's RDNSS to an IPv6 address. - The node replies to the application with the resolved IPv6 address.
6. Considerations for Network Administrators 🏠
Admins deploying private namespaces can help advanced nodes pick the right RDNSS by handing over the info this document describes 🫶
Private namespaces MUST be globally unique, so DNS stays unambiguous. That means no caching headaches and no destination selection mess-ups (see Section 2.3) 😭 The only exception is domains used for local name resolution, like .local.
Private namespaces MUST only consist of subdomains of domains where the relevant operator provides authoritative name service. So subdomains of example.com only fit in the private namespace served by an operator's RDNSSes if that same operator provides a SOA record for example.com. Not a loophole, bestie 🙅♀️
It is RECOMMENDED that admins using this tool deploy DNSSEC for their zone, to counter attacks against private namespaces 🔐
7. IANA Considerations 📋
Per this memo, IANA has assigned two new option codes ✨
The first one is assigned: the DHCPv4 RDNSS Selection option (146) from the "BOOTP Vendor Extensions and DHCP Options" registry, in the group "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters".
The second one is only requested to be assigned: OPTION_RDNSS_SELECTION (74) from the "DHCP Option Codes" registry, in the group "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)". Requested, not assigned yet, so don't count your chickens 🐣
8. Security Considerations 🚨
Okay this part is seriously important, so pay attention 🙈
8.1. Attack Vectors 💀
Attackers might try to use the DHCPv4 RDNSS Selection option or the DHCPv6 OPTION_RDNSS_SELECTION option to redirect some or all DNS queries from a resolver to places they shouldn't go. The goal could be denial of service, setting up a man-in-the-middle attack, or something similar. Super scary stuff ngl.
Attackers might also lure specific traffic by advertising domains and networks with scope that's anywhere from very small to very large, or by simply trying to make the attacker's RDNSS the highest preference default RDNSS. Not on my watch 😤
The best countermeasure for nodes is to implement validating DNSSEC-aware resolvers 🛡️ Trusting validation done by an RDNSS is only a possibility if a node trusts that RDNSS and can use a secure channel for DNS messages. No trust, no trust-based validation, periodt.
8.2. Trust Levels of Network Interfaces 🔒
How trustworthy an interface is, and how trustworthy the config info received over it is, depends on the implementation and/or the node's deployment. Figuring out that trust is out of scope for this spec 🫠
Trust might, for example, be based on the nature of the interface. An authenticated and encrypted VPN, or a layer 2 connection to a trusted home network or a trusted cellular network, might be considered trusted. An unauthenticated and unencrypted connection to an unknown visited network would likely be considered untrusted. Big red flag 🚩
In lots of cases, an implementation might not be able to determine trust levels without explicit configuration from the user or the node's administrator. So, for example, an implementation might not trust configuration by default, even if it came over VPN interfaces. Sometimes, standards bodies that focus on specific access network technologies might be able to define trust levels as part of their system design work 🧩
8.3. Importance of Following the Algorithm 🧠
Section 4 uses normative language to describe a node's internal behavior, so nodes don't accidentally open up new attack vectors by using RDNSS selection options by mistake. During the standards work, the consensus was that it's safer to not always enable this option by default, and to only turn it on when it's deemed useful and safe. Safety first, always 💖
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
- [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
- [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
- [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
- [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
- [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005.
9.2. Informative References
- [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
- [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4", RFC 3442, December 2002.
- [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
- [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
- [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
- [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
- [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
- [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
- [WITHOUT-IPV6NAT] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", Work in Progress, February 2012.
Appendix A. Possible Alternative Practices for RDNSS Selection 🌈
On some private namespace deployments, explicit policies for RDNSS selection aren't available. This section describes ways for nodes to work around the problem, by sending wide-spread queries and by using possibly existing indirect information elements as hints. Resourceful nodes eating this up 🧚
A.1. Sending Queries Out on Multiple Interfaces in Parallel 🚀
Okay so a possible current practice is to fire DNS queries out of multiple interfaces at once and then grab the best answer from whatever comes back 🏃♀️. A node can implement DNSSEC so it can reject any responses that can't be validated 🔐. Picking between legit answers is implementation specific, but replies from trusted RDNSSes get preferred 👑.
Ngl there's a downside. You use more resources, like power, if an interface (say wireless) has to wake up just to handle a DNS query that a cheaper interface could've covered 🔋. The RDNSSes also get extra load 😩. Local caching of results helps with both of these 💖. A node might also learn that some interfaces seem to give 'better' responses and prefer those, but it can't forget that fallback is required when it's connected to more than one network using private namespaces 🦋.
A.2. Search List Option for DNS Forward Lookup Decisions 🔍
A node can learn the special domains of its attached network interfaces from the IPv6 Router Advertisement DNS Search List Option [RFC6106], or from DHCP search list options: DHCPv4 Domain Search Option number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24 [RFC3646]. The node behaviour is very similar to the example in Section 5 🧚. These options aren't meant to be used for RDNSS selection, but nodes can use them as hints for smarter RDNSS prioritization, which helps make DNS queries faster and more likely to succeed ✨.
Overloading existing DNS search list options is not without problems 🙈. Resolvers would obviously use the domains learned from search lists for name resolution. That's fine in deployments where the search list has only a few domains, like 'example.com, private.example.com', but it can become a problem if lots of domains are configured 💀.
A.3. More-Specific Routes for Reverse Lookup Decisions 🛣️
[RFC4191] defines how more-specific routes can be provisioned for nodes. This information isn't meant to be used for RDNSS selection, but a node can still use it as a hint about which interface would be best to try first for reverse lookup procedures 🌸. An RDNSS configured via the same interface as the more-specific routes is more likely to answer reverse lookup questions correctly than an RDNSS on another interface. The likelihood of success is possibly higher if an RDNSS address is received in the same RA [RFC6106] as the more-specific route information 💜.
A.4. Longest Matching Prefix for Reverse Lookup Decisions 🎯
A node can use the longest matching prefix approach when deciding which RDNSS to contact for reverse lookups. Basically, the node can send a DNS query to an RDNSS learned over an interface that has a longest matching prefix to the address being queried 🧠. This approach can help when Unique Local Addressing (ULA) [RFC4193] addresses are in use, and when the queried address belongs to a node or server inside the same network (for example, an intranet) 🏢.
Appendix B. DNSSEC and Multiple Answers Validating with Different Trust Anchors 🔑
Okay, so when validating DNS answers with DNSSEC, a validator might order the list of trust anchors it uses to start validation chains, based on the node's preferences for those trust anchors 📋. A node could use this ability to pick among alternative DNS results from different interfaces 😤. Let's say a node has a trust anchor for the public DNS root and also a special-purpose trust anchor for example.com 🌈.
An answer comes in on interface i1 for www.example.com, and it validates using the public trust anchor ✅. Then another answer comes in on interface i2 for www.example.com, and that one validates using the trust anchor for example.com 🎀. In this case, the node has evidence for relying on i2 for answers in the example.com zone 👑.
Appendix C. Pseudocode for RDNSS Selection 💻
This section shows the RDNSS selection logic in C-style pseudocode 🧁. The code isn't meant to be usable as-is. It's just here for illustration purposes 💅.
The whole procedure starts with a call to "dns_query" function, which takes a query and a list of RDNSSes as parameters 🌟.
/* This is a structure that holds all information related to an RDNSS.*/
/* Here we include only the information related for this illustration.*/
struct rdnss
{
int prf; /* Preference of an RDNSS. */
int interface; /* Type of an interface RDNSS was learned over. */
struct d_and_n; /* Domains and networks information for this RDNSS. */
};
int has_special_knowledge( const struct rdnss *rdnss,
const char *query)
{
/* This function matches the query to the domains and networks
information of the given RDNSS. The function returns TRUE
if the query matches the domains and networks; otherwise, FALSE. */
/* The implementation of this matching function
is left for reader, or rather writer. */
/* return TRUE if query matches rdnss->d_and_n, otherwise FALSE. */
}
const struct rdnss* compare_rdnss_prf( const struct rdnss *rdnss_1,
const struct rdnss *rdnss_2 )
{
/* This function compares preference values of two RDNSSes and
returns the more preferred RDNSS. The function prefers rdnss_1
in the case of equal preference values. */
if (rdnss_1->prf == HIGH_PRF) return rdnss_1;
if (rdnss_2->prf == HIGH_PRF) return rdnss_2;
if (rdnss_1->prf == MED_PRF) return rdnss_1;
if (rdnss_2->prf == MED_PRF) return rdnss_2;
return rdnss_1;
}
const struct rdnss* compare_rdnss_trust( const struct rdnss *rdnss_1,
const struct rdnss *rdnss_2 )
{
/* This function compares trust of the two given RDNSSes. The trust
is based on the trust on the interface RDNSS was learned on. */
/* If the interface is the same, the trust is also the same,
and hence, function will return NULL to indicate lack of
difference in trust. */
if (rdnss_1->interface == rdnss_2->interface) return NULL;
/* Otherwise, implementation-specific rules define which interface
is considered more secure than the other. The rules shown here
are only for illustrative purposes and must be overwritten by
real implementations. */
if (rdnss_1->interface == IF_VPN) return rdnss_1;
if (rdnss_2->interface == IF_VPN) return rdnss_2;
if (rdnss_1->interface == IF_CELLULAR) return rdnss_1;
if (rdnss_2->interface == IF_CELLULAR) return rdnss_2;
if (rdnss_1->interface == IF_WLAN) return rdnss_1;
if (rdnss_2->interface == IF_WLAN) return rdnss_2;
/* Both RDNSSes are from unknown interfaces, so return NULL as
trust-based comparison is impossible. */
return NULL;
}
int compare_rdnsses ( const struct rdnss *rdnss_1,
const struct rdnss *rdnss_2,
const char *query)
{
/* This function compares two RDNSSes and decides which one is more
preferred for resolving the query. If the rdnss_1 is more
preferred, the function returns TRUE; otherwise, FALSE. */
const struct rdnss *more_trusted_rdnss = NULL;
const struct rdnss *less_trusted_rdnss = NULL;
/* Find out if either RDNSS is more trusted. */
more_trusted_rdnss = compare_rdnss_trust( rdnss_1, rdnss_2 );
/* Check if either was more trusted. */
if (more_trusted_rdnss)
{
/* Check which RDNSS was less trusted. */
less_trusted_rdnss =
more_trusted_rdnss == rdnss_1 ? rdnss_2 : rdnss_1;
/* If the more trusted interface is not of low preference
or has special knowledge about the query, or the more
trusted is more preferred and the less trusted has no special
information, prefer more trusted. Otherwise, prefer less trusted. */
if (more_trusted_rdnss->prf != LOW_PRF ||
has_special_knowledge( more_trusted_rdnss, query ) ||
(compare_rdnss_prf( more_trusted_rdnss, less_trusted_rdnss)
== more_trusted_rdnss &&
!has_special_knowledge( less_trusted_rdnss, query)))
{
/* If the more_trusted_rdnss was rdnss_1, return TRUE. */
return more_trusted_rdnss == rdnss_1 ? TRUE : FALSE;
}
else
{
/* If the more_trusted_rdnss was rdnss_1, return TRUE. */
return less_trusted_rdnss == rdnss_1 ? TRUE : FALSE;
}
}
else
{
/* There is no trust difference between RDNSSes; therefore, prefer the
RDNSS that has special knowledge. If both have specific knowledge,
then prefer the rdnss_1. */
if (has_special_knowledge( rdnss_1, query )) return TRUE;
if (has_special_knowledge( rdnss_2, query )) return FALSE;
/* Neither had special knowledge. Therefore, return TRUE if
rdnss_1 is more preferred; otherwise, return FALSE */
return compare_rdnss_prf( rdnss_1 , rdnss_2 )
== rdnss_1 ? TRUE : FALSE;
}
}
void bubble_sort_rdnsses( struct rdnss rdnss_list[],
const int rdnsses,
const char* query)
{
/* This function implements a bubble sort to arrange
RDNSSes in rdnss_list into preference order. */
int i;
int swapped = 0;
struct rdnss rdnss_swap;
do
{
/* Clear swapped-indicator. */
swapped = FALSE;
/* Go through the RDNSS list. */
for (i = 0; i < rdnsses-1; i++)
{
/* Check if the next two items are in the right order, i.e.,
more preferred before less preferred. */
if (compare_rdnsses( &rdnss_list[i],
&rdnss_list[i+1], query) == FALSE)
{
/* The order between two was not right, so swap these two RDNSSes. */
rdnss_swap = rdnss_list[i];
rdnss_list[i] = rdnss_list[i+1];
rdnss_list[i+1] = rdnss_swap;
swapped = TRUE;
}
}
} while (swapped);
/* No more swaps, which means the rdnss_list is now sorted
into preference order. */
}
struct hostent *dns_query( struct rdnss rdnss_list[],
const int rdnsses,
const char* query )
{
/* Perform address resolution for the query. */
int i;
struct hostent response;
/* Sort the RDNSSes into preference order. */
/* This is the function with which this pseudocode starts. */
bubble_sort_rdnsses( &rdnss_list[0], rdnsses, query );
/* Go thourgh all RDNSSes or until valid response is found. */
for (i = 0; i < rdnsses; i++)
{
/* Use the highest preference RDNSS first. */
response = send_and_validate_dns_query( rndss_list[i], query);
/* Check if DNSSEC validation is in use, and if so, validate the
received response. */
if (dnssec_in_use)
{
response = dnssec_validate(response);/* If response is validated, use that. Otherwise, proceed to next
RDNSS. */
if (response) return response;
else continue;
}
/* If acceptable response has been found, return it. */
if (response) return response;
}
return NULL;
}Appendix D. Acknowledgements ✨
Okay, now for my favourite part 🥹 The authors want to thank everyone who gave them super valuable feedback and brilliant improvement ideas. The list is huge and iconic: Mark Andrews, Jari Arkko, Marcelo Bagnulo, Brian Carpenter, Stuart Cheshire, Lars Eggert, Stephan Farrell, Tomohiro Fujisaki, Brian Haberman, Peter Koch, Suresh Krishnan, Murray Kucherawy, Barry Leiba, Edward Lewis, Kurtis Lindqvist, Arifumi Matsumoto, Erik Nordmark, Steve Padgett, Fabien Rapin, Matthew Ryan, Robert Sparks, Dave Thaler, Sean Turner, Margaret Wasserman, Dan Wing, and Dec Wojciech 🌸 Then there are two extra-special shoutouts, Ted Lemon and Julien Laganier, who get special thanks for their work on the security considerations 🔥🫶 Honestly, the security part is where the real care went in, so they deserve all the flowers 💐
Authors' Addresses 💌
Teemu Savolainen
Nokia
Hermiankatu 12 D
Tampere FI-33720
Finland
EMail: teemu.savolainen@nokia.com
Jun-ya Kato
NTT
9-11, Midori-Cho 3-Chome Musashino-Shi
Tokyo 180-8585
Japan
EMail: kato@syce.net
Ted Lemon
Nominum, Inc.
2000 Seaport Boulevard
Redwood City, CA 94063
USA
Phone: +1 650 381 6000
EMail: Ted.Lemon@nominum.com📦 where this page comes from
- ietf: rfc6731 2012-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms