| < draft-ietf-dprive-xfr-over-tls-09.txt | draft-ietf-dprive-xfr-over-tls-12.txt > | |||
|---|---|---|---|---|
| dprive W. Toorop | dprive W. Toorop | |||
| Internet-Draft NLnet Labs | Internet-Draft NLnet Labs | |||
| Updates: 1995, 5936, 7766 (if approved) S. Dickinson | Updates: 1995, 5936, 7766 (if approved) S. Dickinson | |||
| Intended status: Standards Track Sinodun IT | Intended status: Standards Track Sinodun IT | |||
| Expires: October 8, 2021 S. Sahib | Expires: 27 November 2021 S. Sahib | |||
| Brave Software | ||||
| P. Aras | P. Aras | |||
| A. Mankin | A. Mankin | |||
| Salesforce | Salesforce | |||
| April 6, 2021 | 26 May 2021 | |||
| DNS Zone Transfer-over-TLS | DNS Zone Transfer-over-TLS | |||
| draft-ietf-dprive-xfr-over-tls-09 | draft-ietf-dprive-xfr-over-tls-12 | |||
| Abstract | Abstract | |||
| DNS zone transfers are transmitted in clear text, which gives | DNS zone transfers are transmitted in clear text, which gives | |||
| attackers the opportunity to collect the content of a zone by | attackers the opportunity to collect the content of a zone by | |||
| eavesdropping on network connections. The DNS Transaction Signature | eavesdropping on network connections. The DNS Transaction Signature | |||
| (TSIG) mechanism is specified to restrict direct zone transfer to | (TSIG) mechanism is specified to restrict direct zone transfer to | |||
| authorized clients only, but it does not add confidentiality. This | authorized clients only, but it does not add confidentiality. This | |||
| document specifies the use of TLS, rather than clear text, to prevent | document specifies the use of TLS, rather than clear text, to prevent | |||
| zone content collection via passive monitoring of zone transfers: | zone content collection via passive monitoring of zone transfers: | |||
| XFR-over-TLS (XoT). Additionally, this specification updates | XFR-over-TLS (XoT). Additionally, this specification updates RFC1995 | |||
| RFC1995, RFC5936 and RFC7766. | and RFC5936 with respect to efficient use of TCP connections, and | |||
| RFC7766 with respect to the recommended number of connections between | ||||
| a client and server for each transport. | ||||
| 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 http://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 October 8, 2021. | This Internet-Draft will expire on 27 November 2021. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 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 | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
| publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
| carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
| to this document. Code Components extracted from this document must | extracted from this document must include Simplified BSD License text | |||
| include Simplified BSD License text as described in Section 4.e of | as described in Section 4.e of the Trust Legal Provisions and are | |||
| the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Simplified BSD License. | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Document work via GitHub . . . . . . . . . . . . . . . . . . 5 | 2. Document work via GitHub . . . . . . . . . . . . . . . . . . 6 | |||
| 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 5. Design Considerations for XoT . . . . . . . . . . . . . . . . 6 | 5. Design Considerations for XoT . . . . . . . . . . . . . . . . 7 | |||
| 6. Connection and Data Flows in Existing XFR Mechanisms . . . . 7 | 6. Connection and Data Flows in Existing XFR Mechanisms . . . . 8 | |||
| 6.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 8 | 6.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 6.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 9 | 6.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11 | 6.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11 | |||
| 6.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11 | 6.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 6.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 6.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 7. Updates to existing specifications . . . . . . . . . . . . . 11 | 7. Updates to existing specifications . . . . . . . . . . . . . 12 | |||
| 7.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 13 | 7.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 13 | |||
| 7.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 13 | 7.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 14 | |||
| 7.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 13 | 7.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 14 | |||
| 7.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 13 | 7.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 14 | |||
| 7.3.2. AXFRs and IXFRs on the same connection . . . . . . . 14 | 7.3.2. AXFRs and IXFRs on the same connection . . . . . . . 15 | |||
| 7.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 14 | 7.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 7.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 15 | 7.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 15 | |||
| 7.3.5. Backwards compatibility . . . . . . . . . . . . . . . 15 | 7.3.5. Backwards compatibility . . . . . . . . . . . . . . . 16 | |||
| 7.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 15 | 7.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 16 | |||
| 8. XoT specification . . . . . . . . . . . . . . . . . . . . . . 17 | 8. XoT specification . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 8.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 17 | 8.1. Connection establishment . . . . . . . . . . . . . . . . 17 | |||
| 8.2. Port selection . . . . . . . . . . . . . . . . . . . . . 17 | 8.2. TLS versions . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 8.3. High level XoT descriptions . . . . . . . . . . . . . . . 17 | 8.3. Port selection . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 8.4. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 19 | 8.4. High level XoT descriptions . . . . . . . . . . . . . . . 18 | |||
| 8.5. XoT connections . . . . . . . . . . . . . . . . . . . . . 20 | 8.5. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 8.6. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 20 | 8.6. XoT connections . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 8.7. Response RCODES . . . . . . . . . . . . . . . . . . . . . 21 | 8.7. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 8.8. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 21 | 8.8. Response RCODES . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 8.8.1. Padding AXoT responses . . . . . . . . . . . . . . . 21 | 8.9. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 8.9. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 22 | 8.9.1. Padding AXoT responses . . . . . . . . . . . . . . . 22 | |||
| 8.9.1. Condensation of responses . . . . . . . . . . . . . . 22 | ||||
| 8.9.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 22 | ||||
| 8.9.3. Padding of IXoT responses . . . . . . . . . . . . . . 23 | ||||
| 8.10. Name compression and maximum payload sizes . . . . . . . 23 | ||||
| 9. Multi-primary Configurations . . . . . . . . . . . . . . . . 23 | 8.10. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 10. Authentication mechanisms . . . . . . . . . . . . . . . . . . 24 | 8.10.1. Condensation of responses . . . . . . . . . . . . . 23 | |||
| 10.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 8.10.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 24 | |||
| 10.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 8.10.3. Padding of IXoT responses . . . . . . . . . . . . . 24 | |||
| 10.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 8.11. Name compression and maximum payload sizes . . . . . . . 24 | |||
| 10.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . 25 | 9. Multi-primary Configurations . . . . . . . . . . . . . . . . 25 | |||
| 10.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 26 | 10. Authentication mechanisms . . . . . . . . . . . . . . . . . . 26 | |||
| 10.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 26 | 10.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 10.4. IP Based ACL on the Primary . . . . . . . . . . . . . . 26 | 10.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 10.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 10.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 11. XoT authentication . . . . . . . . . . . . . . . . . . . . . 27 | 10.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . 27 | |||
| 12. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 28 | 10.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 13. Implementation Considerations . . . . . . . . . . . . . . . . 29 | 10.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 27 | |||
| 14. Operational Considerations . . . . . . . . . . . . . . . . . 29 | 10.4. IP Based ACL on the Primary . . . . . . . . . . . . . . 28 | |||
| 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 | 10.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 16. Implementation Status . . . . . . . . . . . . . . . . . . . . 29 | 11. XoT authentication . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 17. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | 12. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 29 | |||
| 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 | 13. Implementation Considerations . . . . . . . . . . . . . . . . 30 | |||
| 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 | 14. Operational Considerations . . . . . . . . . . . . . . . . . 30 | |||
| 20. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | |||
| 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 16. Implementation Status . . . . . . . . . . . . . . . . . . . . 31 | |||
| 21.1. Normative References . . . . . . . . . . . . . . . . . . 33 | 17. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | |||
| 21.2. Informative References . . . . . . . . . . . . . . . . . 35 | 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| 21.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| Appendix A. XoT server connection handling . . . . . . . . . . . 36 | 20. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| A.1. Only listen on TLS on a specific IP address . . . . . . . 37 | 21. Normative References . . . . . . . . . . . . . . . . . . . . 35 | |||
| A.2. Client specific TLS acceptance . . . . . . . . . . . . . 37 | 22. Informative References . . . . . . . . . . . . . . . . . . . 37 | |||
| A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 37 | Appendix A. XoT server connection handling . . . . . . . . . . . 39 | |||
| A.4. TLS specific response policies . . . . . . . . . . . . . 37 | A.1. Only listen on TLS on a specific IP address . . . . . . . 39 | |||
| A.4.1. SNI based response policies . . . . . . . . . . . . . 38 | A.2. Client specific TLS acceptance . . . . . . . . . . . . . 39 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 | A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 40 | |||
| A.4. Transport specific response policies . . . . . . . . . . 40 | ||||
| A.4.1. SNI based response policies . . . . . . . . . . . . . 41 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 | ||||
| 1. Introduction | 1. Introduction | |||
| DNS has a number of privacy vulnerabilities, as discussed in detail | DNS has a number of privacy vulnerabilities, as discussed in detail | |||
| in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver | in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver | |||
| query privacy has received the most attention to date, with standards | query privacy has received the most attention to date, with standards | |||
| track documents for both DNS-over-TLS (DoT) [RFC7858] and DNS-over- | track documents for both DNS-over-TLS (DoT) [RFC7858] and DNS-over- | |||
| HTTPS (DoH) [RFC8484], and a proposal for DNS-over-QUIC | HTTPS (DoH) [RFC8484], and a proposal for DNS-over-QUIC | |||
| [I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy | [I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy | |||
| requirements for exchanges between recursive resolvers and | requirements for exchanges between recursive resolvers and | |||
| authoritative servers [I-D.ietf-dprive-phase2-requirements] and some | authoritative servers [I-D.ietf-dprive-phase2-requirements] and some | |||
| suggestions for how signaling of DoT support by authoritatives might | suggestions for how signaling of DoT support by authoritative | |||
| work. However there is currently no RFC that specifically defines | nameservers might work. However, there is currently no RFC that | |||
| recursive to authoritative DNS-over-TLS (ADoT). | specifically defines recursive to authoritative DNS-over-TLS (ADoT). | |||
| [I-D.ietf-dprive-rfc7626-bis] established that stub client DNS query | [I-D.ietf-dprive-rfc7626-bis] established that stub client DNS query | |||
| transactions are not public and needed protection, but on zone | transactions are not public and needed protection, but on zone | |||
| transfer [RFC1995] [RFC5936] it says only: | transfer [RFC1995] [RFC5936] it says only: | |||
| "Privacy risks for the holder of a zone (the risk that someone | "Privacy risks for the holder of a zone (the risk that someone | |||
| gets the data) are discussed in [RFC5936] and [RFC5155]." | gets the data) are discussed in [RFC5936] and [RFC5155]." | |||
| In what way is exposing the full contents of a zone a privacy risk? | In what way is exposing the full contents of a zone a privacy risk? | |||
| The contents of the zone could include information such as names of | The contents of the zone could include information such as names of | |||
| persons used in names of hosts. Best practice is not to use personal | persons used in names of hosts. Best practice is not to use personal | |||
| information for domain names, but many such domain names exist. The | information for domain names, but many such domain names exist. The | |||
| contents of the zone could also include references to locations that | contents of the zone could also include references to locations that | |||
| allow inference about location information of the individuals | allow inference about location information of the individuals | |||
| associated with the zone's organization. It could also include | associated with the zone's organization. It could also include | |||
| references to other organizations. Examples of this could be: | references to other organizations. Examples of this could be: | |||
| o Person-laptop.example.org | * Person-laptop.example.org | |||
| o MX-for-Location.example.org | * MX-for-Location.example.org | |||
| o Service-tenant-from-another-org.example.org | * Service-tenant-from-another-org.example.org | |||
| Additionally, the full zone contents expose all the IP addresses of | Additionally, the full zone contents expose all the IP addresses of | |||
| endpoints held in the DNS records which can make reconnaissance | endpoints held in the DNS records which can make reconnaissance and | |||
| trivial, particularly for IPv6 addresses. There may also be | attack targeting easier, particularly for IPv6 addresses or private | |||
| regulatory, policy or other reasons why the zone contents in full | networks. There may also be regulatory, policy or other reasons why | |||
| must be treated as private. | the zone contents in full must be treated as private. | |||
| Neither of the RFCs mentioned in [I-D.ietf-dprive-rfc7626-bis] | Neither of the RFCs mentioned in [I-D.ietf-dprive-rfc7626-bis] | |||
| contemplates the risk that someone gets the data through | contemplates the risk that someone gets the data through | |||
| eavesdropping on network connections, only via enumeration or | eavesdropping on network connections, only via enumeration or | |||
| unauthorized transfer as described in the following paragraphs. | unauthorized transfer as described in the following paragraphs. | |||
| Zone enumeration is trivially possible for DNSSEC zones which use | Zone enumeration is trivially possible for DNSSEC zones which use | |||
| NSEC; i.e. queries for the authenticated denial of existences | NSEC; i.e. queries for the authenticated denial of existence records | |||
| records allow a client to walk through the entire zone contents. | allow a client to walk through the entire zone contents. [RFC5155] | |||
| [RFC5155] specifies NSEC3, a mechanism to provide measures against | specifies NSEC3, a mechanism to provide measures against zone | |||
| zone enumeration for DNSSEC signed zones (a goal was to make it as | enumeration for DNSSEC signed zones (a goal was to make it as hard to | |||
| hard to enumerate an DNSSEC signed zone as an unsigned zone). Whilst | enumerate a DNSSEC signed zone as an unsigned zone). Whilst this is | |||
| this is widely used, zone walking is now possible with NSEC3 due to | widely used, it has been demonstrated that zone walking is possible | |||
| crypto-breaking advances. This has prompted further work on an | for precomputed NSEC3 using attacks such as those described in | |||
| alternative mechanism for DNSSEC authenticated denial of existence - | [NSEC3-attacks]. This prompted further work on an alternative | |||
| NSEC5 [I-D.vcelak-nsec5] - however questions remain over the | mechanism for DNSSEC authenticated denial of existence - NSEC5 | |||
| practicality of this mechanism. | [I-D.vcelak-nsec5] - however questions remain over the practicality | |||
| of this mechanism. | ||||
| [RFC5155] does not address data obtained outside zone enumeration | [RFC5155] does not address data obtained outside zone enumeration | |||
| (nor does [I-D.vcelak-nsec5]). Preventing eavesdropping of zone | (nor does [I-D.vcelak-nsec5]). Preventing eavesdropping of zone | |||
| transfers (this draft) is orthogonal to preventing zone enumeration, | transfers (this document) is orthogonal to preventing zone | |||
| though they aim to protect the same information. | enumeration, though they aim to protect the same information. | |||
| [RFC5936] specifies using TSIG [RFC8945] for authorization of the | [RFC5936] specifies using TSIG [RFC8945] for authorization of the | |||
| clients of a zone transfer and for data integrity, but does not | clients of a zone transfer and for data integrity, but does not | |||
| express any need for confidentiality, and TSIG does not offer | express any need for confidentiality, and TSIG does not offer | |||
| encryption. | encryption. | |||
| Section 8 of the NIST guide on 'Secure Domain Name System (DNS) | Section 8 of the NIST guide on 'Secure Domain Name System (DNS) | |||
| Deployment' [nist-guide] discusses restricting access for zone | Deployment' [nist-guide] discusses restricting access for zone | |||
| transfers using ACLs and TSIG in more detail. It also discusses the | transfers using ACLs and TSIG in more detail. It also discusses the | |||
| possibility that specific deployments might choose to use a lower | possibility that specific deployments might choose to use a lower | |||
| level network layer to protect zone transfers, e.g., IPSec. | level network layer to protect zone transfers, e.g., IPSec. | |||
| It is noted that in all the common open source implementations such | It is noted that in all the common open source implementations such | |||
| ACLs are applied on a per query basis. Since requests typically | ACLs are applied on a per query basis (at the time of writing). | |||
| occur on TCP connections authoritatives must cater for accepting any | Since requests typically occur on TCP connections authoritatives must | |||
| TCP connection and then handling the authentication of each XFR | therefore accept any TCP connection and then handling the | |||
| request individually. | authentication of each zone transfer (XFR) request individually. | |||
| Because both AXFR and IXFR zone transfers are typically carried out | Because both AXFR (authoritative transfer) and IXFR (incremental | |||
| over TCP from authoritative DNS protocol implementations, encrypting | transfer) are typically carried out over TCP from authoritative DNS | |||
| zone transfers using TLS, based closely on DoT [RFC7858], seems like | protocol implementations, encrypting zone transfers using TLS | |||
| a simple step forward. This document specifies how to use TLS as a | [RFC8499], based closely on DoT [RFC7858], seems like a simple step | |||
| forward. This document specifies how to use TLS (1.3 or later) as a | ||||
| transport to prevent zone collection from zone transfers. | transport to prevent zone collection from zone transfers. | |||
| This document also updates the previous specifications for zone | ||||
| transfers to clarify and extend them, mainly with respect to TCP | ||||
| usage: | ||||
| * RFC1995 (IXFR) and RFC5936 (AXFR) are both updated to add further | ||||
| specification on efficient use of TCP connections | ||||
| * Section 6.2.2 of RFC7766 (DNS Transport over TCP - Implementation | ||||
| Requirements) is updated with a new recommendation about the | ||||
| number of connections between a client and server for each | ||||
| transport. | ||||
| 2. Document work via GitHub | 2. Document work via GitHub | |||
| [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository | [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository | |||
| for this document is at <https://github.com/hanzhang0116/hzpa-dprive- | for this document is at https://github.com/hanzhang0116/hzpa-dprive- | |||
| xfr-over-tls>. Proposed text and editorial changes are very much | xfr-over-tls (https://github.com/hanzhang0116/hzpa-dprive-xfr-over- | |||
| welcomed there, but any functional changes should always first be | tls). Proposed text and editorial changes are very much welcomed | |||
| discussed on the IETF DPRIVE WG (dns-privacy) mailing list. | there, but any functional changes should always first be discussed on | |||
| the IETF DPRIVE WG (dns-privacy) mailing list. | ||||
| 3. Terminology | 3. 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] and [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. | |||
| Privacy terminology is as described in Section 3 of [RFC6973]. | Privacy terminology is as described in Section 3 of [RFC6973]. | |||
| DNS terminology is as described in [RFC8499]. Note that as in | DNS terminology is as described in [RFC8499]. Note that as in | |||
| [RFC8499], the terms 'primary' and 'secondary' are used for two | [RFC8499], the terms 'primary' and 'secondary' are used for two | |||
| servers engaged in zone transfers. | servers engaged in zone transfers. | |||
| DoT: DNS-over-TLS as specified in [RFC7858] | DoT: DNS-over-TLS as specified in [RFC7858] | |||
| XFR-over-TCP: Used to mean both IXFR-over-TCP [RFC1995] and AXFR- | XFR-over-TCP: Used to mean both IXFR-over-TCP [RFC1995] and AXFR- | |||
| over-TCP [RFC5936]. | over-TCP [RFC5936]. | |||
| XoT: Generic XFR-over-TLS mechanisms as specified in this document | XoT: XFR-over-TLS mechanisms as specified in this document which | |||
| apply to both AXFR-over-TLS and IXFR-over-TLS | ||||
| AXoT: AXFR-over-TLS | AXoT: AXFR-over-TLS | |||
| IXoT: IXFR over-TLS | IXoT: IXFR over-TLS | |||
| 4. Threat Model | 4. Threat Model | |||
| The threat model considered here is one where the current contents | The threat model considered here is one where the current contents | |||
| and size of the zone are considered sensitive and should be protected | and size of the zone are considered sensitive and should be protected | |||
| during transfer. | during transfer. | |||
| The threat model does not, however, consider the existence of a zone, | The threat model does not, however, consider the existence of a zone, | |||
| the act of zone transfer between two entities, nor the identities of | the act of zone transfer between two entities, nor the identities of | |||
| the nameservers hosting a zone (including both those acting as hidden | the nameservers hosting a zone (including both those acting as hidden | |||
| primaries/secondaries or directly serving the zone) as sensitive | primaries/secondaries or directly serving the zone) as sensitive | |||
| information. The proposed mechanisms does not attempt to obscure | information. The proposed mechanism does not attempt to obscure such | |||
| such information. The reasons for this include: | information. The reasons for this include: | |||
| o much of this information can be obtained by various methods | * much of this information can be obtained by various methods, | |||
| including active scanning of the DNS | including active scanning of the DNS | |||
| o an attacker who can monitor network traffic can relatively easily | * an attacker who can monitor network traffic can relatively easily | |||
| infer relations between nameservers simply from traffic patterns, | infer relations between nameservers simply from traffic patterns, | |||
| even when some or all of the traffic is encrypted | even when some or all of the traffic is encrypted (in terms of | |||
| current deployments) | ||||
| The model does not consider attacks on the mechanisms that trigger a | ||||
| zone transfer, e.g., NOTIFY messages. | ||||
| It is noted that simply using XoT will indicate a desire by the zone | It is noted that simply using XoT will indicate a desire by the zone | |||
| owner that the contents of the zone remain confidential and so could | owner that the contents of the zone remain confidential and so could | |||
| be subject to blocking (e.g., via blocking of port 853) if an | be subject to blocking (e.g., via blocking of port 853) if an | |||
| attacker had such capabilities. However this threat is likely true | attacker had such capabilities. However this threat is likely true | |||
| of any such mechanism that attempts to encrypt data passed between | of any such mechanism that attempts to encrypt data passed between | |||
| nameservers, e.g., IPsec. | nameservers, e.g., IPsec. | |||
| 5. Design Considerations for XoT | 5. Design Considerations for XoT | |||
| o Confidentiality. Clearly using an encrypted transport for zone | The following principles were considered in the design for XoT: | |||
| * Confidentiality. Clearly using an encrypted transport for zone | ||||
| transfers will defeat zone content leakage that can occur via | transfers will defeat zone content leakage that can occur via | |||
| passive surveillance. | passive surveillance. | |||
| o Authentication. Use of single or mutual TLS (mTLS) authentication | * Authentication. Use of single or mutual TLS (mTLS) authentication | |||
| (in combination with ACLs) can complement and potentially be an | (in combination with access control lists (ACLs)) can complement | |||
| alternative to TSIG. | and potentially be an alternative to TSIG. | |||
| o Performance. Existing AXFR and IXFR mechanisms have the burden of | * Performance. | |||
| backwards compatibility with older implementations based on the | ||||
| original specifications in [RFC1034] and [RFC1035]. For example, | ||||
| some older AXFR servers don't support using a TCP connection for | ||||
| multiple AXFR sessions or XFRs of different zones because they | ||||
| have not been updated to follow the guidance in [RFC5936]. Any | ||||
| implementation of XoT would obviously be required to implement | ||||
| optimized and interoperable transfers as described in [RFC5936], | ||||
| e.g., transfer of multiple zones over one connection. | ||||
| o Performance. Current usage of TCP for IXFR is sub-optimal in some | - Existing AXFR and IXFR mechanisms have the burden of backwards | |||
| cases i.e. connections are frequently closed after a single IXFR. | compatibility with older implementations based on the original | |||
| specifications in [RFC1034] and [RFC1035]. For example, some | ||||
| older AXFR servers don't support using a TCP connection for | ||||
| multiple AXFR sessions or XFRs of different zones because they | ||||
| have not been updated to follow the guidance in [RFC5936]. Any | ||||
| implementation of XoT would obviously be required to implement | ||||
| optimized and interoperable transfers as described in | ||||
| [RFC5936], e.g., transfer of multiple zones over one | ||||
| connection. | ||||
| - Current usage of TCP for IXFR is sub-optimal in some cases i.e. | ||||
| connections are frequently closed after a single IXFR. | ||||
| 6. Connection and Data Flows in Existing XFR Mechanisms | 6. Connection and Data Flows in Existing XFR Mechanisms | |||
| The original specification for zone transfers in [RFC1034] and | The original specification for zone transfers in [RFC1034] and | |||
| [RFC1035] was based on a polling mechanism: a secondary performed a | [RFC1035] was based on a polling mechanism: a secondary performed a | |||
| periodic SOA query (based on the refresh timer) to determine if an | periodic query for the SOA (start of zone authority) record (based on | |||
| AXFR was required. | the refresh timer) to determine if an AXFR was required. | |||
| [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY | [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY | |||
| respectively, to provide for prompt propagation of zone updates. | respectively, to provide for prompt propagation of zone updates. | |||
| This has largely replaced AXFR where possible, particularly for | This has largely replaced AXFR where possible, particularly for | |||
| dynamically updated zones. | dynamically updated zones. | |||
| [RFC5936] subsequently redefined the specification of AXFR to improve | [RFC5936] subsequently redefined the specification of AXFR to improve | |||
| performance and interoperability. | performance and interoperability. | |||
| In this document we use the term "XFR mechanism" to describe the | In this document we use the term "XFR mechanism" to describe the | |||
| entire set of message exchanges between a secondary and a primary | entire set of message exchanges between a secondary and a primary | |||
| that concludes in a successful AXFR or IXFR request/response. This | that concludes in a successful AXFR or IXFR request/response. This | |||
| set may or may not include | set may or may not include | |||
| o NOTIFY messages | * NOTIFY messages | |||
| o SOA queries | * SOA queries | |||
| o Fallback from IXFR to AXFR | * Fallback from IXFR to AXFR | |||
| o Fallback from IXFR-over-UDP to IXFR-over-TCP | * Fallback from IXFR-over-UDP to IXFR-over-TCP | |||
| The term is used to encompasses the range of permutations that are | The term is used to encompass the range of permutations that are | |||
| possible and is useful to distinguish the 'XFR mechanism' from a | possible and is useful to distinguish the 'XFR mechanism' from a | |||
| single XFR request/response exchange. | single XFR request/response exchange. | |||
| 6.1. AXFR Mechanism | 6.1. AXFR Mechanism | |||
| The figure below provides an outline of an AXFR mechanism including | The figure below provides an outline of an AXFR mechanism including | |||
| NOTIFYs. | NOTIFYs. | |||
| Secondary Primary | Secondary Primary | |||
| | NOTIFY | | | NOTIFY | | |||
| | <-------------------------------- | UDP | | <-------------------------------- | UDP | |||
| | --------------------------------> | | | --------------------------------> | | |||
| | NOTIFY Response | | | NOTIFY Response | | |||
| | | | | | | |||
| | | | | | | |||
| | SOA Request | | | SOA Request | | |||
| | --------------------------------> | UDP (or part of | | --------------------------------> | UDP (or part of | |||
| | <-------------------------------- | a TCP session) | | <-------------------------------- | a TCP session) | |||
| | SOA Response | | | SOA Response | | |||
| | | | | | | |||
| | | | | | | |||
| | | | | | | |||
| | AXFR Request | --- | | AXFR Request | --- | |||
| | --------------------------------> | | | | --------------------------------> | | | |||
| | <-------------------------------- | | | | <-------------------------------- | | | |||
| | AXFR Response 1 | | | | AXFR Response 1 | | | |||
| | (Zone data) | | | | (Zone data) | | | |||
| | | | | | | | | |||
| | <-------------------------------- | | TCP | | <-------------------------------- | | TCP | |||
| | AXFR Response 2 | | Session | | AXFR Response 2 | | Session | |||
| | (Zone data) | | | | (Zone data) | | | |||
| | | | | | | | | |||
| | <-------------------------------- | | | | <-------------------------------- | | | |||
| | AXFR Response 3 | | | | AXFR Response 3 | | | |||
| | (Zone data) | --- | | (Zone data) | --- | |||
| | | | | | | |||
| Figure 1. AXFR Mechanism | Figure 1. AXFR Mechanism | |||
| 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) | 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) | |||
| from the primary to the secondary. A secondary may also initiate | from the primary to the secondary. A secondary may also initiate | |||
| an AXFR based on a refresh timer or scheduled/triggered zone | an AXFR based on a refresh timer or scheduled/triggered zone | |||
| maintenance. | maintenance. | |||
| 2. The secondary will normally (but not always) make a SOA query to | 2. The secondary will normally (but not always) make a SOA query to | |||
| the primary to obtain the serial number of the zone held by the | the primary to obtain the serial number of the zone held by the | |||
| primary. | primary. | |||
| 3. If the primary serial is higher than the secondaries serial | 3. If the primary serial is higher than the secondary's serial | |||
| (using Serial Number Arithmetic [RFC1982]), the secondary makes | (using Serial Number Arithmetic [RFC1982]), the secondary makes | |||
| an AXFR request (over TCP) to the primary after which the AXFR | an AXFR request (over TCP) to the primary after which the AXFR | |||
| data flows in one or more AXFR responses on the TCP connection. | data flows in one or more AXFR responses on the TCP connection. | |||
| [RFC5936] defines this specific step as an 'AXFR session' i.e. as | [RFC5936] defines this specific step as an 'AXFR session' i.e. as | |||
| an AXFR query message and the sequence of AXFR response messages | an AXFR query message and the sequence of AXFR response messages | |||
| returned for it. | returned for it. | |||
| [RFC5936] re-specified AXFR providing additional guidance beyond that | [RFC5936] re-specified AXFR providing additional guidance beyond that | |||
| provided in [RFC1034] and [RFC1035] and importantly specified that | provided in [RFC1034] and [RFC1035] and importantly specified that | |||
| AXFR must use TCP as the transport protocol. | AXFR must use TCP as the transport protocol. | |||
| skipping to change at page 10, line 5 ¶ | skipping to change at page 10, line 24 ¶ | |||
| example, it outlines that the SOA query can also happen on this | example, it outlines that the SOA query can also happen on this | |||
| connection. However, this can cause interoperability problems with | connection. However, this can cause interoperability problems with | |||
| older implementations that support only the trivial case of one AXFR | older implementations that support only the trivial case of one AXFR | |||
| per connection. | per connection. | |||
| 6.2. IXFR Mechanism | 6.2. IXFR Mechanism | |||
| The figure below provides an outline of the IXFR mechanism including | The figure below provides an outline of the IXFR mechanism including | |||
| NOTIFYs. | NOTIFYs. | |||
| Secondary Primary | Secondary Primary | |||
| | NOTIFY | | | NOTIFY | | |||
| | <-------------------------------- | UDP | | <-------------------------------- | UDP | |||
| | --------------------------------> | | | --------------------------------> | | |||
| | NOTIFY Response | | | NOTIFY Response | | |||
| | | | | | | |||
| | | | | | | |||
| | SOA Request | | | SOA Request | | |||
| | --------------------------------> | UDP or TCP | | --------------------------------> | UDP or TCP | |||
| | <-------------------------------- | | | <-------------------------------- | | |||
| | SOA Response | | | SOA Response | | |||
| | | | | | | |||
| | | | | | | |||
| | | | | | | |||
| | IXFR Request | | | IXFR Request | | |||
| | --------------------------------> | UDP or TCP | | --------------------------------> | UDP or TCP | |||
| | <-------------------------------- | | | <-------------------------------- | | |||
| | IXFR Response | | | IXFR Response | | |||
| | (Zone data) | | | (Zone data) | | |||
| | | | | | | |||
| | | --- | | | --- | |||
| | IXFR Request | | | | IXFR Request | | | |||
| | --------------------------------> | | Retry over | | --------------------------------> | | Retry over | |||
| | <-------------------------------- | | TCP if | | <-------------------------------- | | TCP if | |||
| | IXFR Response | | required | | IXFR Response | | required | |||
| | (Zone data) | --- | | (Zone data) | --- | |||
| Figure 2. IXFR Mechanism | Figure 2. IXFR Mechanism | |||
| 1. An IXFR is normally (but not always) preceded by a NOTIFY (over | 1. An IXFR is normally (but not always) preceded by a NOTIFY (over | |||
| UDP) from the primary to the secondary. A secondary may also | UDP) from the primary to the secondary. A secondary may also | |||
| initiate an IXFR based on a refresh timer or scheduled/triggered | initiate an IXFR based on a refresh timer or scheduled/triggered | |||
| zone maintenance. | zone maintenance. | |||
| 2. The secondary will normally (but not always) make a SOA query to | 2. The secondary will normally (but not always) make a SOA query to | |||
| the primary to obtain the serial number of the zone held by the | the primary to obtain the serial number of the zone held by the | |||
| primary. | primary. | |||
| 3. If the primary serial is higher than the secondaries serial | 3. If the primary serial is higher than the secondaries serial | |||
| (using Serial Number Arithmetic [RFC1982]), the secondary makes | (using Serial Number Arithmetic [RFC1982]), the secondary makes | |||
| an IXFR request to the primary after which the primary sends an | an IXFR request to the primary after which the primary sends an | |||
| IXFR response. | IXFR response. | |||
| [RFC1995] specifies that Incremental Transfer may use UDP if the | [RFC1995] specifies that Incremental Transfer may use UDP if the | |||
| entire IXFR response can be contained in a single DNS packet, | entire IXFR response can be contained in a single DNS packet, | |||
| otherwise, TCP is used. In fact it says: | otherwise, TCP is used. In fact it says: | |||
| "Thus, a client should first make an IXFR query using UDP." | "Thus, a client should first make an IXFR query using UDP." | |||
| So there may be a fourth step above where the client falls back to | So there may be a fourth step above where the client falls back to | |||
| IXFR-over-TCP. There may also be a fourth step where the secondary | IXFR-over-TCP. There may also be a additional step where the | |||
| must fall back to AXFR because, e.g., the primary does not support | secondary must fall back to AXFR because, e.g., the primary does not | |||
| IXFR. | support IXFR. | |||
| However it is noted that most widely used open source authoritative | However it is noted that most widely used open source authoritative | |||
| nameserver implementations (including both [BIND] and [NSD]) do IXFR | nameserver implementations (including both [BIND] and [NSD]) do IXFR | |||
| using TCP by default in their latest releases. For BIND TCP | using TCP by default in their latest releases. For BIND, TCP | |||
| connections are sometimes used for SOA queries but in general they | connections are sometimes used for SOA queries but in general they | |||
| are not used persistently and close after an IXFR is completed. | are not used persistently and close after an IXFR is completed. | |||
| 6.3. Data Leakage of NOTIFY and SOA Message Exchanges | 6.3. Data Leakage of NOTIFY and SOA Message Exchanges | |||
| This section attempts to presents a rationale for considering | This section presents a rationale for considering encrypting the | |||
| encrypting the other messages in the XFR mechanism. | other messages in the XFR mechanism. | |||
| Since the SOA of the published zone can be trivially discovered by | Since the SOA of the published zone can be trivially discovered by | |||
| simply querying the publicly available authoritative servers leakage | simply querying the publicly available authoritative servers, leakage | |||
| of this RR is not discussed in the following sections. | of this resource record (RR) via such a direct query is not discussed | |||
| in the following sections. | ||||
| 6.3.1. NOTIFY | 6.3.1. NOTIFY | |||
| Unencrypted NOTIFY messages identify configured secondaries on the | Unencrypted NOTIFY messages identify configured secondaries on the | |||
| primary. | primary. | |||
| [RFC1996] also states: | [RFC1996] also states: | |||
| "If ANCOUNT>0, then the answer section represents an | "If ANCOUNT>0, then the answer section represents an | |||
| unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE). | unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE). | |||
| But since the only supported QTYPE for NOTIFY is SOA, this does not | But since the only QTYPE for NOTIFY defined at the time of this | |||
| pose a potential leak. | writing is SOA, this does not pose a potential leak. | |||
| 6.3.2. SOA | 6.3.2. SOA | |||
| For hidden primaries or secondaries the SOA response leaks only the | For hidden XFR servers (either primaries or secondaries), an SOA | |||
| degree of SOA serial number lag of any downstream secondary. | response directly from that server only additionally leaks the degree | |||
| of SOA serial number lag of any downstream secondary of that server. | ||||
| 7. Updates to existing specifications | 7. Updates to existing specifications | |||
| For convenience, the term 'XFR-over-TCP' is used in this document to | For convenience, the term 'XFR-over-TCP' is used in this document to | |||
| mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements | mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements | |||
| that use that term update both [RFC1995] and [RFC5936], and | that use that term update both [RFC1995] and [RFC5936], and | |||
| implicitly also apply to XoT. Differences in behavior specific to | implicitly also apply to XoT. Differences in behavior specific to | |||
| XoT are discussed in Section 8. | XoT are discussed in Section 8. | |||
| Both [RFC1995] and [RFC5936] were published sometime before TCP was | Both [RFC1995] and [RFC5936] were published sometime before TCP was | |||
| considered a first class transport for DNS. [RFC1995], in fact, says | considered a first class transport for DNS. [RFC1995], in fact, says | |||
| nothing with respect to optimizing IXFRs over TCP or re-using already | nothing with respect to optimizing IXFRs over TCP or re-using already | |||
| open TCP connections to perform IXFRs or other queries. Therefore, | open TCP connections to perform IXFRs or other queries. Therefore, | |||
| there arguably is an implicit assumption that a TCP connection is | there arguably is an implicit assumption that a TCP connection is | |||
| used for one and only one IXFR request. Indeed, many major open | used for one and only one IXFR request. Indeed, many major open | |||
| source implementations currently take this approach. And whilst | source implementations take this approach (at the time of this | |||
| [RFC5936] gives guidance on connection re-use for AXFR, it pre-dates | writing). And whilst [RFC5936] gives guidance on connection re-use | |||
| more recent specifications describing persistent TCP connections, | for AXFR, it pre-dates more recent specifications describing | |||
| e.g., [RFC7766], [RFC7828] and AXFR implementations again often make | persistent TCP connections (e.g., [RFC7766], [RFC7828]), and AXFR | |||
| less than optimal use of open connections. | implementations again often make less than optimal use of open | |||
| connections. | ||||
| Given this, new implementations of XoT will clearly benefit from | Given this, new implementations of XoT will clearly benefit from | |||
| specific guidance on TCP/TLS connection usage for XFR because this | specific guidance on TCP/TLS connection usage for XFR, because this | |||
| will: | will: | |||
| o result in more consistent XoT implementations with better | * result in more consistent XoT implementations with better | |||
| interoperability | interoperability | |||
| o remove any need for XoT implementations to support legacy behavior | * remove any need for XoT implementations to support legacy behavior | |||
| that XFR-over-TCP implementations have historically often | for XoT connections that XFR-over-TCP implementations have | |||
| supported | historically often supported | |||
| Therefore this document updates both the previous specifications for | Therefore this document updates both the previous specifications for | |||
| XFR-over-TCP to clarify that | XFR-over-TCP ([RFC1995] and [RFC5936]) to clarify that | |||
| * Implementations MUST use [RFC7766] (DNS Transport over TCP - | ||||
| o Implementations MUST use [RFC7766] (DNS Transport over TCP - | ||||
| Implementation Requirements) to optimize the use of TCP | Implementation Requirements) to optimize the use of TCP | |||
| connections. | connections. | |||
| o Whilst RFC7766 states that 'DNS clients SHOULD pipeline their | * Whilst RFC7766 states that 'DNS clients SHOULD pipeline their | |||
| queries' on TCP connections, it did not distinguish between XFRs | queries' on TCP connections, it did not distinguish between XFRs | |||
| and other queries for this behavior. It is now recognized that | and other queries for this behavior. It is now recognized that | |||
| XFRs are not as latency sensitive as other queries, and can be | XFRs are not as latency sensitive as other queries, and can be | |||
| significantly more complex for clients to handle both because of | significantly more complex for clients to handle, both because of | |||
| the large amount of state that must be kept and because there may | the large amount of state that must be kept and because there may | |||
| be multiple messages in the responses. For these reasons it is | be multiple messages in the responses. For these reasons, it is | |||
| clarified here that a valid reason for not pipelining queries is | clarified here that a valid reason for not pipelining queries is | |||
| when they are all XFR queries i.e. clients sending multiple XFRs | when they are all XFR queries i.e. clients sending multiple XFRs | |||
| MAY choose not to pipeline those queries. Clients that do not | MAY choose not to pipeline those queries. Clients that do not | |||
| pipeline XFR queries, therefore, have no additional requirements | pipeline XFR queries, therefore, have no additional requirements | |||
| to handle out-of-order or intermingled responses (as described | to handle out-of-order or intermingled responses (as described | |||
| later) since they will never receive them. | later), since they will never receive them. | |||
| o Implementations SHOULD use [RFC7828] (The edns-tcp-keepalive EDNS0 | * Implementations SHOULD use [RFC7828] (The edns-tcp-keepalive EDNS0 | |||
| Option) to manage persistent connections. | Option) to manage persistent connections (which is more flexible | |||
| than using just fixed timeouts). | ||||
| The following sections include detailed clarifications on the updates | The following sections include detailed clarifications on the updates | |||
| to XFR behavior implied in [RFC7766] and how the use of [RFC7828] | to XFR behavior implied in [RFC7766] and how the use of [RFC7828] | |||
| applies specifically to XFR exchanges. It also discusses how IXFR | applies specifically to XFR exchanges. They also discuss how IXFR | |||
| and AXFR can reuse the same TCP connection. | and AXFR can reuse the same TCP connection. | |||
| For completeness, we also mention here the recent specification of | For completeness, we also mention here the recent specification of | |||
| extended DNS error (EDE) codes [RFC8914]. For zone transfers, when | extended DNS error (EDE) codes [RFC8914]. For zone transfers, when | |||
| returning REFUSED to a zone transfer request from an 'unauthorized' | returning REFUSED to a zone transfer request from an 'unauthorized' | |||
| client (e.g., where the client is not listed in an ACL for zone | client (e.g., where the client is not listed in an ACL for zone | |||
| transfers or does not sign the request with the correct TSIG key), | transfers or does not sign the request with a valid TSIG key), the | |||
| the extended DNS error code 18 (Prohibited) can also be sent. | extended DNS error code 18 (Prohibited) can also be sent. | |||
| 7.1. Update to RFC1995 for IXFR-over-TCP | 7.1. Update to RFC1995 for IXFR-over-TCP | |||
| For clarity - an IXFR-over-TCP server compliant with this | For clarity - an IXFR-over-TCP server compliant with this | |||
| specification MUST be able to handle multiple concurrent IXoT | specification MUST be able to handle multiple concurrent IXoT | |||
| requests on a single TCP connection (for the same and different | requests on a single TCP connection (for the same and different | |||
| zones) and SHOULD send the responses as soon as they are available, | zones) and SHOULD send the responses as soon as they are available, | |||
| which might be out-of-order compared to the requests. | which might be out-of-order compared to the requests. | |||
| 7.2. Update to RFC5936 for AXFR-over-TCP | 7.2. Update to RFC5936 for AXFR-over-TCP | |||
| skipping to change at page 13, line 47 ¶ | skipping to change at page 14, line 27 ¶ | |||
| 7.3.1. Connection reuse | 7.3.1. Connection reuse | |||
| As specified, XFR-over-TCP clients SHOULD re-use any existing open | As specified, XFR-over-TCP clients SHOULD re-use any existing open | |||
| TCP connection when starting any new XFR request to the same primary, | TCP connection when starting any new XFR request to the same primary, | |||
| and for issuing SOA queries, instead of opening a new connection. | and for issuing SOA queries, instead of opening a new connection. | |||
| The number of TCP connections between a secondary and primary SHOULD | The number of TCP connections between a secondary and primary SHOULD | |||
| be minimized (also see Section 7.4). | be minimized (also see Section 7.4). | |||
| Valid reasons for not re-using existing connections might include: | Valid reasons for not re-using existing connections might include: | |||
| o as already noted in [RFC7766], separate connections for different | * as already noted in [RFC7766], separate connections for different | |||
| zones might be preferred for operational reasons. In this case | zones might be preferred for operational reasons. In this case, | |||
| the number of concurrent connections for zone transfers SHOULD be | the number of concurrent connections for zone transfers SHOULD be | |||
| limited to the total number of zones transferred between the | limited to the total number of zones transferred between the | |||
| client and server. | client and server. | |||
| o reaching a configured limit for the number of outstanding queries | * reaching a configured limit for the number of outstanding queries | |||
| or XFR requests allowed on a single TCP connection | or XFR requests allowed on a single TCP connection | |||
| o the message ID pool has already been exhausted on an open | * the message ID pool has already been exhausted on an open | |||
| connection | connection | |||
| o a large number of timeouts or slow responses have occurred on an | * a large number of timeouts or slow responses have occurred on an | |||
| open connection | open connection | |||
| o an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been | * an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been | |||
| received from the server and the client is in the process of | received from the server and the client is in the process of | |||
| closing the connection (see Section 7.3.4) | closing the connection (see Section 7.3.4) | |||
| If no TCP connections are currently open, XFR clients MAY send SOA | If no TCP connections are currently open, XFR clients MAY send SOA | |||
| queries over UDP or a new TCP connection. | queries over UDP or a new TCP connection. | |||
| 7.3.2. AXFRs and IXFRs on the same connection | 7.3.2. AXFRs and IXFRs on the same connection | |||
| Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a | Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a | |||
| single TCP connection for both IXFR and AXFR requests. [RFC5936] | single TCP connection for both IXFR and AXFR requests. [RFC5936] | |||
| does make the general statement: | does make the general statement: | |||
| "Non-AXFR session traffic can also use an open TCP connection." | "Non-AXFR session traffic can also use an open TCP connection." | |||
| We clarify here that implementations capable of both AXFR and IXFR | We clarify here that implementations capable of both AXFR and IXFR | |||
| and compliant with this specification SHOULD | and compliant with this specification SHOULD | |||
| o use the same TCP connection for both AXFR and IXFR requests to the | * use the same TCP connection for both AXFR and IXFR requests to the | |||
| same primary | same primary | |||
| o pipeline such requests (if they pipeline XFR requests in general) | * pipeline such requests (if they pipeline XFR requests in general) | |||
| and MAY intermingle them | and MAY intermingle them | |||
| o send the response(s) for each request as soon as they are | * send the response(s) for each request as soon as they are | |||
| available i.e. responses MAY be sent intermingled | available i.e. responses MAY be sent intermingled | |||
| For some current implementations adding all the above functionality | ||||
| would introduce significant code complexity. In such a case, there | ||||
| will need to be an assessment of the trade-off between that and the | ||||
| performance benefits of the above for XFR. | ||||
| 7.3.3. XFR limits | 7.3.3. XFR limits | |||
| The server MAY limit the number of concurrent IXFRs, AXFRs or total | The server MAY limit the number of concurrent IXFRs, AXFRs or total | |||
| XFR transfers in progress, or from a given secondary, to protect | XFR transfers in progress, or from a given secondary, to protect | |||
| server resources. Servers SHOULD return SERVFAIL if this limit is | server resources. Servers SHOULD return SERVFAIL if this limit is | |||
| hit, since it is a transient error and a retry at a later time might | hit, since it is a transient error and a retry at a later time might | |||
| succeed. | succeed (there is no previous specification for this behavior). | |||
| 7.3.4. The edns-tcp-keepalive EDNS0 Option | 7.3.4. The edns-tcp-keepalive EDNS0 Option | |||
| XFR clients that send the edns-tcp-keepalive EDNS0 option on every | XFR clients that send the edns-tcp-keepalive EDNS0 option on every | |||
| XFR request provide the server with maximum opportunity to update the | XFR request provide the server with maximum opportunity to update the | |||
| edns-tcp-keepalive timeout. The XFR server may use the frequency of | edns-tcp-keepalive timeout. The XFR server may use the frequency of | |||
| recent XFRs to calculate an average update rate as input to the | recent XFRs to calculate an average update rate as input to the | |||
| decision of what edns-tcp-keepalive timeout to use. If the server | decision of what edns-tcp-keepalive timeout to use. If the server | |||
| does not support edns-tcp-keepalive the client MAY keep the | does not support edns-tcp-keepalive, the client MAY keep the | |||
| connection open for a few seconds ([RFC7766] recommends that servers | connection open for a few seconds ([RFC7766] recommends that servers | |||
| use timeouts of at least a few seconds). | use timeouts of at least a few seconds). | |||
| Whilst the specification for EDNS0 [RFC6891] does not specifically | Whilst the specification for EDNS0 [RFC6891] does not specifically | |||
| mention AXFRs, it does say | mention AXFRs, it does say | |||
| "If an OPT record is present in a received request, compliant | ||||
| "If an OPT record is present in a received request, compliant | responders MUST include an OPT record in their respective | |||
| responders MUST include an OPT record in their respective | responses." | |||
| responses." | ||||
| We clarify here that if an OPT record is present in a received AXFR | We clarify here that if an OPT record is present in a received AXFR | |||
| request, compliant responders MUST include an OPT record in each of | request, compliant responders MUST include an OPT record in each of | |||
| the subsequent AXFR responses. Note that this requirement, combined | the subsequent AXFR responses. Note that this requirement, combined | |||
| with the use of edns-tcp-keepalive, enables AXFR servers to signal | with the use of edns-tcp-keepalive, enables AXFR servers to signal | |||
| the desire to close a connection (when existing transactions have | the desire to close a connection (when existing transactions have | |||
| competed) due to low resources by sending an edns-tcp-keepalive EDNS0 | competed) due to low resources by sending an edns-tcp-keepalive EDNS0 | |||
| option with a timeout of 0 on any AXFR response. This does not | option with a timeout of 0 on any AXFR response. This does not | |||
| signal that the AXFR is aborted, just that the server wishes to close | signal that the AXFR is aborted, just that the server wishes to close | |||
| the connection as soon as possible. | the connection as soon as possible. | |||
| 7.3.5. Backwards compatibility | 7.3.5. Backwards compatibility | |||
| Certain legacy behaviors were noted in [RFC5936], with provisions | Certain legacy behaviors were noted in [RFC5936], with provisions | |||
| that implementations may want to offer options to fallback to legacy | that implementations may want to offer options to fallback to legacy | |||
| behavior when interoperating with servers known not to support | behavior when interoperating with servers known to not support | |||
| [RFC5936]. For purposes of interoperability, IXFR and AXFR | [RFC5936]. For purposes of interoperability, IXFR and AXFR | |||
| implementations may want to continue offering such configuration | implementations may want to continue offering such configuration | |||
| options, as well as supporting some behaviors that were | options, as well as supporting some behaviors that were | |||
| underspecified prior to this work (e.g., performing IXFR and AXFRs on | underspecified prior to this work (e.g., performing IXFR and AXFRs on | |||
| separate connections). However, XoT implementations should have no | separate connections). However, XoT connections should have no need | |||
| need to do so. | to do so. | |||
| 7.4. Update to RFC7766 | 7.4. Update to RFC7766 | |||
| [RFC7766] made general implementation recommendations with regard to | [RFC7766] made general implementation recommendations with regard to | |||
| TCP/TLS connection handling: | TCP/TLS connection handling: | |||
| "To mitigate the risk of unintentional server overload, DNS | "To mitigate the risk of unintentional server overload, DNS | |||
| clients MUST take care to minimize the number of concurrent TCP | clients MUST take care to minimize the number of concurrent TCP | |||
| connections made to any individual server. It is RECOMMENDED | connections made to any individual server. It is RECOMMENDED | |||
| that for any given client/server interaction there SHOULD be no | that for any given client/server interaction there SHOULD be no | |||
| more than one connection for regular queries, one for zone | more than one connection for regular queries, one for zone | |||
| transfers, and one for each protocol that is being used on top | transfers, and one for each protocol that is being used on top | |||
| of TCP (for example, if the resolver was using TLS). However, | of TCP (for example, if the resolver was using TLS). However, | |||
| it is noted that certain primary/ secondary configurations with | it is noted that certain primary/ secondary configurations with | |||
| many busy zones might need to use more than one TCP connection | many busy zones might need to use more than one TCP connection | |||
| for zone transfers for operational reasons (for example, to | for zone transfers for operational reasons (for example, to | |||
| support concurrent transfers of multiple zones)." | support concurrent transfers of multiple zones)." | |||
| Whilst this recommends a particular behavior for the clients using | Whilst this recommends a particular behavior for the clients using | |||
| TCP, it does not relax the requirement for servers to handle 'mixed' | TCP, it does not relax the requirement for servers to handle 'mixed' | |||
| traffic (regular queries and zone transfers) on any open TCP/TLS | traffic (regular queries and zone transfers) on any open TCP/TLS | |||
| connection. It also overlooks the potential that other transports | connection. It also overlooks the potential that other transports | |||
| might want to take the same approach with regard to using separate | might want to take the same approach with regard to using separate | |||
| connections for different purposes. | connections for different purposes. | |||
| This specification for XoT updates the guidance in [RFC7766] to | This specification updates the above general guidance in [RFC7766] to | |||
| provide the same separation of connection purpose (regular queries | provide the same separation of connection purpose (regular queries | |||
| and zone transfers) for all transports being used on top of TCP. | and zone transfers) for all transports being used on top of TCP. | |||
| Therefore, it is RECOMMENDED that for each protocol used on top of | Therefore, it is RECOMMENDED that for each protocol used on top of | |||
| TCP in any given client/server interaction there SHOULD be no more | TCP in any given client/server interaction, there SHOULD be no more | |||
| than one connection for regular queries and one for zone transfers. | than one connection for regular queries and one for zone transfers. | |||
| As an illustration, it could be imagined that in future such an | As an illustration, it could be imagined that in future such an | |||
| interaction could hypothetically include one or all of the following: | interaction could hypothetically include one or all of the following: | |||
| o one TCP connection for regular queries | * one TCP connection for regular queries | |||
| o one TCP connection for zone transfers | * one TCP connection for zone transfers | |||
| o one TLS connection for regular queries | * one TLS connection for regular queries | |||
| o one TLS connection for zone transfers | * one TLS connection for zone transfers | |||
| o one DoH connection for regular queries | * one DoH connection for regular queries | |||
| o one DoH connection for zone transfers | * one DoH connection for zone transfers | |||
| Section 7.3.1 has provided specific details of reasons where more | Section 7.3.1 has provided specific details of reasons where more | |||
| than one connection for a given transport might be required for zone | than one connection for a given transport might be required for zone | |||
| transfers from a particular client. | transfers from a particular client. | |||
| 8. XoT specification | 8. XoT specification | |||
| 8.1. TLS versions | 8.1. Connection establishment | |||
| For improved security all implementations of this specification MUST | During connection establishment the Application-Layer Protocol | |||
| use only TLS 1.3 [RFC8446] or later. | Negotiation (ALPN) token "dot" [DoT-ALPN] MUST be selected in the TLS | |||
| handshake. | ||||
| 8.2. Port selection | 8.2. TLS versions | |||
| All implementations of this specification MUST use only TLS 1.3 | ||||
| [RFC8446] or later. | ||||
| 8.3. Port selection | ||||
| The connection for XoT SHOULD be established using port 853, as | The connection for XoT SHOULD be established using port 853, as | |||
| specified in [RFC7858], unless there is mutual agreement between the | specified in [RFC7858], unless there is mutual agreement between the | |||
| secondary and primary to use a port other than port 853 for XoT. | secondary and primary to use a port other than port 853 for XoT. | |||
| There MAY be agreement to use different ports for AXoT and IXoT, or | There MAY be agreement to use different ports for AXoT and IXoT, or | |||
| for different zones. | for different zones. | |||
| 8.3. High level XoT descriptions | 8.4. High level XoT descriptions | |||
| It is useful to note that in XoT it is the secondary that initiates | It is useful to note that in XoT, it is the secondary that initiates | |||
| the TLS connection to the primary for a XFR request, so that in terms | the TLS connection to the primary for a XFR request, so that in terms | |||
| of connectivity the secondary is the TLS client and the primary the | of connectivity, the secondary is the TLS client and the primary the | |||
| TLS server. | TLS server. | |||
| The figure below provides an outline of the AXoT mechanism including | The figure below provides an outline of the AXoT mechanism including | |||
| NOTIFYs. | NOTIFYs. | |||
| Secondary Primary | Secondary Primary | |||
| | NOTIFY | | | NOTIFY | | |||
| | <-------------------------------- | UDP | | <-------------------------------- | UDP | |||
| | --------------------------------> | | | --------------------------------> | | |||
| | NOTIFY Response | | | NOTIFY Response | | |||
| | | | | | | |||
| | | | | | | |||
| | SOA Request | | | SOA Request | | |||
| | --------------------------------> | UDP (or part of | | --------------------------------> | UDP (or part of | |||
| | <-------------------------------- | a TCP/TLS session) | | <-------------------------------- | a TCP/TLS session) | |||
| | SOA Response | | | SOA Response | | |||
| | | | | | | |||
| | | | | | | |||
| | | | | | | |||
| | AXFR Request | --- | | AXFR Request | --- | |||
| | --------------------------------> | | | | --------------------------------> | | | |||
| | <-------------------------------- | | | | <-------------------------------- | | | |||
| | AXFR Response 1 | | | | AXFR Response 1 | | | |||
| | (Zone data) | | | | (Zone data) | | | |||
| | | | | | | | | |||
| | <-------------------------------- | | TLS | | <-------------------------------- | | TLS | |||
| | AXFR Response 2 | | Session | | AXFR Response 2 | | Session | |||
| | (Zone data) | | | | (Zone data) | | | |||
| | | | | | | | | |||
| | <-------------------------------- | | | | <-------------------------------- | | | |||
| | AXFR Response 3 | | | | AXFR Response 3 | | | |||
| | (Zone data) | --- | | (Zone data) | --- | |||
| | | | | | | |||
| Figure 3. AXoT Mechanism | Figure 3. AXoT Mechanism | |||
| The figure below provides an outline of the IXoT mechanism including | The figure below provides an outline of the IXoT mechanism including | |||
| NOTIFYs. | NOTIFYs. | |||
| Secondary Primary | Secondary Primary | |||
| | NOTIFY | | | NOTIFY | | |||
| | <-------------------------------- | UDP | | <-------------------------------- | UDP | |||
| | --------------------------------> | | | --------------------------------> | | |||
| | NOTIFY Response | | | NOTIFY Response | | |||
| | | | | | | |||
| | | | | | | |||
| | SOA Request | | | SOA Request | | |||
| | --------------------------------> | UDP (or part of | | --------------------------------> | UDP (or part of | |||
| | <-------------------------------- | a TCP/TLS session) | | <-------------------------------- | a TCP/TLS session) | |||
| | SOA Response | | | SOA Response | | |||
| | | | | | | |||
| | | | | | | |||
| | | | | | | |||
| | IXFR Request | --- | | IXFR Request | --- | |||
| | --------------------------------> | | | | --------------------------------> | | | |||
| | <-------------------------------- | | | | <-------------------------------- | | | |||
| | IXFR Response | | | | IXFR Response | | | |||
| | (Zone data) | | | | (Zone data) | | | |||
| | | | TLS | | | | TLS | |||
| | | | session | | | | session | |||
| | IXFR Request | | | | IXFR Request | | | |||
| | --------------------------------> | | | | --------------------------------> | | | |||
| | <-------------------------------- | | | | <-------------------------------- | | | |||
| | IXFR Response | | | | IXFR Response | | | |||
| | (Zone data) | --- | | (Zone data) | --- | |||
| Figure 4. IXoT Mechanism | Figure 4. IXoT Mechanism | |||
| 8.4. XoT transfers | 8.5. XoT transfers | |||
| For a zone transfer between two end points to be considered protected | For a zone transfer between two end points to be considered protected | |||
| with XoT all XFR requests and response for that zone MUST be sent | with XoT all XFR requests and response for that zone MUST be sent | |||
| over TLS connections where at a minimum: | over TLS connections where at a minimum: | |||
| o the client MUST authenticate the server by use of an | * the client MUST authenticate the server by use of an | |||
| authentication domain name using a Strict Privacy Profile as | authentication domain name using a Strict Privacy Profile, as | |||
| described in [RFC8310] | described in [RFC8310] | |||
| o the server MUST validate the client is authorized to request or | * the server MUST validate the client is authorized to request or | |||
| proxy a zone transfer by using one or both of the following: | proxy a zone transfer by using one or both of the following | |||
| methods: | ||||
| * an IP based ACL (which can be either per-message or per- | ||||
| connection) | ||||
| * Mutual TLS (mTLS) | - Mutual TLS (mTLS) | |||
| - an IP based ACL (which can be either per-message or per- | ||||
| connection) combined with a valid TSIG/SIG(0) signature on the | ||||
| XFR request | ||||
| The server MAY also require a valid TSIG/SIG(0) signature, but this | If only one method is selected then mTLS is preferred because it | |||
| alone is not sufficient to authenticate the client or server. | provides strong cryptographic protection at both endpoints. | |||
| Authentication mechanisms are discussed in full in Section 10 and the | Authentication mechanisms are discussed in full in Section 10 and the | |||
| rationale for the above requirement in Section 11. Transfer group | rationale for the above requirement in Section 11. Transfer group | |||
| policies are discussed in Section 12. | policies are discussed in Section 12. | |||
| 8.5. XoT connections | 8.6. XoT connections | |||
| The details in Section 7 about, e.g., persistent connections and XFR | The details in Section 7 about, e.g., persistent connections and XFR | |||
| message handling are fully applicable to XoT connections as well. | message handling are fully applicable to XoT connections as well. | |||
| However any behavior specified here takes precedence for XoT. | However, any behavior specified here takes precedence for XoT. | |||
| If no TLS connections are currently open, XoT clients MAY send SOA | If no TLS connections are currently open, XoT clients MAY send SOA | |||
| queries over UDP or TCP, or TLS. | queries over UDP or TCP, or TLS. | |||
| 8.6. XoT vs ADoT | 8.7. XoT vs ADoT | |||
| As noted earlier, there is currently no specification for encryption | As noted earlier, there is currently no specification for encryption | |||
| of connections from recursive resolvers to authoritative servers. | of connections from recursive resolvers to authoritative servers. | |||
| Some authoritatives are experimenting with ADoT and opportunistic | Some authoritatives are experimenting with ADoT and opportunistic | |||
| encryption has also been raised as a possibility; it is therefore | encryption has also been raised as a possibility; it is therefore | |||
| highly likely that use of encryption by authoritative servers will | highly likely that use of encryption by authoritative servers will | |||
| evolve in the coming years. | evolve in the coming years. | |||
| This raises questions in the short term with regard to TLS connection | This raises questions in the short term with regard to TLS connection | |||
| and message handling for authoritative servers. In particular, there | and message handling for authoritative servers. In particular, there | |||
| is likely to be a class of authoritatives that wish to use XoT in the | is likely to be a class of authoritatives that wish to use XoT in the | |||
| near future with a small number of configured secondaries but that do | near future with a small number of configured secondaries, but that | |||
| wish to support DoT for regular queries from recursive in that same | do not wish to support DoT for regular queries from recursives in | |||
| time frame. These servers have to potentially cope with probing and | that same time frame. These servers have to potentially cope with | |||
| direct queries from recursives and from test servers, and also | probing and direct queries from recursives and from test servers, and | |||
| potential attacks that might wish to make use of TLS to overload the | also potential attacks that might wish to make use of TLS to overload | |||
| server. | the server. | |||
| [RFC5936] clearly states that non-AXFR session traffic can use an | [RFC5936] clearly states that non-AXFR session traffic can use an | |||
| open TCP connection, however, this requirement needs to be re- | open TCP connection, however, this requirement needs to be re- | |||
| evaluated when considering applying the same model to XoT. Proposing | evaluated when considering applying the same model to XoT. Proposing | |||
| that a server should also start responding to all queries received | that a server should also start responding to all queries received | |||
| over TLS just because it has enabled XoT would be equivalent to | over TLS just because it has enabled XoT would be equivalent to | |||
| defining a form of authoritative DoT. This specification does not | defining a form of authoritative DoT. This specification does not | |||
| propose that, but it also does not prohibit servers from answering | propose that, but it also does not prohibit servers from answering | |||
| queries unrelated to XFR exchanges over TLS. Rather, this | queries unrelated to XFR exchanges over TLS. Rather, this | |||
| specification simply outlines in later sections: | specification simply outlines in later sections: | |||
| o how XoT implementations should utilize EDE codes in response to | * how XoT implementations should utilize EDE codes in response to | |||
| queries on TLS connections they are not willing to answer (see | queries on TLS connections they are not willing to answer (see | |||
| Section 8.7) | Section 8.8) | |||
| o the operational and policy options that a XoT server operator has | * the operational and policy options that a XoT server operator has | |||
| with regard to managing TLS connections and messages (see | with regard to managing TLS connections and messages (see | |||
| Appendix A) | Appendix A) | |||
| 8.7. Response RCODES | 8.8. Response RCODES | |||
| XoT clients and servers MUST implement EDE codes. If a XoT server | XoT clients and servers MUST implement EDE codes. If a XoT server | |||
| receives non-XoT traffic it is not willing to answer on a TLS | receives non-XoT traffic it is not willing to answer on a TLS | |||
| connection it SHOULD respond with the extended DNS error code 21 - | connection, it SHOULD respond with REFUSED and the extended DNS error | |||
| Not Supported [RFC8914]. XoT clients should not send any further | code 21 - Not Supported [RFC8914]. XoT clients should not send any | |||
| queries of this type to the server for a reasonable period of time | further queries of this type to the server for a reasonable period of | |||
| (for example, one hour) i.e., long enough that the server | time (for example, one hour) i.e., long enough that the server | |||
| configuration or policy might be updated. | configuration or policy might be updated. | |||
| Historically servers have used the REFUSED RCODE for many situations, | Historically, servers have used the REFUSED RCODE for many | |||
| and so clients often had no detailed information on which to base an | situations, and so clients often had no detailed information on which | |||
| error or fallback path when queries were refused. As a result the | to base an error or fallback path when queries were refused. As a | |||
| client behavior could vary significantly. XoT servers that refuse | result, the client behavior could vary significantly. XoT servers | |||
| queries must cater for the fact that client behavior might vary from | that refuse queries must cater for the fact that client behavior | |||
| continually retrying queries regardless of receiving REFUSED to every | might vary from continually retrying queries regardless of receiving | |||
| query, or at the other extreme clients may decide to stop using the | REFUSED to every query, or at the other extreme clients may decide to | |||
| server over any transport. This might be because those clients are | stop using the server over any transport. This might be because | |||
| either non-XoT clients or do not implement EDE codes. | those clients are either non-XoT clients or do not implement EDE | |||
| codes. | ||||
| 8.8. AXoT specifics | 8.9. AXoT specifics | |||
| 8.8.1. Padding AXoT responses | 8.9.1. Padding AXoT responses | |||
| The goal of padding AXoT responses would be two fold: | The goal of padding AXoT responses is two fold: | |||
| o to obfuscate the actual size of the transferred zone to minimize | * to obfuscate the actual size of the transferred zone to minimize | |||
| information leakage about the entire contents of the zone. | information leakage about the entire contents of the zone. | |||
| o to obfuscate the incremental changes to the zone between SOA | * to obfuscate the incremental changes to the zone between SOA | |||
| updates to minimize information leakage about zone update activity | updates to minimize information leakage about zone update activity | |||
| and growth. | and growth. | |||
| Note that the re-use of XoT connections for transfers of multiple | Note that the re-use of XoT connections for transfers of multiple | |||
| different zones complicates any attempt to analyze the traffic size | different zones slightly complicates any attempt to analyze the | |||
| and timing to extract information. | traffic size and timing to extract information. Also, effective | |||
| padding may require state to be kept as zones may grow and/or shrink | ||||
| over time. | ||||
| It is noted here that, depending on the padding policies eventually | It is noted here that, depending on the padding policies eventually | |||
| developed for XoT, the requirement to obfuscate the total zone size | developed for XoT, the requirement to obfuscate the total zone size | |||
| might require a server to create 'empty' AXoT responses. That is, | might require a server to create 'empty' AXoT responses. That is, | |||
| AXoT responses that contain no RR's apart from an OPT RR containing | AXoT responses that contain no RR's apart from an OPT RR containing | |||
| the EDNS(0) option for padding. For example, without this capability | the EDNS(0) option for padding. For example, without this capability | |||
| the maximum size that a tiny zone could be padded to would | the maximum size that a tiny zone could be padded to would | |||
| theoretically be limited if there had to be a minimum of 1 RR per | theoretically be limited if there had to be a minimum of 1 RR per | |||
| packet. | packet. | |||
| However, as with existing AXFR, the last AXoT response message sent | However, as with existing AXFR, the last AXoT response message sent | |||
| MUST contain the same SOA that was in the first message of the AXoT | MUST contain the same SOA that was in the first message of the AXoT | |||
| response series in order to signal the conclusion of the zone | response series in order to signal the conclusion of the zone | |||
| transfer. | transfer. | |||
| [RFC5936] says: | [RFC5936] says: | |||
| "Each AXFR response message SHOULD contain a sufficient number | "Each AXFR response message SHOULD contain a sufficient number | |||
| of RRs to reasonably amortize the per-message overhead, up to | of RRs to reasonably amortize the per-message overhead, up to | |||
| the largest number that will fit within a DNS message (taking | the largest number that will fit within a DNS message (taking | |||
| the required content of the other sections into account, as | the required content of the other sections into account, as | |||
| described below)." | described below)." | |||
| 'Empty' AXoT responses generated in order to meet a padding | 'Empty' AXoT responses generated in order to meet a padding | |||
| requirement will be exceptions to the above statement. For | requirement will be exceptions to the above statement. For | |||
| flexibility, future proofing and in order to guarantee support for | flexibility, future proofing and in order to guarantee support for | |||
| future padding policies, we state here that secondary implementations | future padding policies, we state here that secondary implementations | |||
| MUST be resilient to receiving padded AXoT responses, including | MUST be resilient to receiving padded AXoT responses, including | |||
| 'empty' AXoT responses that contain only an OPT RR containing the | 'empty' AXoT responses that contain only an OPT RR containing the | |||
| EDNS(0) option for padding. | EDNS(0) option for padding. | |||
| Recommendation of specific policies for padding AXoT responses are | Recommendation of specific policies for padding AXoT responses are | |||
| out of scope for this specification. Detailed considerations of such | out of scope for this specification. Detailed considerations of such | |||
| policies and the trade-offs involved are expected to be the subject | policies and the trade-offs involved are expected to be the subject | |||
| of future work. | of future work. | |||
| 8.9. IXoT specifics | 8.10. IXoT specifics | |||
| 8.9.1. Condensation of responses | 8.10.1. Condensation of responses | |||
| [RFC1995] says condensation of responses is optional and MAY be done. | [RFC1995] says condensation of responses is optional and MAY be done. | |||
| Whilst it does add complexity to generating responses it can | Whilst it does add complexity to generating responses, it can | |||
| significantly reduce the size of responses. However any such | significantly reduce the size of responses. However any such | |||
| reduction might be offset by increased message size due to padding. | reduction might be offset by increased message size due to padding. | |||
| This specification does not update the optionality of condensation | This specification does not update the optionality of condensation | |||
| for XoT responses. | for XoT responses. | |||
| 8.9.2. Fallback to AXFR | 8.10.2. Fallback to AXFR | |||
| Fallback to AXFR can happen, for example, if the server is not able | Fallback to AXFR can happen, for example, if the server is not able | |||
| to provide an IXFR for the requested SOA. Implementations differ in | to provide an IXFR for the requested SOA. Implementations differ in | |||
| how long they store zone deltas and how many may be stored at any one | how long they store zone deltas and how many may be stored at any one | |||
| time. | time. | |||
| Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD | Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD | |||
| request the AXFR on the already open XoT connection. | request the AXFR on the already open XoT connection. | |||
| 8.9.3. Padding of IXoT responses | 8.10.3. Padding of IXoT responses | |||
| The goal of padding IXoT responses would be to obfuscate the | The goal of padding IXoT responses is to obfuscate the incremental | |||
| incremental changes to the zone between SOA updates to minimize | changes to the zone between SOA updates to minimize information | |||
| information leakage about zone update activity and growth. Both the | leakage about zone update activity and growth. Both the size and | |||
| size and timing of the IXoT responses could reveal information. | timing of the IXoT responses could reveal information. | |||
| IXFR responses can vary in size greatly from the order of 100 bytes | IXFR responses can vary greatly in size from the order of 100 bytes | |||
| for one or two record updates, to tens of thousands of bytes for | for one or two record updates, to tens of thousands of bytes for | |||
| large dynamic DNSSEC signed zones. The frequency of IXFR responses | large dynamic DNSSEC signed zones. The frequency of IXFR responses | |||
| can also depend greatly on if and how the zone is DNSSEC signed. | can also depend greatly on if and how the zone is DNSSEC signed. | |||
| In order to guarantee support for future padding policies, we state | In order to guarantee support for future padding policies, we state | |||
| here that secondary implementations MUST be resilient to receiving | here that secondary implementations MUST be resilient to receiving | |||
| padded IXoT responses. | padded IXoT responses. | |||
| Recommendation of specific policies for padding IXoT responses are | Recommendation of specific policies for padding IXoT responses are | |||
| out of scope for this specification. Detailed considerations of such | out of scope for this specification. Detailed considerations of such | |||
| policies and the trade-offs involved are expected to be the subject | padding policies, the use of traffic obfuscation techniques (such as | |||
| of future work. | 'dummy' traffic), and the trade-offs involved are expected to be the | |||
| subject of future work. | ||||
| 8.10. Name compression and maximum payload sizes | 8.11. Name compression and maximum payload sizes | |||
| It is noted here that name compression [RFC1035] can be used in XFR | It is noted here that name compression [RFC1035] can be used in XFR | |||
| responses to reduce the size of the payload, however the maximum | responses to reduce the size of the payload, however, the maximum | |||
| value of the offset that can be used in the name compression pointer | value of the offset that can be used in the name compression pointer | |||
| structure is 16384. For some DNS implementations this limits the | structure is 16384. For some DNS implementations this limits the | |||
| size of an individual XFR response used in practice to something | size of an individual XFR response used in practice to something | |||
| around the order of 16kB. In principle, larger payload sizes can be | around the order of 16kB. In principle, larger payload sizes can be | |||
| supported for some responses with more sophisticated approaches | supported for some responses with more sophisticated approaches | |||
| (e.g., by pre-calculating the maximum offset required). | (e.g., by pre-calculating the maximum offset required). | |||
| Implementations may wish to offer options to disable name compression | Implementations may wish to offer options to disable name compression | |||
| for XoT responses to enable larger payloads. This might be | for XoT responses to enable larger payloads. This might be | |||
| particularly helpful when padding is used since minimizing the | particularly helpful when padding is used since minimizing the | |||
| payload size is not necessarily a useful optimization in this case | payload size is not necessarily a useful optimization in this case | |||
| and disabling name compression will reduce the resources required to | and disabling name compression will reduce the resources required to | |||
| construct the payload. | construct the payload. | |||
| 9. Multi-primary Configurations | 9. Multi-primary Configurations | |||
| Also known as multi-master configurations this model can provide | This model can provide flexibility and redundancy particularly for | |||
| flexibility and redundancy particularly for IXFR. A secondary will | IXFR. A secondary will receive one or more NOTIFY messages and can | |||
| receive one or more NOTIFY messages and can send an SOA to all of the | send an SOA to all of the configured primaries. It can then choose | |||
| configured primaries. It can then choose to send an XFR request to | to send an XFR request to the primary with the highest SOA (or based | |||
| the primary with the highest SOA (or other criteria, e.g., RTT). | on other criteria, e.g., RTT). | |||
| When using persistent connections the secondary may have a XoT | When using persistent connections, the secondary may have a XoT | |||
| connection already open to one or more primaries. Should a secondary | connection already open to one or more primaries. Should a secondary | |||
| preferentially request an XFR from a primary to which it already has | preferentially request an XFR from a primary to which it already has | |||
| an open XoT connection or the one with the highest SOA (assuming it | an open XoT connection or the one with the highest SOA (assuming it | |||
| doesn't have a connection open to it already)? | doesn't have a connection open to it already)? | |||
| Two extremes can be envisaged here. The first one can be considered | Two extremes can be envisaged here. The first one can be considered | |||
| a 'preferred primary connection' model. In this case the secondary | a 'preferred primary connection' model. In this case, the secondary | |||
| continues to use one persistent connection to a single primary until | continues to use one persistent connection to a single primary until | |||
| it has reason not to. Reasons not to might include the primary | it has reason not to. Reasons not to might include the primary | |||
| repeatedly closing the connection, long query/response RTTs on | repeatedly closing the connection, long query/response RTTs on | |||
| transfers or the SOA of the primary being an unacceptable lag behind | transfers or the SOA of the primary being an unacceptable lag behind | |||
| the SOA of an alternative primary. | the SOA of an alternative primary. | |||
| The other extreme can be considered a 'parallel primary connection' | The other extreme can be considered a 'parallel primary connection' | |||
| model. Here a secondary could keep multiple persistent connections | model. Here, a secondary could keep multiple persistent connections | |||
| open to all available primaries and only request XFRs from the | open to all available primaries and only request XFRs from the | |||
| primary with the highest serial number. Since normally the number of | primary with the highest serial number. Since normally the number of | |||
| secondaries and primaries in direct contact in a transfer group is | secondaries and primaries in direct contact in a transfer group is | |||
| reasonably low this might be feasible if latency is the most | reasonably low this might be feasible if latency is the most | |||
| significant concern. | significant concern. | |||
| Recommendation of a particular scheme is out of scope of this | Recommendation of a particular scheme is out of scope of this | |||
| document but implementations are encouraged to provide configuration | document, but implementations are encouraged to provide configuration | |||
| options that allow operators to make choices about this behavior. | options that allow operators to make choices about this behavior. | |||
| 10. Authentication mechanisms | 10. Authentication mechanisms | |||
| To provide context to the requirements in section Section 8.4, this | To provide context to the requirements in Section 8.5, this section | |||
| section provides a brief summary of some of the existing | provides a brief summary of some of the existing authentication and | |||
| authentication and validation mechanisms (both transport independent | validation mechanisms (both transport independent and TLS specific) | |||
| and TLS specific) that are available when performing zone transfers. | that are available when performing zone transfers. Section 11 then | |||
| Section 11 then discusses in more details specifically how a | discusses in more details specifically how a combination of TLS | |||
| combination of TLS authentication, TSIG and IP based ACLs interact | authentication, TSIG and IP based ACLs interact for XoT. | |||
| for XoT. | ||||
| We classify the mechanisms based on the following properties: | We classify the mechanisms based on the following properties: | |||
| o 'Data Origin Authentication' (DO): Authentication that the DNS | * 'Data Origin Authentication' (DO): Authentication that the DNS | |||
| message originated from the party with whom credentials were | message originated from the party with whom credentials were | |||
| shared, and of the data integrity of the message contents (the | shared, and of the data integrity of the message contents (the | |||
| originating party may or may not be party operating the far end of | originating party may or may not be party operating the far end of | |||
| a TCP/TLS connection in a 'proxy' scenario). | a TCP/TLS connection in a 'proxy' scenario). | |||
| o 'Channel Confidentiality' (CC): Confidentiality of the | * 'Channel Confidentiality' (CC): Confidentiality of the | |||
| communication channel between the client and server (i.e. the two | communication channel between the client and server (i.e. the two | |||
| end points of a TCP/TLS connection) from passive surveillance. | end points of a TCP/TLS connection) from passive surveillance. | |||
| o 'Channel Authentication' (CA): Authentication of the identity of | * 'Channel Authentication' (CA): Authentication of the identity of | |||
| party to whom a TCP/TLS connection is made (this might not be a | party to whom a TCP/TLS connection is made (this might not be a | |||
| direct connection between the primary and secondary in a proxy | direct connection between the primary and secondary in a proxy | |||
| scenario). | scenario). | |||
| 10.1. TSIG | 10.1. TSIG | |||
| TSIG [RFC8945] provides a mechanism for two or more parties to use | TSIG [RFC8945] provides a mechanism for two or more parties to use | |||
| shared secret keys which can then be used to create a message digest | shared secret keys which can then be used to create a message digest | |||
| to protect individual DNS messages. This allows each party to | to protect individual DNS messages. This allows each party to | |||
| authenticate that a request or response (and the data in it) came | authenticate that a request or response (and the data in it) came | |||
| from the other party, even if it was transmitted over an unsecured | from the other party, even if it was transmitted over an unsecured | |||
| channel or via a proxy. | channel or via a proxy. | |||
| Properties: Data origin authentication | Properties: Data origin authentication | |||
| 10.2. SIG(0) | 10.2. SIG(0) | |||
| SIG(0) [RFC2931] similarly also provides a mechanism to digitally | SIG(0) [RFC2931] similarly provides a mechanism to digitally sign a | |||
| sign a DNS message but uses public key authentication, where the | DNS message but uses public key authentication, where the public keys | |||
| public keys are stored in DNS as KEY RRs and a private key is stored | are stored in DNS as KEY RRs and a private key is stored at the | |||
| at the signer. | signer. | |||
| Properties: Data origin authentication | Properties: Data origin authentication | |||
| 10.3. TLS | 10.3. TLS | |||
| 10.3.1. Opportunistic TLS | 10.3.1. Opportunistic TLS | |||
| Opportunistic TLS for DoT is defined in [RFC8310] and can provide a | Opportunistic TLS for DoT is defined in [RFC8310] and can provide a | |||
| defense against passive surveillance, providing on-the-wire | defense against passive surveillance, providing on-the-wire | |||
| confidentiality. Essentially | confidentiality. Essentially | |||
| o clients that know authentication information for a server SHOULD | * clients that know authentication information for a server SHOULD | |||
| try to authenticate the server | try to authenticate the server | |||
| o however they MAY fallback to using TLS without authentication and | * however they MAY fallback to using TLS without authentication and | |||
| o they MAY fallback to using cleartext if TLS is not available. | * they MAY fallback to using cleartext if TLS is not available. | |||
| As such it does not offer a defense against active attacks (e.g., an | As such, it does not offer a defense against active attacks (e.g., an | |||
| on path active attacker on the connection from client to server), and | on path active attacker on the connection from client to server), and | |||
| is not considered as useful for XoT. | is not considered as useful for XoT. | |||
| Properties: None guaranteed. | Properties: None guaranteed. | |||
| 10.3.2. Strict TLS | 10.3.2. Strict TLS | |||
| Strict TLS for DoT [RFC8310] requires that a client is configured | Strict TLS for DoT [RFC8310] requires that a client is configured | |||
| with an authentication domain name (and/or SPKI pinset) that MUST be | with an authentication domain name (and/or SPKI pinset) that MUST be | |||
| used to authenticate the TLS handshake with the server. If | used to authenticate the TLS handshake with the server. If | |||
| authentication of the server fails, the client will not proceed with | authentication of the server fails, the client will not proceed with | |||
| the connection. This provides a defense for the client against | the connection. This provides a defense for the client against | |||
| active surveillance, providing client-to-server authentication and | active surveillance, providing client-to-server authentication and | |||
| end-to-end channel confidentiality. | end-to-end channel confidentiality. | |||
| Properties: Channel confidentiality and authentication (of the | Properties: Channel confidentiality and channel authentication (of | |||
| server). | the server). | |||
| 10.3.3. Mutual TLS | 10.3.3. Mutual TLS | |||
| This is an extension to Strict TLS [RFC8310] which requires that a | This is an extension to Strict TLS [RFC8310] which requires that a | |||
| client is configured with an authentication domain name (and/or SPKI | client is configured with an authentication domain name (and/or SPKI | |||
| pinset) and a client certificate. The client offers the certificate | pinset) and a client certificate. The client offers the certificate | |||
| for authentication by the server and the client can authenticate the | for authentication by the server and the client can authenticate the | |||
| server the same way as in Strict TLS. This provides a defense for | server the same way as in Strict TLS. This provides a defense for | |||
| both parties against active surveillance, providing bi-directional | both parties against active surveillance, providing bi-directional | |||
| authentication and end-to-end channel confidentiality. | authentication and end-to-end channel confidentiality. | |||
| Properties: Channel confidentiality and mutual authentication. | Properties: Channel confidentiality and mutual channel | |||
| authentication. | ||||
| 10.4. IP Based ACL on the Primary | 10.4. IP Based ACL on the Primary | |||
| Most DNS server implementations offer an option to configure an IP | Most DNS server implementations offer an option to configure an IP | |||
| based Access Control List (ACL), which is often used in combination | based Access Control List (ACL), which is often used in combination | |||
| with TSIG based ACLs to restrict access to zone transfers on primary | with TSIG based ACLs to restrict access to zone transfers on primary | |||
| servers on a per query basis. | servers on a per query basis. | |||
| This is also possible with XoT but it must be noted that, as with | This is also possible with XoT, but it must be noted that, as with | |||
| TCP, the implementation of such an ACL cannot be enforced on the | TCP, the implementation of such an ACL cannot be enforced on the | |||
| primary until an XFR request is received on an established | primary until an XFR request is received on an established | |||
| connection. | connection. | |||
| As discussed in Appendix A an IP based per connection ACL could also | As discussed in Appendix A, an IP based per connection ACL could also | |||
| be implemented where only TLS connections from recognized secondaries | be implemented where only TLS connections from recognized secondaries | |||
| are accepted. | are accepted. | |||
| Properties: Channel authentication of the client. | Properties: Channel authentication of the client. | |||
| 10.5. ZONEMD | 10.5. ZONEMD | |||
| For completeness, we also describe Message Digest for DNS Zones | For completeness, we also describe Message Digest for DNS Zones | |||
| (ZONEMD) [RFC8976] here. The message digest is a mechanism that can | (ZONEMD) [RFC8976] here. The message digest is a mechanism that can | |||
| be used to verify the content of a standalone zone. It is designed | be used to verify the content of a standalone zone. It is designed | |||
| skipping to change at page 27, line 21 ¶ | skipping to change at page 28, line 39 ¶ | |||
| a general consumer of a zone to do origin authentication of the | a general consumer of a zone to do origin authentication of the | |||
| entire zone contents. Note that the current version of [RFC8976] | entire zone contents. Note that the current version of [RFC8976] | |||
| states: | states: | |||
| "As specified herein, ZONEMD is impractical for large, dynamic zones | "As specified herein, ZONEMD is impractical for large, dynamic zones | |||
| due to the time and resources required for digest calculation. | due to the time and resources required for digest calculation. | |||
| However, The ZONEMD record is extensible so that new digest schemes | However, The ZONEMD record is extensible so that new digest schemes | |||
| may be added in the future to support large, dynamic zones." | may be added in the future to support large, dynamic zones." | |||
| It is complementary but orthogonal the above mechanisms; and can be | It is complementary but orthogonal the above mechanisms; and can be | |||
| used in conjunction with XoT but is not considered further here. | used in conjunction with XoT, but is not considered further here. | |||
| 11. XoT authentication | 11. XoT authentication | |||
| It is noted that zone transfer scenarios can vary from a simple | It is noted that zone transfer scenarios can vary from a simple | |||
| single primary/secondary relationship where both servers are under | single primary/secondary relationship where both servers are under | |||
| the control of a single operator to a complex hierarchical structure | the control of a single operator to a complex hierarchical structure | |||
| which includes proxies and multiple operators. Each deployment | which includes proxies and multiple operators. Each deployment | |||
| scenario will require specific analysis to determine which | scenario will require specific analysis to determine which | |||
| combination of authentication methods are best suited to the | combination of authentication methods are best suited to the | |||
| deployment model in question. | deployment model in question. | |||
| The XoT authentication requirement specified in Section 8.4 addresses | The XoT authentication requirement specified in Section 8.5 addresses | |||
| the issue of ensuring that the transfers is encrypted between the two | the issue of ensuring that the transfers are encrypted between the | |||
| endpoints directly involved in the current transfers. The following | two endpoints directly involved in the current transfers. The | |||
| table summarized the properties of a selection of the mechanisms | following table summarizes the properties of a selection of the | |||
| discussed in Section 10. The two letter acronyms for the properties | mechanisms discussed in Section 10. The two letter acronyms for the | |||
| are used below and (S) indicates the secondary and (P) indicates the | properties are used below and (S) indicates the secondary and (P) | |||
| primary. | indicates the primary. | |||
| +----------------+-------+-------+-------+-------+-------+-------+ | +================+=======+=======+=======+=======+=======+=======+ | |||
| | Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) | | | Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) | | |||
| +----------------+-------+-------+-------+-------+-------+-------+ | +================+=======+=======+=======+=======+=======+=======+ | |||
| | Strict TLS | | Y | Y | | Y | | | | Strict TLS | | Y | Y | | Y | | | |||
| +----------------+-------+-------+-------+-------+-------+-------+ | ||||
| | Mutual TLS | | Y | Y | | Y | Y | | | Mutual TLS | | Y | Y | | Y | Y | | |||
| +----------------+-------+-------+-------+-------+-------+-------+ | ||||
| | ACL on primary | | | | | | Y | | | ACL on primary | | | | | | Y | | |||
| +----------------+-------+-------+-------+-------+-------+-------+ | ||||
| | TSIG | Y | | | Y | | | | | TSIG | Y | | | Y | | | | |||
| +----------------+-------+-------+-------+-------+-------+-------+ | +----------------+-------+-------+-------+-------+-------+-------+ | |||
| Table 1 | ||||
| Table 1: Properties of Authentication methods for XoT | Table 1: Properties of Authentication methods for XoT | |||
| Based on this analysis it can be seen that: | Based on this analysis it can be seen that: | |||
| o Using just mutual TLS can be considered a standalone solution | * Using just mutual TLS can be considered a standalone solution | |||
| since both end points are authenticated | since both end points are cryptographically authenticated | |||
| o Using Strict TLS and an IP based ACL on the primary also provides | * Using secondary side Strict TLS with a primary side IP ACL and | |||
| authentication of both end points | TSIG/SIG(0) combination provides sufficient protection to be | |||
| acceptable. | ||||
| o Additional use of TSIG (or equally SIG(0)) can also provide data | Using just an IP ACL could be susceptible to attacks that can spoof | |||
| origin authentication which might be desirable for deployments | TCP IP addresses, using TSIG/SIG(0) alone could be susceptible to | |||
| that include a proxy between the secondary and primary, but is not | attacks that were able to capture such messages should they be | |||
| part of the XoT requirement because it does nothing to guarantee | accidentally sent in clear text by any server with the key. | |||
| channel confidentiality or authentication. | ||||
| 12. Policies for Both AXoT and IXoT | 12. Policies for Both AXoT and IXoT | |||
| Whilst the protection of the zone contents in a transfer between two | Whilst the protection of the zone contents in a transfer between two | |||
| end points can be provided by the XoT protocol, the protection of all | end points can be provided by the XoT protocol, the protection of all | |||
| the transfers of a given zone requires operational administration and | the transfers of a given zone requires operational administration and | |||
| policy management. | policy management. | |||
| We call the entire group of servers involved in XFR for a particular | We call the entire group of servers involved in XFR for a particular | |||
| set of zones (all the primaries and all the secondaries) the | set of zones (all the primaries and all the secondaries) the | |||
| 'transfer group'. | 'transfer group'. | |||
| Within any transfer group both AXFRs and IXFRs for a zone MUST all | ||||
| use the same policy, e.g., if AXFRs use AXoT then all IXFRs MUST use | ||||
| IXoT. | ||||
| In order to assure the confidentiality of the zone information, the | In order to assure the confidentiality of the zone information, the | |||
| entire transfer group MUST have a consistent policy of requiring | entire transfer group MUST have a consistent policy of using XoT. If | |||
| confidentiality. If any do not, this is a weak link for attackers to | any do not, this is a weak link for attackers to exploit. For | |||
| exploit. | clarification, this means that within any transfer group both AXFRs | |||
| and IXFRs for a zone MUST all use XoT. | ||||
| An individual zone transfer is not considered protected by XoT unless | An individual zone transfer is not considered protected by XoT unless | |||
| both the client and server are configured to use only XoT and the | both the client and server are configured to use only XoT and the | |||
| overall zone transfer is not considered protected until all members | overall zone transfer is not considered protected until all members | |||
| of the transfer group are configured to use only XoT with all other | of the transfer group are configured to use only XoT with all other | |||
| transfers servers (see Section 13). | transfers servers (see Section 13). | |||
| A XoT policy should specify | A XoT policy MUST specify if | |||
| o What kind of TLS is required (Strict or Mutual TLS) | * mutual TLS is used and/or | |||
| o or if an IP based ACL is required. | * a IP ACL and TSIG/SIG(0) combination is used | |||
| o (optionally) if TSIG/SIG(0) is required | ||||
| Since this may require configuration of a number of servers who may | Since this may require configuration of a number of servers who may | |||
| be under the control of different operators the desired consistency | be under the control of different operators the desired consistency | |||
| could be hard to enforce and audit in practice. | could be hard to enforce and audit in practice. | |||
| Certain aspects of the Policies can be relatively easily tested | Certain aspects of the Policies can be relatively easily tested | |||
| independently, e.g., by requesting zone transfers without TSIG, from | independently, e.g., by requesting zone transfers without TSIG, from | |||
| unauthorized IP addresses or over cleartext DNS. Other aspects such | unauthorized IP addresses or over cleartext DNS. Other aspects such | |||
| as if a secondary will accept data without a TSIG digest or if | as if a secondary will accept data without a TSIG digest or if | |||
| secondaries are using Strict as opposed to Opportunistic TLS are more | secondaries are using Strict as opposed to Opportunistic TLS are more | |||
| challenging. | challenging. | |||
| skipping to change at page 29, line 50 ¶ | skipping to change at page 31, line 20 ¶ | |||
| None. | None. | |||
| 16. Implementation Status | 16. Implementation Status | |||
| [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] This section records | [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] This section records | |||
| the status of known implementations of the protocol defined by this | the status of known implementations of the protocol defined by this | |||
| specification at the time of posting of this Internet-Draft, and is | specification at the time of posting of this Internet-Draft, and is | |||
| based on a proposal described in [RFC7942]. | based on a proposal described in [RFC7942]. | |||
| A summary of current behavior and implementation status can be found | A summary of current behavior and implementation status can be found | |||
| here: XoT implementation status [1] | here: XoT implementation status | |||
| (https://dnsprivacy.org/wiki/display/DP/ | ||||
| DNS+Privacy+Implementation+Status#DNSPrivacyImplementationStatus-XFR/ | ||||
| XoTImplementationstatus) | ||||
| Specific recent activity includes: | Specific recent activity includes: | |||
| 1. The 1.9.2 version of Unbound [2] includes an option to perform | 1. The 1.9.2 version of Unbound | |||
| AXoT (instead of AXFR-over-TCP). | (https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ | |||
| Changelog) includes an option to perform AXoT (instead of AXFR- | ||||
| over-TCP). | ||||
| 2. There are currently open pull requests against NSD to implement | 2. There are currently open pull requests against NSD to implement | |||
| 1. Connection re-use by default during XFR-over-TCP [3] | 1. Connection re-use by default during XFR-over-TCP | |||
| (https://github.com/NLnetLabs/nsd/pull/145) | ||||
| 2. Client side XoT [4] | 2. Client side XoT (https://github.com/NLnetLabs/nsd/pull/149) | |||
| 3. Version 9.17.7 of BIND contained an initial implementation of | 3. Version 9.17.7 of BIND contained an initial implementation of | |||
| DoT, implementation of XoT is planned for early 2021 [5] | DoT, implementation of XoT is planned for early 2021 | |||
| (https://gitlab.isc.org/isc-projects/bind9/-/issues/1784) | ||||
| Both items 1. and 2.2. listed above require the client (secondary) to | Both items 1. and 2.2. listed above require the client (secondary) to | |||
| authenticate the server (primary) using a configured authentication | authenticate the server (primary) using a configured authentication | |||
| domain name if XoT is used. | domain name if XoT is used. | |||
| 17. Security Considerations | 17. Security Considerations | |||
| This document specifies a security measure against a DNS risk: the | This document specifies a security measure against a DNS risk: the | |||
| risk that an attacker collects entire DNS zones through eavesdropping | risk that an attacker collects entire DNS zones through eavesdropping | |||
| on clear text DNS zone transfers. | on clear text DNS zone transfers. | |||
| This does not mitigate: | This does not mitigate: | |||
| o the risk that some level of zone activity might be inferred by | * the risk that some level of zone activity might be inferred by | |||
| observing zone transfer sizes and timing on encrypted connections | observing zone transfer sizes and timing on encrypted connections | |||
| (even with padding applied), in combination with obtaining SOA | (even with padding applied), in combination with obtaining SOA | |||
| records by directly querying authoritative servers. | records by directly querying authoritative servers. | |||
| o the risk that hidden primaries might be inferred or identified via | * the risk that hidden primaries might be inferred or identified via | |||
| observation of encrypted connections. | observation of encrypted connections. | |||
| o the risk of zone contents being obtained via zone enumeration | * the risk of zone contents being obtained via zone enumeration | |||
| techniques. | techniques. | |||
| Security concerns of DoT are outlined in [RFC7858] and [RFC8310]. | Security concerns of DoT are outlined in [RFC7858] and [RFC8310]. | |||
| 18. Acknowledgements | 18. Acknowledgements | |||
| The authors thank Tony Finch, Benno Overeinder, Shumon Huque and Tim | The authors thank Tony Finch, Benno Overeinder, Shumon Huque and Tim | |||
| Wicinski and many other members of DPRIVE for review and discussions. | Wicinski and many other members of DPRIVE for review and discussions. | |||
| The authors particularly thank Peter van Dijk, Ondrej Sury, Brian | The authors particularly thank Peter van Dijk, Ondrej Sury, Brian | |||
| skipping to change at page 31, line 18 ¶ | skipping to change at page 32, line 43 ¶ | |||
| Han Zhang | Han Zhang | |||
| Salesforce | Salesforce | |||
| San Francisco, CA | San Francisco, CA | |||
| United States | United States | |||
| Email: hzhang@salesforce.com | Email: hzhang@salesforce.com | |||
| 20. Changelog | 20. Changelog | |||
| [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] | ||||
| draft-ietf-dprive-xfr-over-tls-12 | ||||
| * Changes from IESG review | ||||
| * Add section 8.1 on the requirement to use the DoT ALPN | ||||
| * Modify the one of the options for validation of a client from just | ||||
| an IP ACL to a combination of IP ACL and TSIG/SIG(0) | ||||
| - Update Abstract and Introduction with clear descriptions of how | ||||
| earlier specifications are updated | ||||
| - Add reference on NSEC3 attacks | ||||
| - Justify use of SHOULD in sections 7.3.2 and 7.3.3. | ||||
| - Clarify the Appendix is non-normative | ||||
| - Numerous typos and editorial improvements. | ||||
| - Use xml2rfc v3 (some format changes occur as a result) | ||||
| draft-ietf-dprive-xfr-over-tls-11 | ||||
| * Fix definition update missed in -10 | ||||
| draft-ietf-dprive-xfr-over-tls-10 | ||||
| * Address issued raised from IETF Last Call | ||||
| draft-ietf-dprive-xfr-over-tls-09 | draft-ietf-dprive-xfr-over-tls-09 | |||
| o Address issued raised in the AD review | * Address issued raised in the AD review | |||
| draft-ietf-dprive-xfr-over-tls-08 | draft-ietf-dprive-xfr-over-tls-08 | |||
| o RFC2845 -> (obsoleted by) RFC8945 | * RFC2845 -> (obsoleted by) RFC8945 | |||
| o I-D.ietf-dnsop-dns-zone-digest -> RFC8976 | * I-D.ietf-dnsop-dns-zone-digest -> RFC8976 | |||
| o Minor editorial changes + email update | * Minor editorial changes + email update | |||
| draft-ietf-dprive-xfr-over-tls-07 | draft-ietf-dprive-xfr-over-tls-07 | |||
| o Reference RFC7942 in the implementation status section | * Reference RFC7942 in the implementation status section | |||
| o Convert the URIs that will remain on publication to references | * Convert the URIs that will remain on publication to references | |||
| o Correct typos in acknowledgments | * Correct typos in acknowledgments | |||
| draft-ietf-dprive-xfr-over-tls-06 | draft-ietf-dprive-xfr-over-tls-06 | |||
| o Update text relating to pipelining and connection reuse after WGLC | * Update text relating to pipelining and connection reuse after WGLC | |||
| comments. | comments. | |||
| o Add link to implementation status matrix | * Add link to implementation status matrix | |||
| * Various typos | ||||
| o Various typos | ||||
| draft-ietf-dprive-xfr-over-tls-05 | draft-ietf-dprive-xfr-over-tls-05 | |||
| o Remove the open questions that received no comments. | * Remove the open questions that received no comments. | |||
| o Add more detail to the implementation section | * Add more detail to the implementation section | |||
| o Add Github repository | ||||
| o Fix typos and references and improve layout. | draft-ietf-dprive-xfr-over-tls-04 | |||
| * Add Github repository | ||||
| * Fix typos and references and improve layout. | ||||
| draft-ietf-dprive-xfr-over-tls-03 | draft-ietf-dprive-xfr-over-tls-03 | |||
| o Remove propose to use ALPN | * Remove propose to use ALPN | |||
| o Clarify updates to both RFC1995 and RFC5936 by adding specific | * Clarify updates to both RFC1995 and RFC5936 by adding specific | |||
| sections on this | sections on this | |||
| o Add a section on the threat model | * Add a section on the threat model | |||
| o Convert all SVG diagrams to ASCII art | * Convert all SVG diagrams to ASCII art | |||
| o Add discussions on concurrency limits | * Add discussions on concurrency limits | |||
| o Add discussions on Extended DNS error codes | * Add discussions on Extended DNS error codes | |||
| o Re-work authentication requirements and discussion | * Re-work authentication requirements and discussion | |||
| o Add appendix discussion TLS connection management | * Add appendix discussion TLS connection management | |||
| draft-ietf-dprive-xfr-over-tls-02 | draft-ietf-dprive-xfr-over-tls-02 | |||
| o Significantly update descriptions for both AXoT and IXoT for | * Significantly update descriptions for both AXoT and IXoT for | |||
| message and connection handling taking into account previous | message and connection handling taking into account previous | |||
| specifications in more detail | specifications in more detail | |||
| o Add use of APLN and limitations on traffic on XoT connections. | * Add use of APLN and limitations on traffic on XoT connections. | |||
| o Add new discussions of padding for both AXoT and IXoT | ||||
| o Add text on SIG(0) | * Add new discussions of padding for both AXoT and IXoT | |||
| o Update security considerations | * Add text on SIG(0) | |||
| o Move multi-primary considerations to earlier as they are related | * Update security considerations | |||
| * Move multi-primary considerations to earlier as they are related | ||||
| to connection handling | to connection handling | |||
| draft-ietf-dprive-xfr-over-tls-01 | draft-ietf-dprive-xfr-over-tls-01 | |||
| o Minor editorial updates | * Minor editorial updates | |||
| o Add requirement for TLS 1.3. or later | * Add requirement for TLS 1.3. or later | |||
| o Rename after adoption and reference update. | ||||
| o Add placeholder for SIG(0) discussion | draft-ietf-dprive-xfr-over-tls-00 | |||
| o Update section on ZONEMD | * Rename after adoption and reference update. | |||
| * Add placeholder for SIG(0) discussion | ||||
| * Update section on ZONEMD | ||||
| draft-hzpa-dprive-xfr-over-tls-02 | draft-hzpa-dprive-xfr-over-tls-02 | |||
| o Substantial re-work of the document. | * Substantial re-work of the document. | |||
| draft-hzpa-dprive-xfr-over-tls-01 | draft-hzpa-dprive-xfr-over-tls-01 | |||
| o Editorial changes, updates to references. | * Editorial changes, updates to references. | |||
| draft-hzpa-dprive-xfr-over-tls-00 | draft-hzpa-dprive-xfr-over-tls-00 | |||
| o Initial commit | * Initial commit | |||
| 21. References | [-@?I-D.ietf-tls-esni] | |||
| 21.1. Normative References | 21. Normative References | |||
| [I-D.ietf-dprive-rfc7626-bis] | [DoT-ALPN] IANA, "TLS Application-Layer Protocol Negotiation (ALPN) | |||
| Wicinski, T., "DNS Privacy Considerations", draft-ietf- | Protocol IDs", 2021, <https://www.iana.org/assignments/ | |||
| dprive-rfc7626-bis-08 (work in progress), October 2020. | tls-extensiontype-values/tls-extensiontype- | |||
| values.xhtml#alpn-protocol-ids>. | ||||
| [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | |||
| STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | |||
| <https://www.rfc-editor.org/info/rfc1034>. | <https://www.rfc-editor.org/info/rfc1034>. | |||
| [RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
| specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
| November 1987, <https://www.rfc-editor.org/info/rfc1035>. | November 1987, <https://www.rfc-editor.org/info/rfc1035>. | |||
| [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, | [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, | |||
| DOI 10.17487/RFC1995, August 1996, <https://www.rfc- | DOI 10.17487/RFC1995, August 1996, | |||
| editor.org/info/rfc1995>. | <https://www.rfc-editor.org/info/rfc1995>. | |||
| [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone | [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone | |||
| Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, | Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, | |||
| August 1996, <https://www.rfc-editor.org/info/rfc1996>. | August 1996, <https://www.rfc-editor.org/info/rfc1996>. | |||
| [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, <https://www.rfc- | DOI 10.17487/RFC2119, March 1997, | |||
| editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures | ||||
| ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September | ||||
| 2000, <https://www.rfc-editor.org/info/rfc2931>. | ||||
| [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol | [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol | |||
| (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, | (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, | |||
| <https://www.rfc-editor.org/info/rfc5936>. | <https://www.rfc-editor.org/info/rfc5936>. | |||
| [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | |||
| Morris, J., Hansen, M., and R. Smith, "Privacy | Morris, J., Hansen, M., and R. Smith, "Privacy | |||
| Considerations for Internet Protocols", RFC 6973, | Considerations for Internet Protocols", RFC 6973, | |||
| DOI 10.17487/RFC6973, July 2013, <https://www.rfc- | DOI 10.17487/RFC6973, July 2013, | |||
| editor.org/info/rfc6973>. | <https://www.rfc-editor.org/info/rfc6973>. | |||
| [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and | [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and | |||
| D. Wessels, "DNS Transport over TCP - Implementation | D. Wessels, "DNS Transport over TCP - Implementation | |||
| Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, | Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, | |||
| <https://www.rfc-editor.org/info/rfc7766>. | <https://www.rfc-editor.org/info/rfc7766>. | |||
| [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The | [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The | |||
| edns-tcp-keepalive EDNS0 Option", RFC 7828, | edns-tcp-keepalive EDNS0 Option", RFC 7828, | |||
| DOI 10.17487/RFC7828, April 2016, <https://www.rfc- | DOI 10.17487/RFC7828, April 2016, | |||
| editor.org/info/rfc7828>. | <https://www.rfc-editor.org/info/rfc7828>. | |||
| [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., | [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., | |||
| and P. Hoffman, "Specification for DNS over Transport | and P. Hoffman, "Specification for DNS over Transport | |||
| Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May | Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May | |||
| 2016, <https://www.rfc-editor.org/info/rfc7858>. | 2016, <https://www.rfc-editor.org/info/rfc7858>. | |||
| [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>. | |||
| [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles | [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles | |||
| for DNS over TLS and DNS over DTLS", RFC 8310, | for DNS over TLS and DNS over DTLS", RFC 8310, | |||
| DOI 10.17487/RFC8310, March 2018, <https://www.rfc- | DOI 10.17487/RFC8310, March 2018, | |||
| editor.org/info/rfc8310>. | <https://www.rfc-editor.org/info/rfc8310>. | |||
| [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
| Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
| <https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
| [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, | |||
| January 2019, <https://www.rfc-editor.org/info/rfc8499>. | January 2019, <https://www.rfc-editor.org/info/rfc8499>. | |||
| [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. | [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. | |||
| Lawrence, "Extended DNS Errors", RFC 8914, | Lawrence, "Extended DNS Errors", RFC 8914, | |||
| DOI 10.17487/RFC8914, October 2020, <https://www.rfc- | DOI 10.17487/RFC8914, October 2020, | |||
| editor.org/info/rfc8914>. | <https://www.rfc-editor.org/info/rfc8914>. | |||
| [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., | [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., | |||
| Gudmundsson, O., and B. Wellington, "Secret Key | Gudmundsson, O., and B. Wellington, "Secret Key | |||
| Transaction Authentication for DNS (TSIG)", STD 93, | Transaction Authentication for DNS (TSIG)", STD 93, | |||
| RFC 8945, DOI 10.17487/RFC8945, November 2020, | RFC 8945, DOI 10.17487/RFC8945, November 2020, | |||
| <https://www.rfc-editor.org/info/rfc8945>. | <https://www.rfc-editor.org/info/rfc8945>. | |||
| 21.2. Informative References | 22. Informative References | |||
| [BIND] ISC, "BIND 9", 2021, <https://www.isc.org/bind/>. | [BIND] ISC, "BIND 9.16.16", 2021, <https://www.isc.org/bind/>. | |||
| [I-D.ietf-dprive-dnsoquic] | [I-D.ietf-dprive-dnsoquic] | |||
| Huitema, C., Mankin, A., and S. Dickinson, "Specification | Huitema, C., Mankin, A., and S. Dickinson, "Specification | |||
| of DNS over Dedicated QUIC Connections", draft-ietf- | of DNS over Dedicated QUIC Connections", Work in Progress, | |||
| dprive-dnsoquic-01 (work in progress), October 2020. | Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February | |||
| 2021, <https://tools.ietf.org/html/draft-ietf-dprive- | ||||
| dnsoquic-02>. | ||||
| [I-D.ietf-dprive-phase2-requirements] | [I-D.ietf-dprive-phase2-requirements] | |||
| Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS | Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS | |||
| Privacy Requirements for Exchanges between Recursive | Privacy Requirements for Exchanges between Recursive | |||
| Resolvers and Authoritative Servers", draft-ietf-dprive- | Resolvers and Authoritative Servers", Work in Progress, | |||
| phase2-requirements-02 (work in progress), November 2020. | Internet-Draft, draft-ietf-dprive-phase2-requirements-02, | |||
| 2 November 2020, <https://tools.ietf.org/html/draft-ietf- | ||||
| dprive-phase2-requirements-02>. | ||||
| [I-D.ietf-dprive-rfc7626-bis] | ||||
| Wicinski, T., "DNS Privacy Considerations", Work in | ||||
| Progress, Internet-Draft, draft-ietf-dprive-rfc7626-bis- | ||||
| 09, 9 March 2021, <https://tools.ietf.org/html/draft-ietf- | ||||
| dprive-rfc7626-bis-09>. | ||||
| [I-D.ietf-tls-esni] | [I-D.ietf-tls-esni] | |||
| Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS | Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS | |||
| Encrypted Client Hello", draft-ietf-tls-esni-09 (work in | Encrypted Client Hello", Work in Progress, Internet-Draft, | |||
| progress), December 2020. | draft-ietf-tls-esni-10, 8 March 2021, | |||
| <https://tools.ietf.org/html/draft-ietf-tls-esni-10>. | ||||
| [I-D.vcelak-nsec5] | [I-D.vcelak-nsec5] | |||
| Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and | Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and | |||
| D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of | D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of | |||
| Existence", draft-vcelak-nsec5-08 (work in progress), | Existence", Work in Progress, Internet-Draft, draft- | |||
| December 2018. | vcelak-nsec5-08, 29 December 2018, | |||
| <https://tools.ietf.org/html/draft-vcelak-nsec5-08>. | ||||
| [nist-guide] | ||||
| Chandramouli, R. and S. Rose, "Secure Domain Name System | ||||
| (DNS) Deployment Guide", 2013, | ||||
| <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ | ||||
| NIST.SP.800-81-2.pdf>. | ||||
| [NSD] NLnet Labs, "NSD", 2021, | [NSD] NLnet Labs, "NSD 4.3.6", 2021, | |||
| <https://www.nlnetlabs.nl/projects/nsd/about/>. | <https://www.nlnetlabs.nl/projects/nsd/about/>. | |||
| [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, | [NSEC3-attacks] | |||
| DOI 10.17487/RFC1982, August 1996, <https://www.rfc- | Goldberf, S., Naor, N., Papadopoulos, D., Reyzin, L., | |||
| editor.org/info/rfc1982>. | Vasant, S., and A. Ziv, "Stretching NSEC3 to the Limit: | |||
| Efficient Zone Enumeration Attacks on NSEC3 Variants", | ||||
| 2015, | ||||
| <https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf>. | ||||
| [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures | [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, | |||
| ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September | DOI 10.17487/RFC1982, August 1996, | |||
| 2000, <https://www.rfc-editor.org/info/rfc2931>. | <https://www.rfc-editor.org/info/rfc1982>. | |||
| [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS | [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS | |||
| Security (DNSSEC) Hashed Authenticated Denial of | Security (DNSSEC) Hashed Authenticated Denial of | |||
| Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, | Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, | |||
| <https://www.rfc-editor.org/info/rfc5155>. | <https://www.rfc-editor.org/info/rfc5155>. | |||
| [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms | [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms | |||
| for DNS (EDNS(0))", STD 75, RFC 6891, | for DNS (EDNS(0))", STD 75, RFC 6891, | |||
| DOI 10.17487/RFC6891, April 2013, <https://www.rfc- | DOI 10.17487/RFC6891, April 2013, | |||
| editor.org/info/rfc6891>. | <https://www.rfc-editor.org/info/rfc6891>. | |||
| [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | |||
| Code: The Implementation Status Section", BCP 205, | Code: The Implementation Status Section", BCP 205, | |||
| RFC 7942, DOI 10.17487/RFC7942, July 2016, | RFC 7942, DOI 10.17487/RFC7942, July 2016, | |||
| <https://www.rfc-editor.org/info/rfc7942>. | <https://www.rfc-editor.org/info/rfc7942>. | |||
| [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS | [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS | |||
| (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, | (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, | |||
| <https://www.rfc-editor.org/info/rfc8484>. | <https://www.rfc-editor.org/info/rfc8484>. | |||
| [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. | [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. | |||
| Hardaker, "Message Digest for DNS Zones", RFC 8976, | Hardaker, "Message Digest for DNS Zones", RFC 8976, | |||
| DOI 10.17487/RFC8976, February 2021, <https://www.rfc- | DOI 10.17487/RFC8976, February 2021, | |||
| editor.org/info/rfc8976>. | <https://www.rfc-editor.org/info/rfc8976>. | |||
| 21.3. URIs | ||||
| [1] https://dnsprivacy.org/wiki/display/DP/ | ||||
| DNS+Privacy+Implementation+Status#DNSPrivacyImplementationStatus- | ||||
| XFR/XoTImplementationstatus | ||||
| [2] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ | ||||
| Changelog | ||||
| [3] https://github.com/NLnetLabs/nsd/pull/145 | ||||
| [4] https://github.com/NLnetLabs/nsd/pull/149 | ||||
| [5] https://gitlab.isc.org/isc-projects/bind9/-/issues/1784 | [nist-guide] | |||
| Chandramouli, R. and S. Rose, "Secure Domain Name System | ||||
| (DNS) Deployment Guide", 2013, | ||||
| <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ | ||||
| NIST.SP.800-81-2.pdf>. | ||||
| Appendix A. XoT server connection handling | Appendix A. XoT server connection handling | |||
| This appendix provides a non-normative outline of the pros and cons | ||||
| of XoT server connection handling options. | ||||
| For completeness, it is noted that an earlier version of the | For completeness, it is noted that an earlier version of the | |||
| specification suggested using a XoT specific ALPN to negotiate TLS | specification suggested using a XoT specific ALPN to negotiate TLS | |||
| connections that supported only a limited set of queries (SOA, XRFs) | connections that supported only a limited set of queries (SOA, XRFs), | |||
| however this did not gain support. Reasons given included additional | however, this did not gain support. Reasons given included | |||
| code complexity and proxies having no natural way to forward the ALPN | additional code complexity and the fact that XoT and ADoT are both | |||
| signal to DNS nameservers over TCP connections. | DNS wire format and so should share the "dot" ALPN. | |||
| A.1. Only listen on TLS on a specific IP address | A.1. Only listen on TLS on a specific IP address | |||
| Obviously a nameserver which hosts a zone and services queries for | Obviously a nameserver which hosts a zone and services queries for | |||
| the zone on an IP address published in an NS record may wish to use a | the zone on an IP address published in an NS record may wish to use a | |||
| separate IP address for listening on TLS for XoT, only publishing | separate IP address for listening on TLS for XoT, only publishing | |||
| that address to its secondaries. | that address to its secondaries. | |||
| Pros: Probing of the public IP address will show no support for TLS. | Pros: Probing of the public IP address will show no support for TLS. | |||
| ACLs will prevent zone transfer on all transports on a per query | ACLs will prevent zone transfer on all transports on a per query | |||
| skipping to change at page 37, line 43 ¶ | skipping to change at page 40, line 22 ¶ | |||
| Cons: Currently, none of the major open source DNS authoritative | Cons: Currently, none of the major open source DNS authoritative | |||
| implementations support such an option. | implementations support such an option. | |||
| A.3. SNI based TLS acceptance | A.3. SNI based TLS acceptance | |||
| Primaries could also choose to only accept TLS connections based on | Primaries could also choose to only accept TLS connections based on | |||
| an SNI that was published only to their secondaries. | an SNI that was published only to their secondaries. | |||
| Pros: Reduces the number of accepted connections. | Pros: Reduces the number of accepted connections. | |||
| Cons: As above. For SNIs sent in the clear, this would still allow | Cons: As above. Also, this is not a recommended use of SNI. For | |||
| attackers passively observing traffic to potentially abuse this | SNIs sent in the clear, this would still allow attackers passively | |||
| mechanism. The use of Encrypted Client Hello [I-D.ietf-tls-esni] may | observing traffic to potentially abuse this mechanism. The use of | |||
| be of use here. | Encrypted Client Hello [I-D.ietf-tls-esni] may be of use here. | |||
| A.4. TLS specific response policies | A.4. Transport specific response policies | |||
| Some primaries might rely on TSIG/SIG(0) combined with per-query IP | Some primaries might rely on TSIG/SIG(0) combined with per-query IP | |||
| based ACLs to authenticate secondaries. In this case the primary | based ACLs to authenticate secondaries. In this case the primary | |||
| must accept all incoming TLS connections and then apply a TLS | must accept all incoming TLS/TCP connections and then apply a | |||
| specific response policy on a per query basis. | transport-specific response policy on a per query basis. | |||
| As an aside, whilst [RFC7766] makes a general purpose distinction to | As an aside, whilst [RFC7766] makes a general purpose distinction in | |||
| clients in the usage of connections (between regular queries and zone | the advice to clients about their usage of connections (between | |||
| transfers) this is not strict and nothing in the DNS protocol | regular queries and zone transfers) this is not strict and nothing in | |||
| prevents using the same connection for both types of traffic. Hence | the DNS protocol prevents using the same connection for both types of | |||
| a server cannot know the intention of any client that connects to it, | traffic. Hence a server cannot know the intention of any client that | |||
| it can only inspect the messages it receives on such a connection and | connects to it, it can only inspect the messages it receives on such | |||
| make per query decisions about whether or not to answer those | a connection and make per-query decisions about whether or not to | |||
| queries. | answer those queries. | |||
| Example policies a XoT server might implement are: | Example policies a XoT server might implement are: | |||
| o strict: REFUSE all queries on TLS connections except SOA and | * strict: REFUSE all queries on TLS connections except SOA and | |||
| authorized XFR requests | authorized XFR requests | |||
| o moderate: REFUSE all queries on TLS connections until one is | * moderate: REFUSE all queries on TLS connections until one is | |||
| received that is signed by a recognized TSIG/SIG(0) key, then | received that is signed by a recognized TSIG/SIG(0) key, then | |||
| answer all queries on the connection after that | answer all queries on the connection after that | |||
| o complex: apply a heuristic to determine which queries on a TLS | * complex: apply a heuristic to determine which queries on a TLS | |||
| connections to REFUSE | connections to REFUSE | |||
| o relaxed: answer all non-XoT queries on all TLS connections with | * relaxed: answer all non-XoT queries on all TLS connections with | |||
| the same policy applied to TCP queries | the same policy applied to TCP queries | |||
| Pros: Allows for flexible behavior by the server that could be | Pros: Allows for flexible behavior by the server that could be | |||
| changed over time. | changed over time. | |||
| Cons: The server must handle the burden of accepting all TLS | Cons: The server must handle the burden of accepting all TLS | |||
| connections just to perform XFRs with a small number of secondaries. | connections just to perform XFRs with a small number of secondaries. | |||
| Client behavior to REFUSED response is not clearly defined (see | Client behavior to REFUSED response is not clearly defined (see | |||
| below). Currently, none of the major open source DNS authoritative | Section 8.8). Currently, none of the major open source DNS | |||
| implementations offer an option for different response policies in | authoritative implementations offer an option for different response | |||
| different transports (but could potentially be implemented using a | policies in different transports (but such functionality could | |||
| proxy). | potentially be implemented using a proxy). | |||
| A.4.1. SNI based response policies | A.4.1. SNI based response policies | |||
| In a similar fashion, XoT servers might use the presence of an SNI in | In a similar fashion, XoT servers might use the presence of an SNI in | |||
| the client hello to determine which response policy to initially | the client hello to determine which response policy to initially | |||
| apply to the TLS connections. | apply to the TLS connections. | |||
| Pros: This has to potential to allow a clean distinction between a | Pros: This has to potential to allow a clean distinction between a | |||
| XoT service and any future DoT based service for answering recursive | XoT service and any future DoT based service for answering recursive | |||
| queries. | queries. | |||
| Cons: As above. | Cons: As above. | |||
| Authors' Addresses | Authors' Addresses | |||
| Willem Toorop | Willem Toorop | |||
| NLnet Labs | NLnet Labs | |||
| Science Park 400 | Science Park 400 | |||
| Amsterdam 1098 XH | Amsterdam | |||
| The Netherlands | ||||
| Email: willem@nlnetlabs.nl | Email: willem@nlnetlabs.nl | |||
| Sara Dickinson | Sara Dickinson | |||
| Sinodun IT | Sinodun IT | |||
| Magdalen Centre | Magdalen Centre | |||
| Oxford Science Park | Oxford Science Park | |||
| Oxford OX4 4GA | Oxford | |||
| OX4 4GA | ||||
| United Kingdom | United Kingdom | |||
| Email: sara@sinodun.com | Email: sara@sinodun.com | |||
| Shivan Sahib | Shivan Sahib | |||
| Salesforce | Brave Software | |||
| Vancouver, BC | Vancouver, BC | |||
| Canada | Canada | |||
| Email: shivankaulsahib@gmail.com | Email: shivankaulsahib@gmail.com | |||
| Pallavi Aras | Pallavi Aras | |||
| Salesforce | Salesforce | |||
| Herndon, VA | Herndon, VA, | |||
| United States | United States | |||
| Email: paras@salesforce.com | Email: paras@salesforce.com | |||
| Allison Mankin | Allison Mankin | |||
| Salesforce | Salesforce | |||
| Herndon, VA | Herndon, VA, | |||
| United States | United States | |||
| Email: allison.mankin@gmail.com | Email: allison.mankin@gmail.com | |||
| End of changes. 254 change blocks. | ||||
| 602 lines changed or deleted | 695 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/ | ||||