| < draft-reddy-add-enterprise-split-dns-09.txt | draft-reddy-add-enterprise-split-dns-10.txt > | |||
|---|---|---|---|---|
| ADD T. Reddy | ADD T. Reddy | |||
| Internet-Draft Akamai | Internet-Draft Akamai | |||
| Intended status: Standards Track D. Wing | Intended status: Standards Track D. Wing | |||
| Expires: 3 September 2022 Citrix | Expires: 15 October 2022 Citrix | |||
| K. Smith | K. Smith | |||
| Vodafone | Vodafone | |||
| B. Schwartz | B. Schwartz | |||
| 2 March 2022 | 13 April 2022 | |||
| Split-Horizon DNS Configuration | Establishing Local DNS Authority in Split-Horizon Environments | |||
| draft-reddy-add-enterprise-split-dns-09 | draft-reddy-add-enterprise-split-dns-10 | |||
| Abstract | Abstract | |||
| When split-horizon DNS is deployed by a network, certain domains can | When split-horizon DNS is deployed by a network, certain domains can | |||
| be resolved authoritatively by the network-provided DNS resolver. | be resolved authoritatively by the network-provided DNS resolver. | |||
| DNS clients that don't always use this resolver might wish to do so | DNS clients that don't always use this resolver might wish to do so | |||
| for these domains. This specification enables networks to inform DNS | for these domains. This specification describes how clients can | |||
| clients about domains that are inside the split-horizon DNS, and | confirm the local resolver's authority over these domains. | |||
| describes how clients can confirm the local resolver's authority over | ||||
| these domains. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 3 September 2022. | This Internet-Draft will expire on 15 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.1. Authorized Split Horizon . . . . . . . . . . . . . . . . 4 | 2.1. Validated Split-Horizon . . . . . . . . . . . . . . . . . 4 | |||
| 2.2. Domain Camping . . . . . . . . . . . . . . . . . . . . . 4 | ||||
| 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4. Provisioning Domains dnsZones . . . . . . . . . . . . . . . . 4 | 4. Local Domain Hint Mechanisms . . . . . . . . . . . . . . . . 4 | |||
| 4.1. Confirming Authority over the Domains . . . . . . . . . . 5 | 4.1. DHCP Options . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4.1.1. Confirmation using a pre-configured public | 4.2. Host Configuration . . . . . . . . . . . . . . . . . . . 5 | |||
| resolver . . . . . . . . . . . . . . . . . . . . . . 5 | 4.3. Provisioning Domains dnsZones . . . . . . . . . . . . . . 6 | |||
| 4.1.2. Confirmation using DNSSEC . . . . . . . . . . . . . . 6 | 4.4. Split DNS Configuration for IKEv2 . . . . . . . . . . . . 6 | |||
| 5. An example of Split-Horizon DNS Configuration . . . . . . . . 6 | 5. Establishing Local DNS Authority . . . . . . . . . . . . . . 6 | |||
| 6. Split DNS Configuration for IKEv2 . . . . . . . . . . . . . . 8 | 6. Validating Authority over Local Domain Hints . . . . . . . . 6 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 6.1. Using Pre-configured Public Resolver . . . . . . . . . . 7 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 6.2. Using DNSSEC . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | 7. Examples of Split-Horizon DNS Configuration . . . . . . . . . 7 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 7.1. Split-Horizon Entire Zone . . . . . . . . . . . . . . . . 8 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 7.1.1. Verification using Public Resolver . . . . . . . . . 9 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . 10 | 7.1.2. Verification using DNSSEC . . . . . . . . . . . . . . 10 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | 7.2. Split-Horizon Only Subdomain of Zone . . . . . . . . . . 12 | |||
| 8. Validation with IKEv2 . . . . . . . . . . . . . . . . . . . . 12 | ||||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | ||||
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | ||||
| 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 | ||||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 13 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
| 1. Introduction | 1. Introduction | |||
| To resolve a DNS query, there are three essential behaviors that an | To resolve a DNS query, there are three essential behaviors that an | |||
| implementation can apply: (1) answer from a local database, (2) query | implementation can apply: (1) answer from a local database, (2) query | |||
| the relevant authorities and their parents, or (3) ask a server to | the relevant authorities and their parents, or (3) ask a server to | |||
| query those authorities and return the final answer. Implementations | query those authorities and return the final answer. Implementations | |||
| that use these behaviors are called "authoritative nameservers", | that use these behaviors are called "authoritative nameservers", | |||
| "full resolvers", and "forwarders" (or "stub resolvers"). However, | "full resolvers", and "forwarders" (or "stub resolvers"). However, | |||
| an implementation can also implement a mixture of these behaviors, | an implementation can also implement a mixture of these behaviors, | |||
| skipping to change at page 3, line 30 ¶ | skipping to change at page 3, line 30 ¶ | |||
| Network clients that use pure stub resolution, sending all queries to | Network clients that use pure stub resolution, sending all queries to | |||
| the network-provided resolver, will always receive the split-horizon | the network-provided resolver, will always receive the split-horizon | |||
| results. Conversely, clients that send all queries to a different | results. Conversely, clients that send all queries to a different | |||
| resolver or implement pure full resolution locally will never receive | resolver or implement pure full resolution locally will never receive | |||
| them. Clients with either pure resolution behavior are out of scope | them. Clients with either pure resolution behavior are out of scope | |||
| for this specification. Instead, this specification enables hybrid | for this specification. Instead, this specification enables hybrid | |||
| clients to access split-horizon results from a network-provided | clients to access split-horizon results from a network-provided | |||
| hybrid resolver, while using a different resolution method for some | hybrid resolver, while using a different resolution method for some | |||
| or all other names. | or all other names. | |||
| To achieve the required security properties, clients must be able to | There are several existing mechanisms for a network to provide | |||
| authenticate the DNS servers provided by the network, for example | clients with "local domain hints", listing domain names that have | |||
| using the techniques proposed in [I-D.ietf-add-dnr] and | special treatment in this network (Section 4). However, none of the | |||
| [I-D.ietf-add-ddr], and prove that they are authorized to serve the | local domain hint mechanisms enable clients to determine whether this | |||
| offered split-horizon DNS names. As a result, use of this | special treatment is authorized by the domain owner. Instead, these | |||
| specification is limited to servers that support authenticated | specifications require clients to make their own determinations about | |||
| encryption and split-horizon DNS names that are properly rooted in | whether to trust and rely on these hints. | |||
| the global DNS. | ||||
| This specification describes a protocol between domains, networks, | ||||
| and clients that allows the network to establish its authority over a | ||||
| domain to a client (Section 5). Clients can use this protocol to | ||||
| confirm that a local domain hint was authorized by the domain | ||||
| (Section 6), which might influence its processing of that hint. | ||||
| This specification relies on securely identified local DNS servers | ||||
| and globally valid NS records. Use of this specification is | ||||
| therefore limited to servers that support authenticated encryption | ||||
| and split-horizon DNS names that are properly rooted in the global | ||||
| DNS. | ||||
| 2. Terminology | 2. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119][RFC8174] when, and only when, they appear in all | 14 [RFC2119][RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| This document makes use of the terms defined in [RFC8499]. The terms | This document makes use of the terms defined in [RFC8499]. The term | |||
| "Private DNS", "Global DNS" and "Split DNS" are defined in [RFC8499]. | "Global DNS" is defined in [RFC8499]. | |||
| 'Encrypted DNS' refers to a DNS protocol that provides an encrypted | 'Encrypted DNS' refers to a DNS protocol that provides an encrypted | |||
| channel between a DNS client and server (e.g., DoT, DoH, or DoQ). | channel between a DNS client and server (e.g., DoT, DoH, or DoQ). | |||
| The terms 'Authorized Split Horizon' and 'Domain Camping' are also | The term 'Validated Split-Horizon' is also defined. | |||
| defined. | ||||
| 2.1. Authorized Split Horizon | ||||
| A split horizon configuration for some name is considered | ||||
| "authorized" if any parent of that name has given the local network | ||||
| permission to serve its own responses for that name. Such | ||||
| authorizations generally extend to the entire subtree of names below | ||||
| the authorization point. | ||||
| 2.2. Domain Camping | ||||
| Domain Camping refers to operating a nameserver which claims to be | ||||
| authoritative for a zone, but actually isn't. For example, a domain | ||||
| called example.com on the Internet and an internal DNS server also | ||||
| claims to be authoritative for example.com, but has no delegation | ||||
| from example.com on the Internet. Someone might domain camp on a | ||||
| popular domain name providing the ability to monitor queries and | ||||
| modify answers for that domain. | ||||
| A common variation on domain camping is "NXDOMAIN camping", in which | 2.1. Validated Split-Horizon | |||
| a nameserver claims a zone that does not exist in the global DNS. | ||||
| This is a form of domain camping because it seizes a portion of the | ||||
| parent zone without permission. The use of nonexistent TLDs for | ||||
| local services is a form of NXDOMAIN camping on the root zone. | ||||
| Any form of domain camping likely violates the IAB's guidance | A split horizon configuration for some name is considered "validated" | |||
| regarding "the Unique DNS Root" [RFC2826]. | if the network client has confirmed that a parent of that name has | |||
| authorized the local network to serve its own responses for that | ||||
| name. Such authorization generally extends to the entire subtree of | ||||
| names below the authorization point. | ||||
| 3. Scope | 3. Scope | |||
| The protocol in this document allows the domain owner to create a | The protocol in this document allows the domain owner to create a | |||
| split-horizon DNS. Other entities which do not own the domain are | split-horizon DNS. Other entities which do not own the domain are | |||
| detected by the client. Thus, DNS filtering is not enabled by this | detected by the client. Thus, DNS filtering is not enabled by this | |||
| protocol. | protocol. | |||
| 4. Provisioning Domains dnsZones | 4. Local Domain Hint Mechanisms | |||
| There are various mechanisms by which a network client might learn | ||||
| "local domain hints", which indicate a special treatment for | ||||
| particular domain names upon joining a network. This section | ||||
| provides a review of some common and standardized mechanisms for | ||||
| receiving domain hints. | ||||
| 4.1. DHCP Options | ||||
| There are several DHCP options that convey local domain hints of | ||||
| different kinds. The most directly relevant is "RDNSS Selection" | ||||
| [RFC6731], which provides "a list of domains ... about which the | ||||
| RDNSS has special knowledge", along with a "High", "Medium", or "Low" | ||||
| preference for each name. The specification notes the difficulty of | ||||
| relying on these hints without validation: | ||||
| Trustworthiness of an interface and configuration information | ||||
| received over the interface is implementation and/or node | ||||
| deployment dependent, and the details of determining that trust | ||||
| are beyond the scope of this specification. | ||||
| Other local domain hints in DHCP include the "Domain Name" [RFC2132], | ||||
| "Access Network Domain Name" [RFC5986], "Client FQDN" | ||||
| [RFC4702][RFC4704], and "Name Service Search" [RFC2937] options. | ||||
| This specification may help clients to interpret these hints. For | ||||
| example, a rogue DHCP server could use the "Client FQDN" option to | ||||
| assign a client the name "www.example.com" in order to prevent the | ||||
| client from reaching the true "www.example.com". A client could use | ||||
| this specification to check the network's authority over this name, | ||||
| and adjust its behavior to avoid this attack if authority is not | ||||
| established. | ||||
| The Domain Search option [RFC3397] [RFC3646], which offers clients a | ||||
| way to expand short names into Fully Qualified Domain Names, is not a | ||||
| "local domain hint" by this definition, because it does not modify | ||||
| the processing of any specific domain. (The specification notes that | ||||
| this option can be a "fruitful avenue of attack for a rogue DHCP | ||||
| server", and provides a number of cautions against accepting it | ||||
| unconditionally.) | ||||
| 4.2. Host Configuration | ||||
| A host can be configured with DNS information when it joins a | ||||
| network, including when it brings up VPN (which is also considered | ||||
| joining a(n additional) network, detailed in Section 8). Existing | ||||
| implementations determine the host has joined a certain network via | ||||
| SSID, IP subnet assigned, DNS server IP address or name, and other | ||||
| similar mechanisms. For example, one existing implementation | ||||
| determines the host has joined an internal network because the DHCP- | ||||
| assigned IP address belongs to the company's IP address (as assigned | ||||
| by the regional IP addressing authority) and the DHCP-advertised DNS | ||||
| IP address is one used by IT at that network. Other mechanisms exist | ||||
| in other products but are not interesting to this specification; | ||||
| rather what is interesting is this step to determine "we have joined | ||||
| the internal corporate network" occurred and the DNS server is | ||||
| configured as authoritative for certain DNS zones (e.g., | ||||
| *.example.com). | ||||
| Because a rogue network can simulate all or most of the above | ||||
| characteristics this specification details how to validate these | ||||
| claims in Section 6. | ||||
| 4.3. Provisioning Domains dnsZones | ||||
| Provisioning Domains (PvDs) are defined in [RFC7556] as sets of | Provisioning Domains (PvDs) are defined in [RFC7556] as sets of | |||
| network configuration information that clients can use to access | network configuration information that clients can use to access | |||
| networks, including rules for DNS resolution and proxy configuration. | networks, including rules for DNS resolution and proxy configuration. | |||
| The PvD Key dnsZones is defined in [RFC8801]. The PvD Key dnsZones | The PvD Key "dnsZones" is defined in [RFC8801] as a list of "DNS | |||
| notifies clients of names for which one of the network-provided | zones searchable and accessible" in this provisioning domain. | |||
| resolvers is authoritative. Attempting to resolve these names via | Attempting to resolve these names via another resolver might fail or | |||
| another resolver might fail or return results that are not correct | return results that are not correct for this network. | |||
| for this network. | ||||
| Each dnsZones entry indicates a claim of authority over a domain and | 4.4. Split DNS Configuration for IKEv2 | |||
| its subdomains. For example, if the dnsZones entry is | ||||
| "example.test", this covers "example.test", "www.example.test", and | ||||
| "mail.eng.example.test", but not "otherexample.test" or | ||||
| "example.test.net". | ||||
| [RFC8801] defines a mechanism for discovering multiple Explicit PvDs | In IKEv2 VPNs, the INTERNAL_DNS_DOMAIN configuration attribute can be | |||
| on a single network and their Additional Information by means of an | used to indicate that a domain is "internal" to the VPN [RFC8598]. | |||
| HTTP-over-TLS query using a URI derived from the PvD ID. This set of | To prevent abuse, the specification notes various possible | |||
| additional configuration information is referred to as a Web | restrictions on the use of this attribute: | |||
| Provisioning Domain (Web PvD). The PvD RA option defined in | ||||
| [RFC8801] SHOULD set the H-flag to indicate that Additional | ||||
| Information is available. This Additional Information JSON object | ||||
| SHOULD include the "dnsZones" key to define the DNS domains for which | ||||
| the network claims authority. | ||||
| 4.1. Confirming Authority over the Domains | "If a client is configured by local policy to only accept a | |||
| limited set of INTERNAL_DNS_DOMAIN values, the client MUST ignore | ||||
| any other INTERNAL_DNS_DOMAIN values." | ||||
| To comply with [RFC2826], each dnsZones entry must be authorized in | "IKE clients MAY want to require whitelisted domains for Top-Level | |||
| the global DNS hierarchy. To prevent domain camping, clients must | Domains (TLDs) and Second-Level Domains (SLDs) to further prevent | |||
| confirm this authorization before making use of the entry. | malicious DNS redirections for well-known domains." | |||
| To enable confirmation, the client must discover and validate the | Within these guidelines, a client could adopt a local policy of | |||
| Authentication Domain Names (ADNs) of the network-designated | accepting INTERNAL_DNS_DOMAIN values only when it can validate the | |||
| resolvers using a method such as DNR [I-D.ietf-add-dnr]. The client | local DNS server's authority over those names as described in this | |||
| must also perform an NS query for each dnsZones entry and confirm | specification. | |||
| that at least one of the ADNs appears in each NS RRSet. This NS | ||||
| query must be conducted in a manner that is not vulnerable to | ||||
| tampering by the local network. Suitable tamperproof resolution | ||||
| strategies are described in Section 4.1.1 and Section 4.1.2. | ||||
| Note that each dnsZones entry is authorized only for the specific | 5. Establishing Local DNS Authority | |||
| resolvers whose ADNs appear in its NS RRSet. If a network offers | ||||
| multiple encrypted resolvers via DNR, each dnsZones entry may be | ||||
| authorized for a distinct subset of the network-provided resolvers. | ||||
| 4.1.1. Confirmation using a pre-configured public resolver | To establish its authority over some DNS zone, a participating | |||
| network MUST offer one or more encrypted resolvers via DNR | ||||
| [I-D.ietf-add-dnr] or an equivalent mechanism (see Section 8). At | ||||
| least one of these resolvers' Authentication Domain Names (ADNs) MUST | ||||
| appear in an NS record for that zone. This arrangement establishes | ||||
| this resolver's authority over the zone. | ||||
| The client sends an NS query for the domain in dnsZones to a pre- | 6. Validating Authority over Local Domain Hints | |||
| configured resolver that is external to the network, over a secure | ||||
| transport. Clients SHOULD apply whatever acceptance rules they would | ||||
| otherwise apply when using this resolver (e.g. checking the AD bit, | ||||
| validating RRSIGs). | ||||
| 4.1.2. Confirmation using DNSSEC | To validate the network's authority over a domain name, participating | |||
| clients MUST resolve the NS record for that name. If the resolution | ||||
| result is NODATA, the client MUST remove the last label and repeat | ||||
| the query until a response other than NODATA is received. | ||||
| Once the NS record has been resolved, the client MUST check if each | ||||
| local encrypted resolver's Authentication Domain Name appears in the | ||||
| NS record. The client SHALL regard each such resolver as | ||||
| authoritative for the zone of this NS record. | ||||
| Each validation of authority applies only to the specific resolvers | ||||
| whose names appear in the NS RRSet. If a network offers multiple | ||||
| encrypted resolvers, each DNS entry may be authorized for a distinct | ||||
| subset of the network-provided resolvers. | ||||
| A zone is termed a "Validated Split-Horizon zone" after successful | ||||
| validation using a "tamperproof" NS resolution method, i.e. a method | ||||
| that is not subject to interference by the local network operator. | ||||
| Two possible tamperproof resolution methods are presented below. | ||||
| 6.1. Using Pre-configured Public Resolver | ||||
| The client sends the NS query to a pre-configured resolver that is | ||||
| external to the network, over a secure transport. Clients SHOULD | ||||
| apply whatever acceptance rules they would otherwise apply when using | ||||
| this resolver (e.g. checking the AD bit, validating RRSIGs). | ||||
| 6.2. Using DNSSEC | ||||
| The client resolves the NS record using any resolution method of its | The client resolves the NS record using any resolution method of its | |||
| choice (e.g. querying one of the network-provided resolvers, | choice (e.g. querying one of the network-provided resolvers, | |||
| performing iterative resolution locally), and performs full DNSSEC | performing iterative resolution locally), and performs full DNSSEC | |||
| validation locally [RFC6698]. The result is processed based on its | validation locally [RFC6698]. The result is processed based on its | |||
| DNSSEC validation state (Section 4.3 of [RFC4035]): | DNSSEC validation state (Section 4.3 of [RFC4035]): | |||
| * "Secure": the NS record is used for confirmation. | Secure: the response is used for validation. | |||
| * "Bogus" or "Indeterminate": the record is rejected and | Bogus or Indeterminate: the response is rejected and validation is | |||
| confirmation is considered to have failed. | considered to have failed. | |||
| * "Insecure": the client SHOULD retry the confirmation process using | Insecure: the client SHOULD retry the validation process using a | |||
| a different method, such as the one in Section 4.1.1, to ensure | different method, such as the one in Section 6.1, to ensure | |||
| compatibility with unsigned names. | compatibility with unsigned names. | |||
| 5. An example of Split-Horizon DNS Configuration | 7. Examples of Split-Horizon DNS Configuration | |||
| Two examples are shown below. The first example showing an company | ||||
| with an internal-only DNS server resolving the entire zone for that | ||||
| company (e.g., *.example.com) the second example resolving only a | ||||
| subdomain of the company's zone (e.g., *.internal.example.com). | ||||
| 7.1. Split-Horizon Entire Zone | ||||
| Consider an organization that operates "example.com", and runs a | Consider an organization that operates "example.com", and runs a | |||
| different version of its global domain on its internal network. | different version of its global domain on its internal network. | |||
| Today, on the Internet it publishes two NS records, "ns1.example.com" | Today, on the Internet it publishes two NS records, "ns1.example.com" | |||
| and "ns2.example.com". | and "ns2.example.com". | |||
| To add support for the mechanism described in this document, the | The host and network first need mutual support one of the mechanisms | |||
| network and endpoints first need to support [I-D.ietf-add-dnr] and | described in learning (Section 4). Shown in Figure 1 is learning | |||
| [RFC8801]. Then, for each site, the administrator would add DNS | using DNR and PvD. | |||
| servers named "ns1.example.com" or "ns2.example.com" (the names | ||||
| published on the Internet). Those names would be advertised to the | ||||
| endpoints as described in [I-D.ietf-add-dnr]. | ||||
| The endpoints compliant with this specification can then determine | Validation is then perfomed using either Public DNS (Section 7.1.1) | |||
| the network's internal nameservers are owned and managed by the same | or DNSSEC (Section 7.1.2). | |||
| entity that has published the NS records on the Internet as shown in | ||||
| Figure 1: | ||||
| Steps 1-2: The client joins the network, obtains an IP address, and | steps 1-2: The client determines the network's DNS server | |||
| discovers the resolvers "ns1.example.com" and "ns2.example.com" | (ns1.example.com) and Provisioning Domain (pvd.example.com) using | |||
| and their IP addresses using DNR [I-D.ietf-add-dnr]. Using | DNR [I-D.ietf-add-dnr] and PvD [RFC8801], using one of DNR Router | |||
| [RFC8801], the client also discovers the PvD FQDN is | Solicitation, DHCPv4, or DHCPv6. | |||
| "pvd.example.com". | ||||
| Steps 3-7: The client establishes an encrypted DNS connection with | step 3-5: The client connects to the DNR-learned DNS server | |||
| "ns1.example.com", validates its TLS certificate, and queries it | (ns1.example.com), validates its certificate, and queries for | |||
| for "pvd.example.com" to retrieve the PvD JSON object. Note that | pvd.example.com. | |||
| [RFC8801] in Section 4.1 mandates the PvD FQDN MUST be resolved | ||||
| using the DNS servers indicated by the associated PvD. The PvD | steps 6-7: The client connects to the PvD server, validates its | |||
| contains: | certificate, and retrieves the provisioning domain JSON | |||
| information indicated by the associated PvD. The PvD contains: | ||||
| { | { | |||
| "identifier": "pvd.example.com", | "identifier": "pvd.example.com", | |||
| "expires": "2020-05-23T06:00:00Z", | "expires": "2020-05-23T06:00:00Z", | |||
| "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], | "prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"], | |||
| "dnsZones:": ["example.com"] | "dnsZones:": ["example.com"] | |||
| } | } | |||
| The JSON keys "identifier", "expires", and "prefixes" are defined | The JSON keys "identifier", "expires", and "prefixes" are defined | |||
| in [RFC8801]. | in [RFC8801]. | |||
| Steps 8-9: The client then uses an encrypted DNS connection to a | +---------+ +--------------------+ +------------+ +--------+ | |||
| public resolver (e.g., 1.1.1.1) to issue NS queries for the | | client | | Network | | Network | | Router | | |||
| domains in dnsZones. The NS lookup for "example.com" will return | | | | encrypted resolver | | PvD server | | | | |||
| +---------+ +--------------------+ +------------+ +--------+ | ||||
| | | | | | ||||
| | Router Solicitation or | | | | ||||
| | DHCPv4/DHCPv6 (1) | | | | ||||
| |----------------------------------------------------------->| | ||||
| | | | | | ||||
| | Response with DNR hostnames & | | | | ||||
| | PvD FQDN (2) | | | | ||||
| |<-----------------------------------------------------------| | ||||
| | ----------------------------\ | | | | ||||
| |-| now knows DNR hostnames & | | | | | ||||
| | | PvD FQDN | | | | | ||||
| | |---------------------------/ | | | | ||||
| | | | | | ||||
| | TLS connection to ns1.example.com (3) | | | ||||
| |------------------------------------>| | | | ||||
| | ---------------------------\ | | | | ||||
| |-| validate TLS certificate | | | | | ||||
| | |--------------------------| | | | | ||||
| | | | | | ||||
| | resolve pvd.example.com (4) | | | | ||||
| |------------------------------------>| | | | ||||
| | | | | | ||||
| | A or AAAA records (5) | | | | ||||
| |<------------------------------------| | | | ||||
| | | | | | ||||
| | https://pvd.example.com/.well-known/pvd (6) | | | ||||
| |---------------------------------------------->| | | ||||
| | | | | | ||||
| | 200 OK (JSON Additional Information) (7) | | | ||||
| |<----------------------------------------------| | | ||||
| | -----------------------\ | | | | ||||
| |-| dnsZones=example.com | | | | | ||||
| | |----------------------| | | | | ||||
| Figure 1: Learning Local Claims of DNS Authority | ||||
| 7.1.1. Verification using Public Resolver | ||||
| The figure below shows the steps performed to verify the local claims | ||||
| of DNS authority using a public resolver. | ||||
| Steps 1-2: The client uses an encrypted DNS connection to a public | ||||
| resolver (e.g., 1.1.1.1) to issue NS queries for the domains in | ||||
| dnsZones. The NS lookup for "example.com" will return | ||||
| "ns1.example.com" and "ns2.example.com". | "ns1.example.com" and "ns2.example.com". | |||
| Step 10: As the network-provided nameservers are the same as the | Step 3: As the network-provided nameservers are the same as the | |||
| names retrieved from the public resolver and the network- | names retrieved from the public resolver and the network- | |||
| designated resolver's certificate includes at least one of the | designated resolver's certificate includes at least one of the | |||
| names retrieved from the public resolver, the client has finished | names retrieved from the public resolver, the client has finished | |||
| validation that the nameservers signaled in [I-D.ietf-add-dnr] and | validation that the nameservers signaled in [I-D.ietf-add-dnr] and | |||
| [RFC8801] are owned and managed by the same entity that published | [RFC8801] are owned and managed by the same entity that published | |||
| the NS records on the Internet. The endpoint will then use that | the NS records on the Internet. The endpoint will then use that | |||
| information from [I-D.ietf-add-dnr] and [RFC8801] to resolve names | information from [I-D.ietf-add-dnr] and [RFC8801] to resolve names | |||
| within dnsZones. | within dnsZones. | |||
| +---------+ +---------------------+ +------------+ +---------+ +---------+ | +---------+ +--------------------+ +----------+ | |||
| | client | | Network | | Network | | Router | | public | | | client | | Network | | public | | |||
| | | | encrypted resolvr | | PvD server | | | | resolvr | | | | | encrypted resolver | | resolver | | |||
| +---------+ +---------------------+ +------------+ +---------+ +---------+ | +---------+ +--------------------+ +----------+ | |||
| | | | | | | | | | | |||
| | Router Solicitation (1) | | | | | | TLS connection | | | |||
| |-------------------------------------------------------------->| | | |--------------------------------------------------->| | |||
| | | | | | | | ---------------------------\ | | | |||
| | Router Advertisement with DNR hostnames & PvD FQDN (2) | | | |-| validate TLS certificate | | | | |||
| |<--------------------------------------------------------------| | | | |--------------------------| | | | |||
| | -------------------------------------\ | | | | | | | | | |||
| |-| now knows DNR hostnames & PvD FQDN | | | | | | | NS? example.com (1) | | | |||
| | |------------------------------------| | | | | | |--------------------------------------------------->| | |||
| | | | | | | | | | | |||
| | TLS connection to ns1.example.com (3) | | | | | | NS=ns1.example.com, ns2.example.com (2) | | | |||
| |----------------------------------------->| | | | | |<---------------------------------------------------| | |||
| | ---------------------------\ | | | | | | -------------------------------\ | | | |||
| |-| validate TLS certificate | | | | | | |-| both DNR ADNs are authorized | | | | |||
| | |--------------------------| | | | | | | ----------------------\--------| | | | |||
| | | | | | | |-| finished validation | | | | |||
| | resolve pvd.example.com (4) | | | | | | |---------------------| | | | |||
| |----------------------------------------->| | | | | | | | | |||
| | | | | | | | use network-designated resolver | | | |||
| | AAAA records (5) | | | | | | for example.com (3) | | | |||
| |<-----------------------------------------| | | | | |----------------------------------------->| | | |||
| | | | | | | | | | | |||
| | https://pvd.example.com/.well-known/pvd (6) | | | | ||||
| |--------------------------------------------------->| | | | ||||
| | | | | | | ||||
| | 200 OK (JSON Additional Information) (7) | | | | ||||
| |<---------------------------------------------------| | | | ||||
| | -----------------------\ | | | | | ||||
| |-| dnsZones=example.com | | | | | | ||||
| | |----------------------| | | | | | ||||
| | | | | | | ||||
| | TLS connection | | | | | ||||
| |-------------------------------------------------------------------------->| | ||||
| | ---------------------------\ | | | | | ||||
| |-| validate TLS certificate | | | | | | ||||
| | |--------------------------| | | | | | ||||
| | | | | | | ||||
| | NS? example.com (8) | | | | | ||||
| |-------------------------------------------------------------------------->| | ||||
| | | | | | | ||||
| | NS=ns1.example.com, ns2.example.com (9) | | ||||
| |<--------------------------------------------------------------------------| | ||||
| | -------------------------------\ | | | | | ||||
| |-| both DNR ADNs are authorized | | | | | | ||||
| | ----------------------\--------| | | | | | ||||
| |-| finished validation | | | | | | ||||
| | |---------------------| | | | | | ||||
| | | | | | | ||||
| | use network-designated resolver | | | | | ||||
| | for example.com (10) | | | | | ||||
| |----------------------------------------->| | | | | ||||
| | | | | | | ||||
| Figure 1: An Example of Split-Horizon DNS Configuration | Figure 2: Verifying Claims using Public Resolver | |||
| 6. Split DNS Configuration for IKEv2 | 7.1.2. Verification using DNSSEC | |||
| The split-tunnel Virtual Private Network (VPN) configuration allows | The figure below shows the steps performed to verify the local claims | |||
| the endpoint to access resources that reside in the VPN [RFC8598] via | of DNS authority using DNSSEC. | |||
| the tunnel; other traffic not destined to the VPN does not traverse | ||||
| the tunnel. In contrast, a non-split-tunnel VPN configuration causes | Steps 1-2: The DNSSEC-validating client queries the network | |||
| all traffic to traverse the tunnel into the VPN. | encrypted resolver to issue NS queries for the domains in | |||
| dnsZones. The NS lookup for "example.com" will return a signed | ||||
| response containing "ns1.example.com" and "ns2.example.com". The | ||||
| client then performs full DNSSEC validation locally. | ||||
| Step 3: As the DNSSEC validation is successful and the network- | ||||
| provided nameservers are the same as the names in the DNSSEC | ||||
| response, and the network-designated resolver's certificate | ||||
| includes at least one of the names returned in the DNSSEC | ||||
| response, the client has finished validation that the nameservers | ||||
| signaled in [I-D.ietf-add-dnr] and [RFC8801] are owned and managed | ||||
| by the same entity that published the NS records on the Internet. | ||||
| The endpoint will then use that information from | ||||
| [I-D.ietf-add-dnr] and [RFC8801] to resolve names within dnsZones. | ||||
| +---------+ +--------------------+ | ||||
| | client | | Network | | ||||
| | | | encrypted resolver | | ||||
| +---------+ +--------------------+ | ||||
| | | | ||||
| | DNSSEC OK (DO), NS? example.com (1) | | ||||
| |--------------------------------------------------------------->| | ||||
| | | | ||||
| | NS=ns1.example.com,ns2.example.com, Signed Answer (RRSIG) (2) | | ||||
| |<---------------------------------------------------------------| | ||||
| | -----------------------------------\ | | ||||
| |-| DNSKEY+NS matches RRSIG, use NS | | | ||||
| | |----------------------------------| | | ||||
| | -------------------------------\ | | ||||
| |-| both DNR ADNs are authorized | | | ||||
| | |------------------------------| | | ||||
| | ----------------------\ | | ||||
| |-| finished validation | | | ||||
| | |---------------------| | | ||||
| | | | ||||
| | use encrypted network-designated resolver for example.com (3) | | ||||
| |--------------------------------------------------------------->| | ||||
| | | | ||||
| Figure 3: Verifying Claims using DNSSEC | ||||
| 7.2. Split-Horizon Only Subdomain of Zone | ||||
| A subdomain can also be used for all internal DNS names (e.g., the | ||||
| zone internal.example.com exists only on the internal DNS server). | ||||
| For successful validation described in this document the the internal | ||||
| DNS server will need a certificate signed by a CA trusted by the | ||||
| client. | ||||
| For such a name internal.example.com the message flow is similar to | ||||
| Section 7.1 the difference is that queries for hosts not within the | ||||
| subdomain (www.example.com) are sent to the public resolver rather | ||||
| than resolver for internal.example.com. | ||||
| 8. Validation with IKEv2 | ||||
| When the VPN tunnel is IPsec, the encrypted DNS resolver hosted by | When the VPN tunnel is IPsec, the encrypted DNS resolver hosted by | |||
| the VPN service provider can be securely discovered by the endpoint | the VPN service provider can be securely discovered by the endpoint | |||
| using the ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types | using the ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types | |||
| defined in [I-D.ietf-ipsecme-add-ike]. For split-tunnel VPN | defined in [I-D.ietf-ipsecme-add-ike]. | |||
| configurations, the endpoint uses the discovered encrypted DNS server | ||||
| to resolve domain names for which the VPN provider claims authority. | ||||
| For non-split-tunnel VPN configurations, the endpoint uses the | ||||
| discovered encrypted DNS server to resolve both global and private | ||||
| domain names. For split-tunnel VPN configurations, the IKE client | ||||
| can use any one of the mechanisms discussed in Section 4.1 to | ||||
| determine if the VPN service provider is authoritative over the Split | ||||
| Horizon DNS domains. | ||||
| Other VPN tunnel types have similar configuration capabilities, not | Other VPN tunnel types have similar configuration capabilities, not | |||
| detailed here. | detailed here. | |||
| 7. Security Considerations | 9. Security Considerations | |||
| The content of dnsZones may be passed to another (DNS) program for | ||||
| processing. As with any network input, the content SHOULD be | ||||
| considered untrusted and handled accordingly. The client must | ||||
| perform the mechanisms discussed in Section 4.1 to determine if the | ||||
| network-designated encrypted resolvers are authoritative over the | ||||
| domains in dnsZones. If they are not, the client must ignore those | ||||
| dnsZones. | ||||
| This specification does not alter DNSSEC validation behaviour. To | This specification does not alter DNSSEC validation behaviour. To | |||
| ensure compatibility with validating clients, network operators MUST | ensure compatibility with validating clients, network operators MUST | |||
| ensure that names under the split horizon are correctly signed or | ensure that names under the split-horizon are correctly signed or | |||
| place them in an unsigned zone. | place them in an unsigned zone. | |||
| 8. IANA Considerations | If an internal zone name (e.g., internal.example.com) is used with in | |||
| conjunction with this specification and a public certificate is | ||||
| obtained for validation, that internal zone name will exist in | ||||
| Certificate Transparency [RFC9162] logs. It should be noted, | ||||
| however, that this specification does not leak individual host names | ||||
| (e.g., www.internal.example.com) into the Certificate Transparancy | ||||
| logs or to public DNS resolvers. | ||||
| 10. IANA Considerations | ||||
| This document has no IANA actions. | This document has no IANA actions. | |||
| 9. Acknowledgements | 11. Acknowledgements | |||
| Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Paul | Thanks to Mohamed Boucadair, Jim Reid, Tommy Pauly, Paul Vixie, Paul | |||
| Wouters and Vinny Parla for the discussion and comments. | Wouters and Vinny Parla for the discussion and comments. | |||
| 10. References | 12. References | |||
| 12.1. Normative References | ||||
| 10.1. Normative References | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2826] Internet Architecture Board, "IAB Technical Comment on the | ||||
| Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May | ||||
| 2000, <https://www.rfc-editor.org/info/rfc2826>. | ||||
| [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
| Rose, "Protocol Modifications for the DNS Security | Rose, "Protocol Modifications for the DNS Security | |||
| Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, | Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, | |||
| <https://www.rfc-editor.org/info/rfc4035>. | <https://www.rfc-editor.org/info/rfc4035>. | |||
| [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication | [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication | |||
| of Named Entities (DANE) Transport Layer Security (TLS) | of Named Entities (DANE) Transport Layer Security (TLS) | |||
| Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August | Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August | |||
| 2012, <https://www.rfc-editor.org/info/rfc6698>. | 2012, <https://www.rfc-editor.org/info/rfc6698>. | |||
| skipping to change at page 10, line 28 ¶ | skipping to change at page 13, line 34 ¶ | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. | [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. | |||
| Shao, "Discovering Provisioning Domain Names and Data", | Shao, "Discovering Provisioning Domain Names and Data", | |||
| RFC 8801, DOI 10.17487/RFC8801, July 2020, | RFC 8801, DOI 10.17487/RFC8801, July 2020, | |||
| <https://www.rfc-editor.org/info/rfc8801>. | <https://www.rfc-editor.org/info/rfc8801>. | |||
| 10.2. Informative References | 12.2. Informative References | |||
| [I-D.ietf-add-ddr] | ||||
| Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. | ||||
| Jensen, "Discovery of Designated Resolvers", Work in | ||||
| Progress, Internet-Draft, draft-ietf-add-ddr-05, 31 | ||||
| January 2022, <https://www.ietf.org/archive/id/draft-ietf- | ||||
| add-ddr-05.txt>. | ||||
| [I-D.ietf-add-dnr] | [I-D.ietf-add-dnr] | |||
| Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. | Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. | |||
| Jensen, "DHCP and Router Advertisement Options for the | Jensen, "DHCP and Router Advertisement Options for the | |||
| Discovery of Network-designated Resolvers (DNR)", Work in | Discovery of Network-designated Resolvers (DNR)", Work in | |||
| Progress, Internet-Draft, draft-ietf-add-dnr-05, 13 | Progress, Internet-Draft, draft-ietf-add-dnr-06, 22 March | |||
| December 2021, <https://www.ietf.org/archive/id/draft- | 2022, <https://www.ietf.org/archive/id/draft-ietf-add-dnr- | |||
| ietf-add-dnr-05.txt>. | 06.txt>. | |||
| [I-D.ietf-ipsecme-add-ike] | [I-D.ietf-ipsecme-add-ike] | |||
| Boucadair, M., Reddy, T., Wing, D., and V. Smyslov, | Boucadair, M., Reddy, T., Wing, D., and V. Smyslov, | |||
| "Internet Key Exchange Protocol Version 2 (IKEv2) | "Internet Key Exchange Protocol Version 2 (IKEv2) | |||
| Configuration for Encrypted DNS", Work in Progress, | Configuration for Encrypted DNS", Work in Progress, | |||
| Internet-Draft, draft-ietf-ipsecme-add-ike-00, 17 December | Internet-Draft, draft-ietf-ipsecme-add-ike-01, 22 March | |||
| 2021, <https://www.ietf.org/archive/id/draft-ietf-ipsecme- | 2022, <https://www.ietf.org/archive/id/draft-ietf-ipsecme- | |||
| add-ike-00.txt>. | add-ike-01.txt>. | |||
| [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor | ||||
| Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, | ||||
| <https://www.rfc-editor.org/info/rfc2132>. | ||||
| [RFC2937] Smith, C., "The Name Service Search Option for DHCP", | ||||
| RFC 2937, DOI 10.17487/RFC2937, September 2000, | ||||
| <https://www.rfc-editor.org/info/rfc2937>. | ||||
| [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration | ||||
| Protocol (DHCP) Domain Search Option", RFC 3397, | ||||
| DOI 10.17487/RFC3397, November 2002, | ||||
| <https://www.rfc-editor.org/info/rfc3397>. | ||||
| [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic | ||||
| Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, | ||||
| DOI 10.17487/RFC3646, December 2003, | ||||
| <https://www.rfc-editor.org/info/rfc3646>. | ||||
| [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host | ||||
| Configuration Protocol (DHCP) Client Fully Qualified | ||||
| Domain Name (FQDN) Option", RFC 4702, | ||||
| DOI 10.17487/RFC4702, October 2006, | ||||
| <https://www.rfc-editor.org/info/rfc4702>. | ||||
| [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for | ||||
| IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) | ||||
| Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, | ||||
| <https://www.rfc-editor.org/info/rfc4704>. | ||||
| [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local | ||||
| Location Information Server (LIS)", RFC 5986, | ||||
| DOI 10.17487/RFC5986, September 2010, | ||||
| <https://www.rfc-editor.org/info/rfc5986>. | ||||
| [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, | [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, | |||
| "IPv6 Router Advertisement Options for DNS Configuration", | "IPv6 Router Advertisement Options for DNS Configuration", | |||
| RFC 6106, DOI 10.17487/RFC6106, November 2010, | RFC 6106, DOI 10.17487/RFC6106, November 2010, | |||
| <https://www.rfc-editor.org/info/rfc6106>. | <https://www.rfc-editor.org/info/rfc6106>. | |||
| [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved | ||||
| Recursive DNS Server Selection for Multi-Interfaced | ||||
| Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, | ||||
| <https://www.rfc-editor.org/info/rfc6731>. | ||||
| [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain | [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain | |||
| Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, | Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, | |||
| <https://www.rfc-editor.org/info/rfc7556>. | <https://www.rfc-editor.org/info/rfc7556>. | |||
| [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use | [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use | |||
| Domain Name", RFC 7686, DOI 10.17487/RFC7686, October | Domain Name", RFC 7686, DOI 10.17487/RFC7686, October | |||
| 2015, <https://www.rfc-editor.org/info/rfc7686>. | 2015, <https://www.rfc-editor.org/info/rfc7686>. | |||
| [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS | [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS | |||
| Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, | Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, | |||
| skipping to change at page 11, line 31 ¶ | skipping to change at page 15, line 22 ¶ | |||
| [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the | [RFC8598] Pauly, T. and P. Wouters, "Split DNS Configuration for the | |||
| Internet Key Exchange Protocol Version 2 (IKEv2)", | Internet Key Exchange Protocol Version 2 (IKEv2)", | |||
| RFC 8598, DOI 10.17487/RFC8598, May 2019, | RFC 8598, DOI 10.17487/RFC8598, May 2019, | |||
| <https://www.rfc-editor.org/info/rfc8598>. | <https://www.rfc-editor.org/info/rfc8598>. | |||
| [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to | [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to | |||
| a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, | a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, | |||
| <https://www.rfc-editor.org/info/rfc8806>. | <https://www.rfc-editor.org/info/rfc8806>. | |||
| [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate | ||||
| Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, | ||||
| December 2021, <https://www.rfc-editor.org/info/rfc9162>. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Tirumaleswar Reddy | Tirumaleswar Reddy | |||
| Akamai | Akamai | |||
| Embassy Golf Link Business Park | Embassy Golf Link Business Park | |||
| Bangalore 560071 | Bangalore 560071 | |||
| Karnataka | Karnataka | |||
| India | India | |||
| Email: kondtir@gmail.com | Email: kondtir@gmail.com | |||
| End of changes. 49 change blocks. | ||||
| 242 lines changed or deleted | 408 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||