[DNSOP] Last Call: (Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-04-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative for, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document deprecates the DS enrollment methods described in Section 3 of RFC 8078 in favor of Section 4 of this document, and also updates RFC 7344. [ Ed note: This document is being collaborated on at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/). The authors gratefully accept pull requests. ] The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Error Reporting' to Proposed Standard (draft-ietf-dnsop-dns-error-reporting-08.txt)
The IESG has approved the following document: - 'DNS Error Reporting' (draft-ietf-dnsop-dns-error-reporting-08.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ Technical Summary DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in RFC 8914. When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating recursive resolver to automatically signal an error to a monitoring agent specified by the authoritative server. Working Group Summary The WG worked together to address any and all issues. While the document had already undergone thorough review by both the WG and implementers, as indicated below, the WGLC period was extended by two weeks to include additional input from the WG before advancing the document to the IESG. All feedback has been further discussed on the mailing list and, if relevant, incorporated into the document. Document Quality In an early phase, proof-of-concept implementations of the I-D were realised during IETF Hackathons and interop tests were carried out. There are several implementations that have been in use for some time now. Personnel Benno Overeinder is DS! Warren "Ace" Kumari is RAD! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam (17:00 to 18:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## interim-2024-dnsop-01 ### Chairs * Benno Overeinder [be...@nlnetlabs.nl](be...@nlnetlabs.nl) * Suzanne Woolf [suzworldw...@gmail.com](suzworldw...@gmail.com) * Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com) ### IESG Overlord * Warren Kumari [war...@kumari.net](war...@kumari.net) ### Document Status * [Github](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md) * [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/) * [Propose Slides](https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/session/dnsop) ## Session interim-2024-dnsop-01 * Date: 30 January 2024 * Time: 17:00-18:00 UTC * [MeetEcho](https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f) * [Jabber](dn...@jabber.ietf.org) * [Zulip](https://zulip.ietf.org/#narrow/stream/dnsop) * [Minutes](https://notes.ietf.org/notes-ietf-interim-2024-dnsop-01-dnsop) ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### New Business * Presentation on state of DELEG draft. - 15 minutes * Legacy resolver compliance testing results. - 5 minutes * Open discussion points in the draft: - 10 minutes * Open Discussiontime for discussions - 20 minutes * IETF Process Time * BoF? New WG ? Another Hour Needed at next IETF Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f -- A calendar subscription for all dnsop meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Error Reporting) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Error Reporting' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-10-30. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in RFC 8914. When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating recursive resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Fragmentation Avoidance in DNS) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Fragmentation Avoidance in DNS' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-10-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract EDNS0 enables a DNS server to send large responses using UDP and is widely deployed. Large DNS/UDP responses are fragmented, and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting response size where possible, and signaling the need to upgrade from UDP to TCP transport where necessary. This document proposes techniques to avoid IP fragmentation in DNS. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8899: Packetization Layer Path MTU Discovery for Datagram Transports (Proposed Standard - Internet Engineering Task Force (IETF)) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Terminology' to Best Current Practice (draft-ietf-dnsop-rfc8499bis-10.txt)
The IESG has approved the following document: - 'DNS Terminology' (draft-ietf-dnsop-rfc8499bis-10.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ Technical Summary The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 8499 and updates RFC 2308. Working Group Summary This is a terminology document, and updates RFC8499. There were a number of terms (e.g sibling, in-bailiwick, lame-delegation) whose exact definitions involved significant discussion, and, eventually we determined that some terms are so vague (or are used differently by different people) that they should generally be avoided. Document Quality The document is well written and easy to read. Terminology documents are soul-crushing to write - much thanks to the authors for being willing to slog through this! Personnel Benno Overeinder is DS. Warren "Ace" Kumari is RAD (and easily amused) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Negative Caching of DNS Resolution Failures' to Proposed Standard (draft-ietf-dnsop-caching-resolution-failures-08.txt)
The IESG has approved the following document:
- 'Negative Caching of DNS Resolution Failures'
(draft-ietf-dnsop-caching-resolution-failures-08.txt) as Proposed Standard
This document is the product of the Domain Name System Operations Working
Group.
The IESG contact persons are Warren Kumari and Robert Wilton.
A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/
Technical Summary
In the DNS, resolvers employ caching to reduce both latency for end
users and load on authoritative name servers. The process of
resolution may result in one of three types of responses: (1) a
response containing the requested data; (2) a response indicating the
requested data does not exist; or (3) a non-response due to a
resolution failure in which the resolver does not receive any useful
information regarding the data's existence. This document concerns
itself only with the third type.
RFC 2308 specifies requirements for DNS negative caching. There,
caching of type (1) and (2) responses is mandatory and caching of
type (3) responses is optional. This document updates RFC 2308 to
require negative caching for DNS resolution failures.
RFC 4035 allows DNSSEC validation failure caching. This document
updates RFC 4035 to require caching for DNSSEC validation failures.
RFC 4697 prohibits aggressive requerying for NS records at a failed
zone's parent zone. This document updates RFC 4697 to expand this
requirement to all query types and to all ancestor zones.
Working Group Summary
While there was not much discussion on the document, what discussion there
was was supportive. The authors did a good job of addressing comments, and so
there was minimal / no drama...
Document Quality
This document specifies a behavior ("cache resolution failures, yo!") rather
than an exact specification. A number of implementations now follow this
behavior, but only one (ISC BIND) is documented to do so in the draft.
Personnel
Andrew McConachie is DS!
Warren "Ace" Kumari is RAD1!!1!1
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Terminology) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Terminology' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-09-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendicies A and B. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc882: Domain names: Concepts and facilities (Unknown - Legacy stream) rfc1912: Common DNS Operational and Configuration Errors (Informational - Legacy stream) rfc1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc2136: Dynamic Updates in the Domain Name System (DNS UPDATE) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc2308: Negative Caching of DNS Queries (DNS NCACHE) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4033: DNS Security Introduction and Requirements (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4034: Resource Records for the DNS Security Extensions (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4592: The Role of Wildcards in the Domain Name System (Proposed Standard - Internet Engineering Task Force (IETF)) rfc5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (Proposed Standard - Internet Engineering Task Force (IETF)) rfc5936: DNS Zone Transfer Protocol (AXFR) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc6561: Recommendations for the Remediation of Bots in ISP Networks (Informational - Internet Engineering Task Force (IETF)) rfc6781: DNSSEC Operational Practices, Version 2 (Informational - Internet Engineering Task Force (IETF)) rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc6841: A Framework for DNSSEC Policies and DNSSEC Practice Statements (Informational - Internet Engineering Task Force (IETF)) rfc7344: Automating DNSSEC Delegation Trust Maintenance (Proposed Standard - Internet Engineering Task Force (IETF)) rfc7719: DNS Terminology (Informational - Internet Engineering Task Force (IETF)) rfc8310: Usage Profiles for DNS over TLS and DNS over DTLS (Proposed Standard - Internet Engineering Task Force (IETF)) rfc9250: DNS over Dedicated QUIC Connections (Proposed Standard - Internet Engineering Task Force (IETF)) draft-ietf-dnsop-glue-is-not-optional: DNS Glue Requirements in Referral Responses (None - Internet Engineering Task Force (IETF)) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Negative Caching of DNS Resolution Failures) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Negative Caching of DNS Resolution Failures' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-08-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data; (2) a response indicating the requested data does not exist; or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type. RFC 2308 specifies requirements for DNS negative caching. There, caching of type (1) and (2) responses is mandatory and caching of type (3) responses is optional. This document updates RFC 2308 to require negative caching for DNS resolution failures. RFC 4035 allows DNSSEC validation failure caching. This document updates RFC 4035 to require caching for DNSSEC validation failures. RFC 4697 prohibits aggressive requerying for NS records at a failed zone's parent zone. This document updates RFC 4697 to expand this requirement to all query types and to all ancestor zones. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Glue Requirements in Referral Responses' to Proposed Standard (draft-ietf-dnsop-glue-is-not-optional-09.txt)
The IESG has approved the following document:
- 'DNS Glue Requirements in Referral Responses'
(draft-ietf-dnsop-glue-is-not-optional-09.txt) as Proposed Standard
This document is the product of the Domain Name System Operations Working
Group.
The IESG contact persons are Warren Kumari and Robert Wilton.
A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/
Technical Summary
The DNS uses glue records to allow iterative clients to find the
addresses of name servers that are contained within a delegated zone.
Authoritative Servers are expected to return all available glue
records for in-domain name servers in a referral response. If
message size constraints prevent the inclusion of all glue records
for in-domain name servers, the server MUST set the TC flag to inform
the client that the response is incomplete, and that the client
SHOULD use another transport to retrieve the full response. This
document updates RFC 1034 to clarify correct server behavior.
Working Group Summary
This document has been around for some time and has benefited from discussion
among multiple DNS protocol implementers. This doesn't represent a large number
of people but it does represent a major portion of those who will have to
implement and maintain the behavior described.
The most difficult point was differences in usage of some specific terminology
("bailiwick"). This was handled by eliminating use of the term here and adding
it to draft-ietf-dnsop-8499bis, which notes that the term is confusing and
should be considered historic.
Document Quality
This document has only very limited applicability to new implementations; it's
a clarification of a much older specification (RFC 1034). Implementers took
part in discussion of the draft and will be able to update their software where
it differs from the standard as clarified here.
Personnel
Suzanne Woolf is DS.
Warren "Ace" Kumari is RAD
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2023-06-20
The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2023-06-20 from 20:00 to 21:00 Europe/Amsterdam (18:00 to 19:00 UTC). Agenda: ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### Current Working Group Business * DNS Terminology and definition "lame delegation" - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ - WG Chairs, Paul Hoffman and Kazunori Fujiwara, 55 min - Chairs Action: Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=7e86a1ea-71f7-40c0-8c34-eb16a1a57a6e -- A calendar subscription for all dnsop meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'The ALT Special Use Top Level Domain' to Proposed Standard (draft-ietf-dnsop-alt-tld-25.txt)
The IESG has approved the following document: - 'The ALT Special Use Top Level Domain' (draft-ietf-dnsop-alt-tld-25.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ Technical Summary This document reserves a TLD label, "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces. Working Group Summary The WG consensus on the merits of the .alt proposal is reasonably strong. It deals with a fairly esoteric subject, so many participants in DNSOP didn't have strong views. No one thinks it's a perfect solution to the problem it describes. However, there's consensus that it's likely to help future protocol designers, potentially including some in the IETF and some outside. Regarding controversy, some participants felt it would not be appropriate for the IETF to consider a proposal that they believed was properly in the remit of ICANN as maintainer of the public DNS root zone. However, this was eventually solved by being appropriately restricted about the scope of the draft and the WG's job. The proposal relates only to protocols that are not the DNS, but use domain names; and there is a liaison relationship in place between the IETF and ICANN to handle any needed clarifications. The WG was only obligated to consider the proposal on the merits. During IETF LC, a liaison statement was sent to ICANN to inform them of the documents progress and to indicate how to provide comments during the last call process. After the IETF LC period had ended, a liaison response was received from ICANN, indicating that they appreciated the opportunity to comment on the document, but had no comments to make. Document Quality The document is short, well written, and likely pretty widely reviewed. The document quality is good. Personnel The Document Shepherd for this document is Suzanne Woolf. The Responsible Area Director is Robert Wilton. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Glue Requirements in Referral Responses) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Glue Requirements in Referral Responses' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-05-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone. Authoritative Servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)' to Proposed Standard (draft-ietf-dnsop-svcb-https-12.txt)
The IESG has approved the following document: - 'Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)' (draft-ietf-dnsop-svcb-https-12.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ Technical Summary This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Working Group Summary This was originally approved on 2022-05-25 and sent to the RFC Editor. However, it ended up stuck in MISREF state, stuck on draft-ietf-tls-esni , which we then learnt would be many months to progress. As the ECH reference was for an "optional feature", after discussions with the authors, WG, chairs, chairs of TLS, authors of ECH, authors of the other documents, IESG, etc we asked the RFC Editor to return the document. It has now had the ECH feature removed, had another WGLC, and IETF LC. It probably didn't need all of this process stuff, but I figured it is better to have transparency (and, yes, this is being coordinated with the documents that rely on *this* doc!) Please see the shepherd's writeup if this is confusing... Diff from the previously approved version: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11=draft-ietf-dnsop-svcb-https-12=--html We now return you to your regularly scheduled ballot text... Document Quality While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this. Personnel Document Shepherd (DS): Tim Wicinski Responsible Area Director (RAD!): Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-04-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Your attention please... This is a second IETF LC for this document - it was originally approved on 2022-05-25 and sent to the RFC Editor. However, it had a reference to a reference to a document (ECH in the TLS WG) which will still be many months in the making -- and other documents are now waiting on this document. As the ECH reference was for an "optional feature", after discussions with the authors, WG, chairs, chairs of TLS, authors of ECH, authors of the other documents, IESG, etc we asked the RFC Editor to return the document. It has now had the ECH feature removed, and has had another WGLC, and this is the IETF LC on the removal of the text. It probably didn't need all of this process stuff, but I figured it is better to have transparency (and, yes, this is being coordinated with the documents that rely on this doc!) Please see the shepherd's writeup if this is confusing... Diff from the previously approved version: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11=draft-ietf-dnsop-svcb-https-12=--html We now return you to your regularly scheduled LC text... Abstract This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (The ALT Special Use Top Level Domain) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'The ALT Special Use Top Level Domain' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-04-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document reserves a TLD label, "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces. [ This document is being collaborated on in Github at <https://github.com/wkumari/draft-wkumari-dnsop-alt-tld>. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. ] The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Catalog Zones' to Proposed Standard (draft-ietf-dnsop-dns-catalog-zones-09.txt)
The IESG has approved the following document: - 'DNS Catalog Zones' (draft-ietf-dnsop-dns-catalog-zones-09.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/ Technical Summary This document describes a method for automatic DNS zone provisioning among DNS primary and secondary nameservers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. Working Group Summary This document has been in development for many years, and has been widely implemented and deployed. There was very little controversy, and the WG support was good. The document has 7 authors (more than the recommended 5); this is intentional, as all made significant contributions. Document Quality Appendix A points out there are several implementations that interact successfully. These include: Knot DNS 3.1, PowerDNS version 4, BIND 9 Personnel Tim Wicinski is DS Warren Kumari is RAD ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Catalog Zones) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Catalog Zones' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-12-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a method for automatic DNS zone provisioning among DNS primary and secondary nameservers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Security Extensions (DNSSEC)' to Best Current Practice (draft-ietf-dnsop-dnssec-bcp-06.txt)
The IESG has approved the following document: - 'DNS Security Extensions (DNSSEC)' (draft-ietf-dnsop-dnssec-bcp-06.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/ Technical Summary This document describes DNSSEC (specified in RFC 4033, RFC 4034, RFC 4035 and others); one purpose is to introduce/collect all of the RFCs in one place to allow readers to understand the many aspects of DNSSEC (and more easily reference it!). Another purpose is to move DNSSEC to Best Current Practice status. Working Group Summary There was good consensus, with no major drama or controversy. Document Quality The document is of good quality, and very readable. There is no protocol or formal language. There are many implementations and deployment of DNSSEC, but they are not specific to, nor driven by the document. Personnel Tim Wicinski is DS Warren Kumari is RAD! (Yes, I did check the expiration date of this joke, and, no, it hasn't expired yet...) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC) to Informational RFC
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-10-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). This document obsoletes RFC 5933 and updates RFC 8624. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Security Extensions (DNSSEC)) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Security Extensions (DNSSEC)' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-10-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the DNS security extensions (commonly called "DNSSEC") that are specified RFCs 4033, 4034, 4035, and a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. Another purpose is to move DNSSEC to Best Current Practice status. This document is currently maintained at https://github.com/paulehoffman/draft-hoffman-dnssec. Issues and pull requests are welcomed. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5702: Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC (Proposed Standard - Internet Engineering Task Force (IETF)) rfc5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4034: Resource Records for the DNS Security Extensions (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4033: DNS Security Introduction and Requirements (Proposed Standard - Internet Engineering Task Force (IETF)) rfc3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) (Proposed Standard - Internet Engineering Task Force (IETF)) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2022-09-26
The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2022-09-26 from 17:00 to 18:00 Europe/Amsterdam (15:00 to 16:00 UTC). Agenda: The draft draft-ietf-dnsop-rfc8499bis is on the agenda for the interim meeting: - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=40f2f302-13a7-477b-b6fd-3d3d0754f05f ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Guidance for NSEC3 parameter settings' to Best Current Practice (draft-ietf-dnsop-nsec3-guidance-10.txt)
The IESG has approved the following document: - 'Guidance for NSEC3 parameter settings' (draft-ietf-dnsop-nsec3-guidance-10.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ Technical Summary This document provides guidance to operators on setting NSEC3 parameters. It is based on recent operational deployment experience. Working Group Summary Working group consensus took some time, as the discussion about what were the correct values to recommend. After iterative testing, recommended values were agreed via working group consensus. Document Quality There are existing implementations that are described in Appendix E. This section contains the number of iterations for these implementations. Personnel Tim Wicinski is the Document Shepherd. Warren Kumari is RAD! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)' to Proposed Standard (draft-ietf-dnsop-svcb-https-10.txt)
The IESG has approved the following document: - 'Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)' (draft-ietf-dnsop-svcb-https-10.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ Technical Summary This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Working Group Summary Working group consensus was strong, though it was rough in spots. During WGLC, discussions came up about the syntax of the records. The issues raised about the syntax was discussed in depth, and the issues raised were very much the rare exception rather than the rule. Syntax Discussion: https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/ WGLC thread: https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/ Document Quality While these are updates to existing standards, there is an implementation section where several versions of open source software has implemented this. Personnel Document Shepherd (DS): Tim Wicinski Responsible Area Director (RAD!): Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2022-05-24
The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2022-05-24 from 19:00 to 20:00 Europe/Amsterdam (17:00 to 18:00 UTC). Agenda: Agenda * Chairs, Administrivia (10 min) * Ulrich Wisser and Shumon Huque, DNSSEC Automation (25 min) https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/ * Peter Thomassen and Nils Wisiol, Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator (25 min) https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=45d75893-b015-4b13-b835-204c9de2b003 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Guidance for NSEC3 parameter settings) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Guidance for NSEC3 parameter settings' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2022-05-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract NSEC3 is a DNSSEC mechanism providing proof of non-existence by asserting that there are no names that exist between two domain names within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4470: Minimally Covering NSEC Records and DNSSEC On-line Signing (Proposed Standard - Internet Engineering Task Force (IETF)) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Transport over TCP - Operational Requirements' to Best Current Practice (draft-ietf-dnsop-dns-tcp-requirements-15.txt)
The IESG has approved the following document: - 'DNS Transport over TCP - Operational Requirements' (draft-ietf-dnsop-dns-tcp-requirements-15.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ Technical Summary This document clarifies and strengthens an existing protocol feature specified in RFC 1123 from a SHOULD to a MUST. The bulk of it is a justification of the MUST for implementers, and corresponding advice to operators that they use the feature. For many years it's been typical for DNS implementers to provide code for servicing DNS requests over TCP, but it has also been common for operators to turn it off; this document attempts to establish a best common practice for operators to only use DNS software that implements TCP support and to not disable the capability. Working Group Summary This document has been around in various forms for some time, and has been extensively reviewed in the WG by both protocol experts and DNS operators. THe authors are experienced DNS protocol designers and operators as well, and responded to every issue raised in the WG discussion over time. Document Quality This document clarifies and strengthens an existing protocol feature specified in RFC 1123 from a SHOULD to a MUST. The bulk of it is a justification of the MUST for implementers, and corresponding advice to operators that they use the feature. For many years it's been typical for DNS implementers to provide code for servicing DNS requests over TCP, but it has also been common for operators to turn it off; this document attempts to establish a best common practice for operators to only use DNS software that implements TCP support and to not disable the capability. Personnel Suzanne Woolf is the Document Shepherd Warren Kumari is RAD ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2021-12-15
The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2021-12-15 from 18:00 to 19:00 Europe/Amsterdam (17:00 to 18:00 UTC). Agenda: The draft DNS Terminology is the main topic on the agenda for the interim meeting: - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=d57b1252-6a56-4941-93a2-fc6e409b0eff ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2021-10-26
The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2021-10-26 from 14:00 to 15:00 UTC. Agenda: # DNS Operations (DNSOP) Working Group ## interim-2021-dnsop-02 ### Chairs * Benno Overeinder [be...@nlnetlabs.nl](be...@nlnetlabs.nl) * Suzanne Woolf [suzworldw...@gmail.com](suzworldw...@gmail.com) * Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com) ### IESG Overlord * Warren Kumari [war...@kumari.net](war...@kumari.net) ### Document Status * [Github](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md) * [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/) * [Propose Slides](https://datatracker.ietf.org/meeting/interim-2021-dnsop-02/session/dnsop) ## Session interim-2021-dnsop-02 * Date: 26 October 2021 * Time: 14:00-15:00 UTC * MeetEcho: [https://meetings.conf.meetecho.com/interim/?short=87d21aa3-6ff9-401f-b176-c3d3bde92ec4](https://meetings.conf.meetecho.com/interim/?short=87d21aa3-6ff9-401f-b176-c3d3bde92ec4) * Jabber: [dn...@jabber.ietf.org](dn...@jabber.ietf.org) * Minutes: [https://codimd.ietf.org/notes-ietf-interim-2021-dnsop-02-dnsop](https://codimd.ietf.org/notes-ietf-interim-2021-dnsop-02-dnsop) ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### Current Working Group Business * DNS Error Reporting - https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ - Roy Arends , 50 min - Chairs Action: Topics 1. Introduction: state of the I-D 2. Dependency on RFC8914 (Extended DNS Errors): State of implementation of EDE in various implementation 3. Issues and potential solutions - encapsulation of the erroneous domain - signalling EDE support Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=87d21aa3-6ff9-401f-b176-c3d3bde92ec4 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Revised IANA Considerations for DNSSEC' to Proposed Standard (draft-ietf-dnsop-dnssec-iana-cons-05.txt)
The IESG has approved the following document: - 'Revised IANA Considerations for DNSSEC' (draft-ietf-dnsop-dnssec-iana-cons-05.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ Technical Summary This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for DS records and NSEC3 parameters. It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to say that algorithms that are described in RFCs that are not on standards track are only at the "MAY" level of implementation recommendation. The rationale for these changes is to bring the requirements for DS records and for the hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. Working Group Summary There was a lot of debate and discussion when it was first introduced. There was a feeling that loosening the requirements on adding new DNSSEC algorithms would lead to algorithms not getting implemented, algorithms designed around national/"vanity" crypto, etc. This was resolved with some discussion. Document Quality The document changes the registration policy for an IANA registry, to better align with other registries. It is a process document and so there are no implementations, it is written appropriately for the intended audience, etc. Personnel Tim Wicinski is the DS Warren Kumari is RAD! (nope, still not old...) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Query Name Minimisation to Improve Privacy' to Proposed Standard (draft-ietf-dnsop-rfc7816bis-11.txt)
The IESG has approved the following document: - 'DNS Query Name Minimisation to Improve Privacy' (draft-ietf-dnsop-rfc7816bis-11.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ Technical Summary This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. Working Group Summary Working group consensus was strong; the document is describing a well known and deployed mechanism. After IETF LC, there was a concern raised that a comment may have been missed. The WG was asked to specifically consider and discuss this point (https://mailarchive.ietf.org/arch/msg/dnsop/6P6MS881ZdHnbtnwP7q8Q74_pw8/) After discussions, I determined that there was not sufficient consensus to make the change. Document Quality RFC7816 was published as Experimental - after significant deployment experience, data-collection and analysis, etc., we are obsoleting 7816, and publishing this new, Standards Track document. Personnel Tim Wicinski is Document Shepherd Warren Kumari is RAD! (This joke never gets old) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Revised IANA Considerations for DNSSEC) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Revised IANA Considerations for DNSSEC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-09-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for DS records and NSEC3 parameters. It also updates RFC 5155 and RFC 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to say that algorithms that are described in RFCs that are not on standards track are only at the "MAY" level of implementation recommendation. The rationale for these changes is to bring the requirements for DS records and for the hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2021-09-15 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2021-09-15 from 01:00 to 02:00 UTC. Agenda: The following drafts are on the agenda: * dnsop-avoid-fragmentation * dnsop-glue-is-not-optional Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=a910f22a-d46b-401f-be04-97c290437214 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2021-09-15
The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2021-09-15 from 01:00 to 02:00 UTC. Agenda: The following drafts are on the agenda: * dnsop-avoid-fragmentation * dnsop-glue-is-not-optional Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m2e714c1c1a5a29e532d47a7461a63e2d ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Transport over TCP - Operational Requirements) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Transport over TCP - Operational Requirements' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-09-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 1123. This document strongly encourages the operational practice of permitting DNS messages to be carried over TCP on the Internet as a best current practice. Such encouragement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP, as well as over an encrypted TLS session. The document also considers the consequences with this form of DNS communication and the potential operational issues that can arise when this best current practice is not upheld. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY (Proposed Standard - Internet Engineering Task Force (IETF)) rfc8490: DNS Stateful Operations (Proposed Standard - Internet Engineering Task Force (IETF)) rfc7873: Domain Name System (DNS) Cookies (Proposed Standard - Internet Engineering Task Force (IETF)) rfc7828: The edns-tcp-keepalive EDNS0 Option (Proposed Standard - Internet Engineering Task Force (IETF)) rfc7766: DNS Transport over TCP - Implementation Requirements (Proposed Standard - Internet Engineering Task Force (IETF)) rfc7477: Child-to-Parent Synchronization in DNS (Proposed Standard - Internet Engineering Task Force (IETF)) rfc6762: Multicast DNS (Proposed Standard - Internet Engineering Task Force (IETF)) rfc5936: DNS Zone Transfer Protocol (AXFR) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc2181: Clarifications to the DNS Specification (Proposed Standard - Internet Engineering Task Force (IETF)) rfc1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc1995: Incremental Zone Transfer in DNS (Proposed Standard - Internet Engineering Task Force (IETF)) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-08-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7871: Client Subnet in DNS Queries (Informational - Internet Engineering Task Force (IETF)) draft-ietf-tls-esni: TLS Encrypted Client Hello (None - Internet Engineering Task Force (IETF)) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'YANG Types for DNS Classes and Resource Record Types' to Proposed Standard (draft-ietf-dnsop-iana-class-type-yang-05.txt)
The IESG has approved the following document: - 'YANG Types for DNS Classes and Resource Record Types' (draft-ietf-dnsop-iana-class-type-yang-05.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ Technical Summary This document introduces the YANG module "iana-dns-class-rr-type" that contains derived types reflecting two IANA registries: DNS CLASSes and Resource Record (RR) TYPEs. These YANG types are intended as a minimum basis for future data modeling work. Working Group Summary There were several discussions during the working group process, but they were all resolved. Special attention is addressed to the IANA registration process, see also the IANA Considerations section. Instead of giving examples in the document, it is more procedural in its description. This has been chosen to ensure that, if there are changes in the IANA registration, the RFC does not give any obsolete examples and be misleading for software implementers who do not ultimately look at the IANA registry. Document Quality This document is seen as a fundamental building block for future RFCs in the DNSOP WG that intend to use YANG and NETCONF for DNS provisioning. The authors and the WG participants involved were well knowledgable with regard to YANG and NETCONF. The reviewers who have done a thorough review are Paul Wouters, Normen Kowalewski and Bob Harold, in addition to other DNSOP participants who have given the document during different phases feedback. There was also an early review by IANA. All seemed to be in order, but there were some comments about the XSLT stylesheet in Annex A, namely (not) remove it at the publication of the RFC. The authors/reviewers prefer to keep the XSLT-style sheet because they do not expect changes to the style sheet (and if so, it is appropriate to go through the IETF process again). It has been agreed to revisit this during the Last Call to see what others think. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'NSEC and NSEC3 TTLs and NSEC Aggressive Use' to Proposed Standard (draft-ietf-dnsop-nsec-ttl-05.txt)
The IESG has approved the following document: - 'NSEC and NSEC3 TTLs and NSEC Aggressive Use' (draft-ietf-dnsop-nsec-ttl-05.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ Technical Summary Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC(3) records may deny names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC(3) TTL to correct that situation. This document updates RFC 4034, RFC 4035, and RFC 5155. Working Group Summary Working group consensus was strong. Document Quality The document clearly describes the issues/lack of clarity in existing documents, and contains fixes. It updates a number of RFCs, and clearly states the original and replacement text. Personnel Document Shepherd: Tim Wicinski RAD: Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Query Name Minimisation to Improve Privacy) to Internet Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Query Name Minimisation to Improve Privacy' as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-06-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. This document is part of the IETF DNSOP (DNS Operations) Working Group. The source of the document, as well as a list of open issues, is at <https://framagit.org/bortzmeyer/rfc7816-bis> The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4851/ The document contains these normative downward references. See RFC 3967 for additional information: rfc7816: DNS Query Name Minimisation to Improve Privacy (Experimental - Internet Engineering Task Force (IETF)) rfc6973: Privacy Considerations for Internet Protocols (Informational - Internet Architecture Board (IAB)) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (YANG Types for DNS Classes and Resource Record Types) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'YANG Types for DNS Classes and Resource Record Types' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-05-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document introduces the YANG module "iana-dns-class-rr-type" that contains derived types reflecting two IANA registries: DNS CLASSes and Resource Record (RR) TYPEs. These YANG types are intended as a minimum basis for future data modeling work. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (NSEC and NSEC3 TTLs and NSEC Aggressive Use) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'NSEC and NSEC3 TTLs and NSEC Aggressive Use' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-05-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC and NSEC3 TTL to correct that situation. This document updates RFC 4034, RFC 4035, RFC 5155, and RFC 8198. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Interoperable Domain Name System (DNS) Server Cookies' to Proposed Standard (draft-ietf-dnsop-server-cookies-05.txt)
The IESG has approved the following document: - 'Interoperable Domain Name System (DNS) Server Cookies' (draft-ietf-dnsop-server-cookies-05.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ Technical Summary DNS cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism. This document provides precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients. Working Group Summary There were several discussions during the working group process, but they were all resolved. Document Quality The document was the result of different interpretations of the original RFC that cause some implementation issues. Appendix C points out there are several implementations that interact successfully. Personnel Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Interoperable Domain Name System (DNS) Server Cookies) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Interoperable Domain Name System (DNS) Server Cookies' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-12-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract DNS Cookies, as specified in [RFC7873], are a lightweight DNS transaction security mechanism that provide limited protection to DNS servers and clients against a variety of denial-of-service and amplification, forgery, or cache poisoning attacks by off-path attackers. This document provides precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients. This document updates [RFC7873] with * suggestions for constructing Client Cookies in a privacy preserving fashion, * precise instructions for constructing Server Cookies deprecating the methods described in [RFC7873], and * suggestions on how to update a server secret. An IANA registry listing the methods and associated pseudo random function suitable for creating DNS Server cookies is created, with the method described in this document as the first and as of yet only entry. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Message Digest for DNS Zones' to Proposed Standard (draft-ietf-dnsop-dns-zone-digest-14.txt)
The IESG has approved the following document: - 'Message Digest for DNS Zones' (draft-ietf-dnsop-dns-zone-digest-14.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari, Robert Wilton and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ Technical Summary: This document describes a protocol and new DNS Resource Record that can be used to provide a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the digest data in the zone itself. When a zone publisher includes an ZONEMD record, recipients can verify the zone contents for accuracy and completeness. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. Working Group Summary: There were several discussions during the working group process, but they were all resolved. The only other point raised was with the intended document status (currently Standards Track). Please see comments in Section 6 Document Quality: There have been implementations of the DNS record in several public domain DNS servers. However, because of the narrow use for this resource record, the shepherd does not feel that vendors will see the need to implement. More than one managed DNS vendor has indicated they see no need to implement. Personnel: Document Shepherd: Tim Wicinski Responsible Area Director: Barry Leiba ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Message Digest for DNS Zones) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Message Digest for DNS Zones' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a protocol and new DNS Resource Record that can be used to provide a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the digest data in the zone itself. When a zone publisher includes an ZONEMD record, recipients can verify the zone contents for accuracy and completeness. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. ZONEMD is not designed to replace DNSSEC. Whereas DNSSEC protects individual RRSets (DNS data with fine granularity), ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified at this time, ZONEMD is not designed for use in large, dynamic zones due to the time and resources required for digest calculation. The ZONEMD record described in this document is designed so that new digest schemes may be developed in the future to support large, dynamic zones. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Secret Key Transaction Authentication for DNS (TSIG)' to Internet Standard (draft-ietf-dnsop-rfc2845bis-09.txt)
The IESG has approved the following document: - 'Secret Key Transaction Authentication for DNS (TSIG)' (draft-ietf-dnsop-rfc2845bis-09.txt) as Internet Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ Technical Summary This document describes a protocol for DNS for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic DNS updates as coming from an approved client, or to authenticate responses as coming from an approved DNS name server. No recommendation is made here for distributing the shared secrets: it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism. The draft obsoletes RFC2845 and RFC4635. Working Group Summary The draft updates RFC2845, because due to some ambiguity in the wording of the document, different implementations made decisions that caused operational problems, see also Section 1.3. The draft was swiftly adopted to become a DNSOP WG document. After WG adoption, the authors of the original RFC2845 have also been added to the author list. The WG stated that the document was not just an errata, but a bis, so the document could improve the readability and wording of the protocol specification. Document Quality A recent implementation of RFC2845 used the rfc2845bis draft to implement TSIG. The new draft document is much clearer and offers better implementation guidance than the original. RFC2845 is implemented by all known open source DNS name servers and, as far as the shepherd knows, all commercial DNS name servers (not knowing for proprietary name servers). The implementer (Martin Hoffmann, NLnet Labs) has provided good feedback to improve the text of the rfc2845bis draft and to reorganize some sections. Other feedback from the working group has also been processed. Personnel Document Shepherd: Benno Overeinder Responsible Area Director: Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Extended DNS Errors' to Proposed Standard (draft-ietf-dnsop-extended-error-16.txt)
The IESG has approved the following document: - 'Extended DNS Errors' (draft-ietf-dnsop-extended-error-16.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari, Robert Wilton and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ Technical Summary This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Working Group Summary The document went through a rigorous consensus process, and there were several points which took a few iterations to resolve, but they were all resolved to strong approval from the working group. Document Quality There are no current implementations, but both software vendors and third party DNS providers are planning to implement these error codes now that the specifics have been agreed on. Personnel Document Shepherd: Tim Wicinski Responsible Area Director: Barry Leiba ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2020-04-23 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Domain Name System Operations (dnsop) Working Group will hold a virtual interim meeting on 2020-04-23 from 17:00 to 18:00 Europe/Amsterdam (15:00 to 16:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## interim-2020-dnsop-02 * Date: 23 April 2020 * Time: 1500 - 1600 UTC * Webex: https://ietf.webex.com/ietf/j.php?MTID=m8d49e59807a47eec1d8cf5fbd4f81fa3 ### * Jabber: dn...@jabber.ietf.org * EtherPad: https://etherpad.ietf.org/p/notes-ietf-interim-2020-dnsop-02?useMonospaceFont=true ### Chairs * Tim Wicinski tjw.i...@gmail.com * Suzanne Woolf suzworldw...@gmail.com * Benno Overeinder be...@nlnetlabs.nl ### IESG Overlord * Warren Kumari war...@kumari.net ### Document Status * https://github.com/DNSOP/wg-materials/blob/master/dnsop-document-status.md ### Datatracker * https://datatracker.ietf.org/wg/dnsop/documents/ # Agenda ## Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ## Current Working Group Business ### YANG Types for DNS Classes and Resource Record Types - https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ - Ladislav Lhotka, 10 min - Chairs Action: ### Interoperable Domain Name System (DNS) Server Cookies - https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ - Willem Toorop, 15min - Chairs Action: How close to WGLC? # ## New Working Group Business ### DNS TIMEOUT Resource Record - https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/ - Tom Pusateri/Tim Wattenberg, 15 min - Chairs Action: Adopt? ### Delegation Revalidation by DNS Resolvers - https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/ - Shumon Huque, 15 min - Chairs Action: ### Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC - https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ - Dmitry Belyavsky, 15min - Chairs Action: # ## Reference ### BlueSheets Attendees are asked to visit and enter your Name+Affiliation in the Blue-Sheet section of the DNSOP Etherpad. ### Mic Line Queue The Mic Line will use the WebEx chat channel. To get in the queue type q+ to leave type q-. Please dont type questions or other things into the WebEx chat channel as that will make managing the queue very hard for the chairs. Please use the Jabber channel for side conversations. When you connect into WebEx you should start off as auto-muted so youll need to unmute yourself to speak when called. ### Helpful Info Prep The IETF has prepared a couple of documents to help get everyone ready. https://www.ietf.org/how/meetings/107/session-participant-guide/ https://www.ietf.org/how/meetings/107/session-presenter-guide/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8d49e59807a47eec1d8cf5fbd4f81fa3. Meeting Id: 616 191 802 Meeting password: 3JNxacS23pS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2020-04-23 CHANGED
MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Domain Name System Operations (dnsop) Working Group will hold a virtual interim meeting on 2020-04-23 from 17:00 to 18:00 Europe/Amsterdam (15:00 to 16:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## interim-2020-dnsop-02 * Date: 23 April 2020 * Time: 1500 - 1600 UTC * Webex: https://ietf.webex.com/ietf/j.php?MTID=m8d49e59807a47eec1d8cf5fbd4f81fa3 ### * Jabber: dn...@jabber.ietf.org * EtherPad: https://etherpad.ietf.org/p/notes-ietf-interim-2020-dnsop-02?useMonospaceFont=true ### Chairs * Tim Wicinski tjw.i...@gmail.com * Suzanne Woolf suzworldw...@gmail.com * Benno Overeinder be...@nlnetlabs.nl ### IESG Overlord * Warren Kumari war...@kumari.net ### Document Status * https://github.com/DNSOP/wg-materials/blob/master/dnsop-document-status.md ### Datatracker * https://datatracker.ietf.org/wg/dnsop/documents/ # Agenda ## Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ## Current Working Group Business ### YANG Types for DNS Classes and Resource Record Types - https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ - Ladislav Lhotka, 10 min - Chairs Action: ### Interoperable Domain Name System (DNS) Server Cookies - https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ - Willem Toorop, 15min - Chairs Action: How close to WGLC? # ## New Working Group Business ### DNS TIMEOUT Resource Record - https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/ - Tom Pusateri/Tim Wattenberg, 15 min - Chairs Action: Adopt? ### Delegation Revalidation by DNS Resolvers - https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/ - Shumon Huque, 15 min - Chairs Action: ### Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC - https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ - Dmitry Belyavsky, 15min - Chairs Action: # ## Reference ### BlueSheets Attendees are asked to visit and enter your Name+Affiliation in the Blue-Sheet section of the DNSOP Etherpad. ### Mic Line Queue The Mic Line will use the WebEx chat channel. To get in the queue type q+ to leave type q-. Please dont type questions or other things into the WebEx chat channel as that will make managing the queue very hard for the chairs. Please use the Jabber channel for side conversations. When you connect into WebEx you should start off as auto-muted so youll need to unmute yourself to speak when called. ### Helpful Info Prep The IETF has prepared a couple of documents to help get everyone ready. https://www.ietf.org/how/meetings/107/session-participant-guide/ https://www.ietf.org/how/meetings/107/session-presenter-guide/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8d49e59807a47eec1d8cf5fbd4f81fa3. Meeting Id: 617846 Meeting password: 3JNxacS23pS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Document Action: 'Multi Signer DNSSEC models' to Informational RFC (draft-ietf-dnsop-multi-provider-dnssec-05.txt)
The IESG has approved the following document: - 'Multi Signer DNSSEC models' (draft-ietf-dnsop-multi-provider-dnssec-05.txt) as Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/ Technical Summary The draft documents operational models for deploying DNSSEC signed zones across multiple DNS providers to distribute their authoritative DNS service. It presents challenges depending on the configuration and feature set in use, and presents several deployment models that may be suitable. Working Group Summary The document has been reviewed and discussed on the DNSOP mailing list and during DNSOP workgroup meetings. Contributions were done by a relative small number of interested folks, feedback by the WG was promptly integrated in the document. No points of difficulty or controversy appeared and consensus was quick. There has been good consensus during the WGLC period. External parties (DNS zone owners and DNS providers) have architected the DNSSEC multi-provider model in their operations and use it in their daily job (e.g., see DNSOP mailing list, email thread “[DNSOP] Working Group Last Call for draft-ietf-dnsop-multi-provider-dnssec”.) Document Quality The document is of good quality, and describes a real issue and (real world) operational advice on how to deal with this. The security section mentions the need for strong authentication to protect DNSSEC key material, but although the usefulness of the warning, this is beyond the scope of the document. The document shepherd has no specific concerns or issues with the document or with the WG process. The shepherd stands behind the document and thinks the document is ready for publication. Personnel Document Shepherd: Benno Overeinder Area Director: Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2020-04-23
The Domain Name System Operations (dnsop) Working Group will hold a virtual interim meeting on 2020-04-23 from 17:00 to 18:00 Europe/Amsterdam (15:00 to 16:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## interim-2020-dnsop-02 * Date: 23 April 2020 * Time: * Webex: ### * Jabber: dn...@jabber.ietf.org * EtherPad: ### Chairs * Tim Wicinski tjw.i...@gmail.com * Suzanne Woolf suzworldw...@gmail.com * Benno Overeinder be...@nlnetlabs.nl ### IESG Overlord * Warren Kumari war...@kumari.net ### Document Status * https://github.com/DNSOP/wg-materials/blob/master/dnsop-document-status.md ### Datatracker * https://datatracker.ietf.org/wg/dnsop/documents/ # Agenda ## Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ## Current Working Group Business ### YANG Types for DNS Classes and Resource Record Types - https://datatracker.ietf.org/doc/draft-ietf-dnsop-iana-class-type-yang/ - Ladislav Lhotka, 10 min - Chairs Action: ### Interoperable Domain Name System (DNS) Server Cookies - https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ - Willem Toorop, 15min - Chairs Action: How close to WGLC? # ## New Working Group Business ### DNS TIMEOUT Resource Record - https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/ - Tom Pusateri/Tim Wattenberg, 15 min - Chairs Action: Adopt? ### Delegation Revalidation by DNS Resolvers - https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/ - Shumon Huque, 15 min - Chairs Action: # ## Reference ### BlueSheets Attendees are asked to visit and enter your Name+Affiliation in the Blue-Sheet section of the DNSOP Etherpad. ### Mic Line Queue The Mic Line will use the WebEx chat channel. To get in the queue type q+ to leave type q-. Please don't type questions or other things into the WebEx chat channel as that will make managing the queue very hard for the chairs. Please use the Jabber channel for side conversations. When you connect into WebEx you should start off as auto-muted so you'll need to unmute yourself to speak when called. ### Helpful Info & Prep The IETF has prepared a couple of documents to help get everyone ready. https://www.ietf.org/how/meetings/107/session-participant-guide/ https://www.ietf.org/how/meetings/107/session-presenter-guide/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m8d49e59807a47eec1d8cf5fbd4f81fa3 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'A Common Operational Problem in DNS Servers - Failure To Communicate' to Best Current Practice (draft-ietf-dnsop-no-response-issue-20.txt)
The IESG has approved the following document: - 'A Common Operational Problem in DNS Servers - Failure To Communicate' (draft-ietf-dnsop-no-response-issue-20.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ Technical Summary Failing to respond to DNS queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of DNS queries which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem. Working Group Summary The document initially prescribed remediation for failing to respond correctly. After much working group debate, this wording was removed and the document focused on documenting the failure scenarios. Document Quality Document quality is good and has been through several reviews. Comments raised at IETF LC were addressed. Personnel Document Shepherd: Tim Wicinski Responsible Area Director: Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2020-04-14
The Domain Name System Operations (dnsop) Working Group will hold a virtual interim meeting on 2020-04-14 from 16:00 to 18:00 Europe/Amsterdam (14:00 to 16:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## IETF 107 * Date: April 14, 2020 * Time: 14:00 UTC * Webex: https://ietf.webex.com/ietf/j.php?MTID=m706bba8b48e3db3db02d72f0941b2630 ### * Jabber: * EtherPad: <https://etherpad.ietf.org:9009/p/interim-2020-dnsop-01> ### Chairs * Tim Wicinski * Suzanne Woolf * Benno Overeinder ### IESG Overlord * Warren Kumari ### Document Status * <https://github.com/DNSOP/wg-materials/blob/master/dnsop-document-status.md> ### Datatracker * <https://datatracker.ietf.org/wg/dnsop/documents/> # Agenda ## Administrivia * Agenda Bashing, Blue Sheets, etc, 10 min * Updates of Old Work, Chairs, 10 min ## Current Working Group Business ### Service binding and parameter specification via the DNS - <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-httpssvc/> - Eric Nygren, 15 min - Chairs Action: ? ### DNS Query Name Minimisation to Improve Privacy (bis) - <https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/> - Ralph Dolmans, 15min - Chairs Action: How close to WGLC? # ## New Working Group Business ### Avoid IP fragmentation in DNS - <https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/> - Kazunori Fujiwara, 15 min - Chairs Action: Adopt? ### The Delegation_Only DNSKEY flag - <https://tools.ietf.org/html/draft-pwouters-powerbind-03> - Paul Wouters, 10 min - Chairs Action: Adopt? ### Parameterized Nameserver Delegation with NS2 and NS2T - <https://datatracker.ietf.org/doc/draft-tapril-ns2/> - Tim April, 15 min - Chairs Action: ### DNS Catalog Zones - <https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/> - Willem Toorop, 15 min - Chairs Action: ### A Data Model for configuring Domain Name System (DNS) Zone Provisioning on Authoritative Nameservers - <https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-zone-provisioning-yang/> - Willem Toorop, 15 min - Chairs Action: # ## Reference ### BlueSheets Attendees are asked to visit and enter your Name+Affiliation in the Blue-Sheet section of the DNSOP Etherpad. ### Mic Line Queue The Mic Line will use the WebEx chat channel. To get in the queue type q+ to leave type q-. Please don’t type questions or other things into the WebEx chat channel as that will make managing the queue very hard for the chairs. Please use the Jabber channel for side conversations. When you connect into WebEx you should start off as auto-muted so you’ll need to unmute yourself to speak when called. ### Helpful Info & Prep The IETF has prepared a couple of documents to help get everyone ready, including a reminder that you need to register for IETF107 as a remote participant to join remotely. <https://www.ietf.org/how/meetings/107/session-participant-guide/> <https://www.ietf.org/how/meetings/107/session-presenter-guide/> Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m706bba8b48e3db3db02d72f0941b2630 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Document Action: 'Running a Root Server Local to a Resolver' to Informational RFC (draft-ietf-dnsop-7706bis-12.txt)
The IESG has approved the following document: - 'Running a Root Server Local to a Resolver' (draft-ietf-dnsop-7706bis-12.txt) as Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari, Barry Leiba and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/ Technical Summary: This document shows how to start and maintain a local copy of the root zone that reduces round-trip times for certain queries, reduces the risk of third-party observation of DNS queries and responses, and does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. It updates RFC 7706 with additional operator experience in using the described techniques. Working Group Summary: The original RFC 7706 was published in 2015 as guidance to resolver operators to help them provide local resolution of lookups in the root zone, which has become increasingly popular as a resiliency mechanism for DNS operations, but which can also lead to new failures that might be difficult to troubleshoot. The technique was largely undocumented at the time. The WG expected that a -bis document would be useful with more experience, and has been correct in this assessment, so insight from that further experience is presented here. The WG has thoroughly discussed the document and both authors have been responsive and accurate in their work on it. Document Quality: The document is based on RFC 7706 and clearly states the premise for going beyond it-- 7706 specified one mechanism, local root server on loopback, for the local root cache; 7706bis discusses others, including operational requirements for configuration to provide the desired service and avoid the pitfalls. Personnel: Shepherd: Suzanne Woolf AD: Barry Leiba ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Extended DNS Errors) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Extended DNS Errors' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-04-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Multi Signer DNSSEC models) to Informational RFC
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Multi Signer DNSSEC models' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-03-31. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key management mechanisms are necessitated. This document presents deployment models that accommodate this scenario and describe these key management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key management requirements on authoritative servers not involved in multi signer configurations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Running a Root Server Local to a Resolver) to Informational RFC
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Running a Root Server Local to a Resolver' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-02-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-kh-dnsop-7706bis. The most recent version of the document, open issues, and so on should all be available there. The authors gratefully accept pull requests. ] The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Secret Key Transaction Authentication for DNS (TSIG)) to Internet Standard
[ Note to readers: Section 10.1 ("Issue Fixed in this Document") is useful to
understand the reason for this document. I'm asking the authors to please put a
pointer (or similar) to this in the abstract. ]
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Secret Key Transaction
Authentication for DNS (TSIG)'
as Internet Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-01-21. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
This document describes a protocol for transaction level
authentication using shared secrets and one way hashing. It can be
used to authenticate dynamic updates as coming from an approved
client, or to authenticate responses as coming from an approved name
server.
No recommendation is made here for distributing the shared secrets:
it is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism.
This document obsoletes RFC2845 and RFC4635.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ballot/
No IPR declarations have been submitted directly on this I-D.
The document contains these normative downward references.
See RFC 3967 for additional information:
rfc4635: HMAC SHA (Hashed Message Authentication Code, Secure Hash
Algorithm) TSIG Algorithm Identifiers (Proposed Standard - IETF stream)
rfc2845: Secret Key Transaction Authentication for DNS (TSIG) (Proposed
Standard - IETF stream)
rfc3597: Handling of Unknown DNS Resource Record (RR) Types (Proposed
Standard - IETF stream)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Serving Stale Data to Improve DNS Resiliency' to Proposed Standard (draft-ietf-dnsop-serve-stale-10.txt)
The IESG has approved the following document: - 'Serving Stale Data to Improve DNS Resiliency' (draft-ietf-dnsop-serve-stale-10.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari, Ignas Bagdonas and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ Technical Summary This draft defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. It updates the definition of TTL from RFCs 1034, 1035, and 2181 to make it clear that data can be kept in the cache beyond the TTL expiry and used for responses when a refreshed answer is not readily available. Working Group Summary This draft dates to March 2017 and was adopted by DNSOP in October 2017. It's been extensively reviewed in the WG. The primary point of controversy was that it discusses an optional protocol change (the choice by a recursive resolver to re-use data beyond the authoritative server TTL when no refresh is available) that some WG participants felt to be unwise under some conditions. The discussion of timer values in Sec. 5, and of implementation decisions and caveats in Sec. 6 and Sec. 7, seem to address these concerns. Since this protocol modification is widely implemented and deployed, having a standards track description seemed to promote careful practice and interoperability. Document Quality The protocol update discussed in this draft is an attempt to document behavior that is implemented in multiple open source DNS codebases and deployed by a number of large operators, including DNS services and CDNs that rely on the specified DNS behavior. Common practice regarding the handling of TTLs by recursive resolvers has changed considerably over the behavior originally specified, and documenting the current practice as an update to the protocol seems likely to promote interoperability and transparency under both normal and adverse conditions. Personnel Suzanne Woolf (shepherd) Barry Leiba (AD) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'A Common Operational Problem in DNS Servers - Failure To Communicate.' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2019-12-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNS is a query / response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem. The document does not look at the DNS data itself, just the structure of the responses. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) (Proposed Standard - IETF stream) rfc3225: Indicating Resolver Support of DNSSEC (Proposed Standard - IETF stream) rfc7766: DNS Transport over TCP - Implementation Requirements (Proposed Standard - IETF stream) rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - IETF stream) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Moving DNSSEC Lookaside Validation (DLV) to Historic Status' to Proposed Standard (draft-ietf-dnsop-obsolete-dlv-02.txt)
The IESG has approved the following document: - 'Moving DNSSEC Lookaside Validation (DLV) to Historic Status' (draft-ietf-dnsop-obsolete-dlv-02.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-obsolete-dlv/ Technical Summary This document obsoletes DNSSEC lookaside validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. It is a supporting document for https://datatracker.ietf.org/doc/status-change-dlv-to-historic/status-change/last-call/ Working Group Summary WG consensus was strong. Document Quality This document is in support of https://datatracker.ietf.org/doc/status-change-dlv-to-historic/ Personnel Document Shepherd: Tim Wicinski Area Director: Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Moving DNSSEC Lookaside Validation (DLV) to Historic Status) to Proposed Standard
Please note that this document was originally Last Called on 2019-09-18 as Informational -- https://mailarchive.ietf.org/arch/msg/ietf-announce/RmSJ_aEt_522jT9rqEYmALxCvag It was originally intended that the document text be copied into the status-change document -- but, that doesn't work, because we need a document to exist to actually update RFC 6698 and RFC 6840. So, this requires a second IETF LC, with the header noting that this updates RFC 6698 and RFC 6840, and with the document now being Std Track. The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Moving DNSSEC Lookaside Validation (DLV) to Historic Status' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-10-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document obsoletes DNSSEC lookaside validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates, and updates RFC 6840 by excluding the DLV registries from the trust anchor selection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-obsolete-dlv/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-obsolete-dlv/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5074: DNSSEC Lookaside Validation (DLV) (Informational - IETF stream) rfc4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record (Informational - IETF stream) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Serving Stale Data to Improve DNS Resiliency) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Serving Stale Data to Improve DNS Resiliency' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-09-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks, and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFC 1034 and RFC 1035 so that data can be kept in the cache beyond the TTL expiry, and also updates RFC 2181 by interpreting values with the high order bit set as being positive, rather than 0, and also suggests a cap of 7 days. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3589/ https://datatracker.ietf.org/ipr/3014/ https://datatracker.ietf.org/ipr/3590/ https://datatracker.ietf.org/ipr/3059/ https://datatracker.ietf.org/ipr/3573/ https://datatracker.ietf.org/ipr/2967/ https://datatracker.ietf.org/ipr/2968/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Moving DNSSEC Lookaside Validation (DLV) to Historic Status) to Informational RFC
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Moving DNSSEC Lookaside Validation (DLV) to Historic Status' as Informational RFC Please note that this is primarily to support: https://datatracker.ietf.org/doc/status-change-dlv-to-historic and should be read with that. We are using option 2 of https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-09-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document obsoletes DNSSEC lookaside validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-obsolete-dlv/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-obsolete-dlv/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Algorithm Implementation Requirements and Usage Guidance for DNSSEC' to Proposed Standard (draft-ietf-dnsop-algorithm-update-10.txt)
The IESG has approved the following document: - 'Algorithm Implementation Requirements and Usage Guidance for DNSSEC' (draft-ietf-dnsop-algorithm-update-10.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ Technical Summary The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of non- existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes [RFC6944]. Working Group Summary The Working Group did not have any controversy on this document. There was discussion around the 2119 Normative terms as this draft uses RECOMMENDED/NOT RECOMMENDED instead of SHOULD/SHOULD NOT. This did not cause any problems gaining consensus Document Quality Document is very concise and informative as it updates the list of recommendations for DNSKEY algorithms. The document (currently) has a section listing which implementations support with algorithms / requirements. Personnel Document Shepherd? Tim Wicinski Responsible Area Director? Warren Kumari RFC Editor Note Please remove section 4 "Implementation Status" plus all references to [RFC7942] prior to publication as an RFC. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Algorithm Implementation Requirements and Usage Guidance for DNSSEC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-02-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of non- existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes [RFC6944]. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'C-DNS: A DNS Packet Capture Format' to Proposed Standard (draft-ietf-dnsop-dns-capture-format-10.txt)
The IESG has approved the following document: - 'C-DNS: A DNS Packet Capture Format' (draft-ietf-dnsop-dns-capture-format-10.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ Technical Summary This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata Working Group Summary There was no controversy with the working group. However, during an IETF Hackathon, several issues were during the proof of concept. The document was corrected to address these issues, and is a stronger document because of this. Document Quality There is an existing implementation, as well as converters from this format to other packet formats. From the document: ICANN/Sinodun IT have developed an open source implementation called DNS-STATS Compactor. The Compactor is a suite of tools which can capture DNS traffic (from either a network interface or a PCAP file) and store it in the Compacted-DNS (C-DNS) file format. PCAP files for the captured traffic can also be reconstructed. See Compactor [1]. This implementation: o covers the whole of the specification described in the -03 draft with the exception of support for malformed messages and pico second time resolution. (Note: this implementation does allow malformed messages to be recorded separately in a PCAP file). o is released under the Mozilla Public License Version 2.0. o has a users mailing list available, see dns-stats-users [2]. Personnel Document Shepherd: Tim Wicinski Responsible Area Director (RAD): Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Stateful Operations' to Proposed Standard (draft-ietf-dnsop-session-signal-20.txt)
The IESG has approved the following document: - 'DNS Stateful Operations' (draft-ietf-dnsop-session-signal-20.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ Technical Summary This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions, using type-length-value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. Working Group Summary The working group spent a significant amount of time on this document, as it adds persistence to DNS "connections". However, after several iterations, the working group came to consensus on the document, and strong consensus to move forward. Document Quality The document is clear and easily read. It defines capabilities and provides functionality to be leveraged by other protocols. There are currently no existing implementations of the protocol. However, this work is being leveraged in another working group on DNS Service Discovery. Now that this draft is moving forward, final implementations can begin to emerge. Personnel Tim Wicinski is the Document Shepherd, Warren Kumari is RAD. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Attrleaf Changes: Fixing Specifications with Underscored Node Name Use' to Best Current Practice (draft-ietf-dnsop-attrleaf-fix-07.txt)
The IESG has approved the following document: - 'DNS Attrleaf Changes: Fixing Specifications with Underscored Node Name Use' (draft-ietf-dnsop-attrleaf-fix-07.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ Technical Summary Original uses of an underscore character as a domain node name prefix, which creates a space for constrained interpretation of resource records, were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name- creation activities, all drawing from the same namespace. A registry now has been defined. However the existing specifications that use underscore naming need to be modified, to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model. Working Group Summary This document has a very long history, with multiple, extended periods of hiatus. It's recent activity received substantial working group participant commentary that produced substantial changes to the design of the proposed registry. The latest rounds comments were primarily about minor editorial points or clarification of implications, rather than changes to the design. Multiple participants have commented on the work, over time and recently. They are cited in the document Acknowledgements section. WG criticism of the original design approach produced at least two major revisions to the design. Document Quality This work is explicitly designed to require no software or operational changes. Changes are restricted to the relevant IETF documents, to use standard registry processes. There are no other reviewers that merit special mentioning. Personnel Benno Overeinder is Document Shepherd. Warren Kumari is RAD :-) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Scoped Data Through "Underscore" Naming of Attribute Leaves' to Best Current Practice (draft-ietf-dnsop-attrleaf-16.txt)
The IESG has approved the following document: - 'DNS Scoped Data Through "Underscore" Naming of Attribute Leaves' (draft-ietf-dnsop-attrleaf-16.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ Technical Summary Formally, any DNS resource record may occur under any domain name. However some services have defined an operational convention, which applies to DNS leaf nodes that are under a DNS branch having one or more reserved node names, each beginning with an _underscore. The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain, above the underscored branch. This specification explores the nature of this DNS usage and defines the "DNS Global Underscore Scoped Entry Registry" with IANA. The purpose of the Underscore registry is to avoid collisions resulting from the use of the same underscore-based name, for different services. Working Group Summary This document has a very long history, with multiple, extended periods of hiatus. It's recent activity received substantial working group participant commentary that produced substantial changes to the design of the proposed registry. The latest rounds comments were primarily about minor editorial points or clarification of implications, rather than changes to the design. Multiple participants have commented on the work, over time and recently. They are cited in the document Acknowledgements section. WG criticism of the original design approach produced at least two major revisions to the design. Document Quality This work is explicitly designed to require no software or operational changes. Changes are restricted to the relevant IETF documents, to use standard registry processes. The chairs did talk with application area to have good reviews from them. Personnel Benno Overeinder is Document Shepherd. Warren Kumari is RAD! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'A Root Key Trust Anchor Sentinel for DNSSEC' to Proposed Standard (draft-ietf-dnsop-kskroll-sentinel-17.txt)
The IESG has approved the following document: - 'A Root Key Trust Anchor Sentinel for DNSSEC' (draft-ietf-dnsop-kskroll-sentinel-17.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari, Ignas Bagdonas and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ Technical Summary The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key. Working Group Summary This document has had a short history, and came about while working with ICANN on the KSK rollover process, as a way to assist tracking the addition and removal of DNSSEC keys. Document Quality There are two different implementations of the design. Personnel Document Shepherd: Tim Wicinski Responsible Area Director: Terry Manderson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (C-DNS: A DNS Packet Capture Format) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'C-DNS: A DNS Packet Capture Format' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-11-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic monitoring applications. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2909/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Document Action: 'Reverse DNS in IPv6 for Internet Service Providers' to Informational RFC (draft-ietf-dnsop-isp-ip6rdns-07.txt)
The IESG has approved the following document: - 'Reverse DNS in IPv6 for Internet Service Providers' (draft-ietf-dnsop-isp-ip6rdns-07.txt) as Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ Technical Summary In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone. Working Group Summary This document was reviewed pretty extensively. There were several issues brought up during the document, which the authors and the working group were able to resolve over time. Since the document presents operational guidance, there is no specific implementations needed. Document Quality Operational advice / discussions - no implementation needed. Document is an easy read, clear and concise. Personnel Document Shepherd: Tim Wicinski Area Director:Warren Kumari ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNS Terminology' to Best Current Practice (draft-ietf-dnsop-terminology-bis-14.txt)
The IESG has approved the following document: - 'DNS Terminology' (draft-ietf-dnsop-terminology-bis-14.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ Technical Summary The domain name system (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document will be the successor to RFC 7719, and thus will obsolete RFC 7719. It will also update RFC 2308. Working Group Summary This document has proceeded through the WG remarkably smoothly. The editors have done an enormous amount of work, as have the reviewers. The editors were open with the WG in taking input and mostly incorporating it. A terminology document for a 30yo protocol covered by dozens of existing documents and used by millions of hosts and billions of users every day is a particularly thankless task and it's been done very well. It was written expressly to obsolete 7719, which was Informational and tackled only those definitions that were unambiguous; this document extends them in an attempt to resolve some such ambiguities to recommend "best practice". Document Quality The document attempts to describe both the standard and practice for a protocol that's been in use for 30 years and dozens of implementations. Attention in the WG came from both operators and implementers. Personnel Suzanne Woolf is the Document Shepherd. Warren Kumari is RAD! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY' to Proposed Standard (draft-ietf-dnsop-refuse-any-07.txt)
The IESG has approved the following document: - 'Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY' (draft-ietf-dnsop-refuse-any-07.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ Technical Summary The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance or other reasons. This document provides specific behaviorial guidance for DNS servers and/or clients. Working Group Summary There was some initial issues reaching consensus during WGLC, but the authors worked out the specific issues with the working group and the final version met with strong consensus. Document Quality The document is clear and well written. It contains an Implementation section discussing implementation experience, and is deployed in the Internet. Personnel Document Shepherd is Tim Wicinski and Warren "Ace" Kumari is RAD! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Scoped Data Through "Underscore" Naming of Attribute Leaves) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Scoped Data Through "Underscore" Naming of Attribute Leaves' as Best Current Practice PLEASE NOTE: The draft-ietf-dnsop-attrleaf-fix and draft-ietf-dnsop-attrleaf documents are very closely related. Please read **both** of them when commenting. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-09-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Formally, any DNS resource record may occur under any domain name. However some services have defined an operational convention, which applies to DNS leaf nodes that are under a DNS branch having one or more reserved node names, each beginning with an _underscore. The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain, above the underscored branch. This specification explores the nature of this DNS usage and defines the "DNS Global Underscore Scoped Entry Registry" with IANA. The purpose of the Underscore registry is to avoid collisions resulting from the use of the same underscore-based name, for different services. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc2181: Clarifications to the DNS Specification (Proposed Standard - IETF stream) rfc2782: A DNS RR for specifying the location of services (DNS SRV) (Proposed Standard - IETF stream) rfc5518: Vouch By Reference (Proposed Standard - IETF stream) rfc6698: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA (Proposed Standard - IETF stream) rfc8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) (Proposed Standard - IETF stream) rfc8162: Using Secure DNS to Associate Certificates with Domain Names for S/MIME (Experimental - IETF stream) rfc5026: Mobile IPv6 Bootstrapping in Split Scenario (Proposed Standard - IETF stream) rfc7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Informational - Independent Submission Editor stream) rfc7929: DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP (Experimental - IETF stream) rfc5509: Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream) draft-ietf-acme-acme: Automatic Certificate Management Environment (ACME) (None - IETF stream) rfc3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence (Proposed Standard - IETF stream) rfc6733: Diameter Base Protocol (Proposed Standard - IETF stream) draft-ietf-uta-mta-sts: SMTP MTA Strict Transport Security (MTA-STS) (None - IETF stream) rfc7553: The Uniform Resource Identifier (URI) DNS Resource Record (Informational - IETF stream) rfc7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (Proposed Standard - IETF stream) rfc7671: The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance (Proposed Standard - IETF stream) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Attrleaf Changes: Fixing Specifications with Underscored Node Name Use) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Attrleaf Changes: Fixing Specifications with Underscored Node Name Use' as Best Current Practice PLEASE NOTE: The draft-ietf-dnsop-attrleaf-fix and draft-ietf-dnsop-attrleaf documents are very closely related. Please read **both** of them when commenting. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-09-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Original uses of an underscore character as a domain node name prefix, which creates a space for constrained interpretation of resource records, were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name- creation activities, all drawing from the same namespace. A registry now has been defined. However the existing specifications that use underscore naming need to be modified, to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc3887: Message Tracking Query Protocol (Proposed Standard - IETF stream) rfc5415: Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification (Proposed Standard - IETF stream) rfc4976: Relay Extensions for the Message Sessions Relay Protocol (MSRP) (Proposed Standard - IETF stream) rfc5518: Vouch By Reference (Proposed Standard - IETF stream) rfc3861: Address Resolution for Instant Messaging and Presence (Proposed Standard - IETF stream) rfc4387: Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP (Proposed Standard - IETF stream) rfc4386: Internet X.509 Public Key Infrastructure Repository Locator Service (Experimental - IETF stream) rfc6011: Session Initiation Protocol (SIP) User Agent Configuration (Informational - IETF stream) rfc4120: The Kerberos Network Authentication Service (V5) (Proposed Standard - IETF stream) rfc5679: Locating IEEE 802.21 Mobility Services Using DNS (Proposed Standard - IETF stream) rfc5928: Traversal Using Relays around NAT (TURN) Resolution Mechanism (Proposed Standard - IETF stream) rfc8145: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) (Proposed Standard - IETF stream) rfc5864: DNS SRV Resource Records for AFS (Proposed Standard - IETF stream) rfc7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Informational - Independent Submission Editor stream) rfc2782: A DNS RR for specifying the location of services (DNS SRV) (Proposed Standard - IETF stream) rfc5766: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (Proposed Standard - IETF stream) rfc6117: IANA Registration of Enumservices: Guide, Template, and IANA Considerations (Proposed Standard - IETF stream) rfc3263: Session Initiation Protocol (SIP): Locating SIP Servers (Proposed Standard - IETF stream) rfc3529: Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) (Experimental - Independent Submission Editor stream) rfc7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (Proposed Standard - IETF stream) rfc6733: Diameter Base Protocol (Proposed Standard - IETF stream) rfc5780: NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) (Experimental - IETF stream) rfc6186: Use of SRV Records for Locating Email Submission/Access Services (Proposed Standard - IETF stream) rfc3832: Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV (Experimental - IETF stream) rfc5509: Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) (Proposed Standard - IETF stream) rfc3958: Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) (Proposed Standard - IETF stream) rfc3620: The TUNNEL Profile (Proposed Standard - IETF stream) rfc5026: Mobile IPv6 Bootstrapping in Split Scenario
[DNSOP] Last Call: (Reverse DNS in IPv6 for Internet Service Providers) to Informational RFC
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Reverse DNS in IPv6 for Internet Service Providers' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-09-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (A Root Key Trust Anchor Sentinel for DNSSEC) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'A Root Key Trust Anchor Sentinel for DNSSEC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-09-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key. [ This document is being collaborated on in Github at: https://github.com/APNIC-Labs/draft-kskroll-sentinel. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. RFC Editor, please remove text in square brackets before publication. ] The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-09-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance or other reasons. The DNS specification does not include specific guidance for the behaviour of DNS servers or clients in this situation. This document aims to provide such guidance. This document updates RFC 1034 and RFC 1035. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Terminology) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Terminology' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-08-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The domain name system (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document will be the successor to RFC 7719, and thus will obsolete RFC 7719. It will also update RFC 2308. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc2308: Negative Caching of DNS Queries (DNS NCACHE) (Proposed Standard - IETF stream) rfc2181: Clarifications to the DNS Specification (Proposed Standard - IETF stream) rfc1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (Proposed Standard - IETF stream) rfc1912: Common DNS Operational and Configuration Errors (Informational - Legacy stream) rfc882: Domain names: Concepts and facilities (Unknown - Legacy stream) rfc6561: Recommendations for the Remediation of Bots in ISP Networks (Informational - IETF stream) rfc6781: DNSSEC Operational Practices, Version 2 (Informational - IETF stream) rfc4592: The Role of Wildcards in the Domain Name System (Proposed Standard - IETF stream) rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) (Proposed Standard - IETF stream) rfc3731: Extensible Provisioning Protocol (EPP) Domain Name Mapping (Proposed Standard - IETF stream) rfc7719: DNS Terminology (Informational - IETF stream) rfc2136: Dynamic Updates in the Domain Name System (DNS UPDATE) (Proposed Standard - IETF stream) rfc5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (Proposed Standard - IETF stream) rfc7344: Automating DNSSEC Delegation Trust Maintenance (Proposed Standard - IETF stream) rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - IETF stream) rfc4034: Resource Records for the DNS Security Extensions (Proposed Standard - IETF stream) rfc8310: Usage Profiles for DNS over TLS and DNS over DTLS (Proposed Standard - IETF stream) rfc4033: DNS Security Introduction and Requirements (Proposed Standard - IETF stream) rfc6841: A Framework for DNSSEC Policies and DNSSEC Practice Statements (Informational - IETF stream) rfc5936: DNS Zone Transfer Protocol (AXFR) (Proposed Standard - IETF stream) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNS Stateful Operations) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNS Stateful Operations' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-06-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions, using type-length-value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header opcode and result code which has different message semantics. This document updates RFC 7766 by redefining a session, providing new guidance on connection re-use, and providing a new mechanism for handling session idle timeouts. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Document Action: 'Special-Use Domain Names Problem Statement' to Informational RFC (draft-ietf-dnsop-sutld-ps-08.txt)
The IESG has approved the following document: - 'Special-Use Domain Names Problem Statement' (draft-ietf-dnsop-sutld-ps-08.txt) as Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ Technical Summary The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special- Use Domain Names. Working Group Summary This document was the result of a decision in DNSOP to attempt to characterize the problems we actually face with special use names before attempting to analyze any of several proposals and contending beliefs about how to resolve them. The document has been a considerable time in the making but has WG consensus as a list of the relevant issues and challenges. As such, it can reasonably be the basis for future work in this area, whether it's within scope/charter for DNSOP or not. Document Quality The document summarizes many discussions and documents across DNSOP, the wider IETF, and other concerned communities to date. Personnel Shepherd: Suzanne Woolf Area Director: Benoit Claise ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Aggressive use of DNSSEC-validated Cache' to Proposed Standard (draft-ietf-dnsop-nsec-aggressiveuse-10.txt)
The IESG has approved the following document: - 'Aggressive use of DNSSEC-validated Cache' (draft-ietf-dnsop-nsec-aggressiveuse-10.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari, Benoit Claise and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/ Technical Summary This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers to generate negative answers within a range, and positive answers from wildcards. This increases performance / decreases latency, decreases resource utilization on both authoritative and recursive servers, and also increases privacy. It may also help increase resilience to certain DoS attacks in some circumstances. Working Group Summary Well reviewed by WG, nothing from the WG ML to suggest dissent. Document Quality Quality appears good. Personnel Document Shepherd: Tim Wicinski AD: Terry Manderson; was Joel who hand-balled it to Warren, and he is an author.. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Special-Use Domain Names Problem Statement) to Informational RFC
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Special-Use Domain Names Problem Statement' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-06-20. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special- Use Domain Names. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)' to Proposed Standard (draft-ietf-dnsop-edns-key-tag-05.txt)
The IESG has approved the following document: - 'Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)' (draft-ietf-dnsop-edns-key-tag-05.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ Technical Summary This document specifies two different ways for validating DNS resolvers to signal to a server which DNSSEC keys are referenced in their chain-of- trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.This document describes two independent methods for validating resolvers to publish their referenced keys: an EDNS option and a different DNS query. Working Group Summary The working group was in strong consensus behind this document. One thing which did emerge was that there was a division over two methods for publishihng the keys (EDNS option vs a DNS query). It turned out that each method had its positives and its negatives. The consensus from the working group was to offer both alternatives, documents the flaws in each. Document Quality The document shepherd did a deep dive on the document for technical correctness, as well as an editorial pass for grammar and diction. The shepherd feels this document is ready for publication. (4) Personnel Tim Wickinski is the document shpeherd, Joel Jaeggli is the Area Director ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2017-02-16
The Domain Name System Operations (dnsop) Working Group will hold a virtual interim meeting on 2017-02-16 from 19:00 to 21:00 UTC. Agenda: Preliminary agenda: 1. Issues from WGLC on the problem statement (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/) 2. Proposals for moving forward: * reviews of alt-tld; ready for WGLC? will it help? (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/) * stop here? (leave RFC 6761 as-is, continue to process registry changes case-by-case) * proposals for process revision/update? 3. Next steps: * any drafts to write? * any input or liaison to request from the IAB? (regarding either namespace architecture or relationships of the IETF with other groups) 4. AOB: your I-D or proposed action for the WG/IESG/IAB here Information about remote participation: Webex details will follow ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Initializing a DNS Resolver with Priming Queries' to Best Current Practice (draft-ietf-dnsop-resolver-priming-11.txt)
The IESG has approved the following document: - 'Initializing a DNS Resolver with Priming Queries' (draft-ietf-dnsop-resolver-priming-11.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/ Technical Summary This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS RRSet for the root zone and the necessary address information for reaching the root servers. Working Group Summary This document has been active in the working group for several years. It had strong consensus to adopt and publish. However, due to working group inertia and authors busy schedules, the document stalled several times. It was picked back up recently and the document went through an editing process to streamline the language. This time through the process there was enough attention paid by the working group to address any outstanding issues, provide editorial comments, and see the document through. Personnel Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Managing DS records from parent via CDS/CDNSKEY' to Proposed Standard (draft-ietf-dnsop-maintain-ds-04.txt)
The IESG has approved the following document: - 'Managing DS records from parent via CDS/CDNSKEY' (draft-ietf-dnsop-maintain-ds-04.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ Technical Summary This document describes an in-band method for introducing and removing the Initial DNSSEC trust anchor between a parent and a child domain. This is done by using the CDS/CDNSKEY DNS RR Types introduced in RFC7344. The document also attempts to produce reasonable initial acceptance policy. This work is extending the work done in RFC7344, which was published as an Information document. Time and experience has given the working group insight that the use and deployment of the CDS/CDNSKEY are useful in DNSSEC adoption. Therefore, with the publication of this document, the previous document should be elevated to Standards Track. Working Group Summary This working group was very supportive of this document, and discussion was centered around assisting the adoption of DNSSEC, but also the management of the DS Records. There was many constructive comments on the draft that have all been addressed. The consensus was broad across the working group and the authors addressed all issues raised. Document Quality To be addressed in the interregnum, from the Genart review. This document intends to move RFC7344 from Informational to PS in place (without republishing RFC7344. The intent to do so is buried at the end of the document (the abstract doesn't mention it). The Last Call for the document does not make it clear that _this_ document is elevating RFC7344. (It at least mentions it, which is good, but the writeup about the elevation can be read to say "we're considering this elevation somewhere else, keep it in mind while evaluating this document"). There is no hint from the subject line that this is a call to bring RFC7344 onto the standards track. Unless there is some other communication effort that I've missed on a quick search, I think it is very likely that most of the IETF community outside the dnsop working group missed this intent. I strongly encourge a last call focusing _specifically_ on moving RFC7344 to the standards track without republication. My personal feedback on elevating RFC7344 without republishing is that it's not the right thing to do. At the very least "Category: Informational" appears in the document itself, and that will not change. If the IESG decides to proceed with this as currently formulated, count me in the deep rough. Personnel Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-01-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain-of-trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain-of-trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone. This document describes two independent methods for validating resolvers to publish their referenced keys: an EDNS option and a different DNS query. The reason there are two methods instead of one is some people see significant problems with each method. Having two methods is clearly worse than having just one, but it is probably better for the Internet than having no way to gain the information from the resolvers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Initializing a DNS Resolver with Priming Queries) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Initializing a DNS Resolver with Priming Queries' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-11-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS RRSet for the root zone and the necessary address information for reaching the root servers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5452: Measures for Making DNS More Resilient against Forged Answers (Proposed Standard - IETF stream) rfc4033: DNS Security Introduction and Requirements (Proposed Standard - IETF stream) rfc3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements (Proposed Standard - IETF stream) Note that some of these references may already be listed in the acceptable Downref Registry. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'NXDOMAIN really means there is nothing underneath' to Proposed Standard (draft-ietf-dnsop-nxdomain-cut-05.txt)
The IESG has approved the following document: - 'NXDOMAIN really means there is nothing underneath' (draft-ietf-dnsop-nxdomain-cut-05.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/ Technical Summary This document clearly states that when a DNS resolver receives the response code of NXDOMAIN, it means that the domain name queried AND ALL THE NAMES UNDER IT do not exist. Currently this is an ambitious area where behavior varies depending on implementation. The document updates Section 5 of RFC2308, and attempts to clarify RFC1034 Proposed Standard was chosen as it updates existing Standards. Working Group Summary This document was reviewed and discussed both in DNSOP, but also other DNS-releated mailing lists. The topic of strongly defining what happens with a NXDOMAIN and below that, especially with root TLD servers. There was strong consensus to finally address outstanding issues in old standards. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'DNSSEC Roadblock Avoidance' to Best Current Practice (draft-ietf-dnsop-dnssec-roadblock-avoidance-05.txt)
The IESG has approved the following document: - 'DNSSEC Roadblock Avoidance' (draft-ietf-dnsop-dnssec-roadblock-avoidance-05.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ Technical Summary This document describes problems that a DNSSEC aware resolver or application might run into within a non-compliant infrastructure; outlining potential detection and mitigation techniques. This document attempts to create a shared approach to detect and overcome network issues that a DNSSEC deployment may face. Document Quality This document was actively reviewed, though in organized bursts when the authors were available. The authors were very actively in addressing issues brought up and everything brought up both in meetings and on the mailing list were addressed to satisfaction of the working group. Also, multiple implementations of the compliance checks were written, including teams not involved with the writing of this draft. This has shown the working group there is a strong consensus from desire for these checks to be standardized. Personnel Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (NXDOMAIN really means there is nothing underneath) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'NXDOMAIN really means there is nothing underneath' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-07-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document states clearly that when a DNS resolver receives a response with response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. REMOVE BEFORE PUBLICATION: this document should be discussed in the IETF DNSOP (DNS Operations) group, through its mailing list. The source of the document, as well as a list of open issues, is currently kept at Github [1]. This documents clarifies RFC 1034 and modifies a bit RFC 2308 so it updates both of them. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (Managing DS records from parent via CDS/CDNSKEY) to Proposed Standard
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Managing DS records from parent via CDS/CDNSKEY' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-07-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC7344 specifies how DNS trust can be partially maintained in-band between parent and child. There are two features missing in that specification: initial trust setup and removal of trust anchor. This document addresses both these omissions. Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signalling is seen as a problem or liability that prevents some DNSSEC adoption at large scale. This document adds a method for in-band signalling of these DNSSEC status changes. Initial trust is considered in general to be a hard technical problem, this document sets forth reasonable policies that clarify and simplify the initial acceptance policy. Elevating RFC 7344 to standards-track. Of note, the policy framework described in this document normatively references (thereby including it) a method described in the informational document RFC 7344 . This transition. should be considered it context of advancing this draft. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ballot/ No IPR declarations have been submitted directly on this I-D. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Last Call: (DNSSEC Roadblock Avoidance) to Best Current Practice
The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'DNSSEC Roadblock Avoidance' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-06-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes problems that a DNSSEC aware resolver/ application might run into within a non-compliant infrastructure. It outline potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2716/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'Domain Name System (DNS) Cookies' to Proposed Standard (draft-ietf-dnsop-cookies-10.txt)
The IESG has approved the following document: - 'Domain Name System (DNS) Cookies' (draft-ietf-dnsop-cookies-10.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/ Technical Summary DNS cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification / forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT, and anycast and can be incrementally deployed. Working Group Summary This draft was originally raised several years ago but it languished due to working group hubris. When it was revised, the working group had broad consensus this was a relevant document. The draft had many reviewers, and also picked up another author as the design was polished. Initially, the draft defined the EDNS Option to have an Error Code that was returned. After much discussion, and a prototype deployment of the option, it was decided that the Error Code was not needed, and was removed. Since then a second implementation has appeared The working group was in strong consensus behind this draft. Personnel Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Document Action: 'Client Subnet in DNS Queries' to Informational RFC (draft-ietf-dnsop-edns-client-subnet-07.txt)
The IESG has approved the following document: - 'Client Subnet in DNS Queries' (draft-ietf-dnsop-edns-client-subnet-07.txt) as Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/ Technical Summary This draft defines an EDNS0 extension to carry information about the network that originated a DNS query, and the network for which the subsequent response can be cached. Working Group Summary This draft originally showed up in dnsext working group and was highly criticized and eventually dropped. Since then, dnsext closed down, the ability to get EDNS option codes because a simple expert review process and not Internet Standard, and the scope of this document was changed to document what *currently* exists in the world, and how it behaves. The extensive security writeup, several notes about privacy, and a number of implementation and operational notes included in the text were key in getting consensus support to publish the document. Document Quality There are security issues with this version, as raised by various people. They are correct, and the intent is not to correct the security flaws with this document, but to describe how this option behaves currently. It is suggested a new version will be worked on in a year which addresses the security issues, and addresses other issues about this option. Personnel Document Shepherd: Suzanne Woolf Area Director: Joel Jaggeli ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Protocol Action: 'The edns-tcp-keepalive EDNS0 Option' to Proposed Standard (draft-ietf-dnsop-edns-tcp-keepalive-06.txt)
The IESG has approved the following document:
- 'The edns-tcp-keepalive EDNS0 Option'
(draft-ietf-dnsop-edns-tcp-keepalive-06.txt) as Proposed Standard
This document is the product of the Domain Name System Operations Working
Group.
The IESG contact persons are Benoit Claise and Joel Jaeggli.
A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/
Technical Summary
This document defines an EDNS0 option ("edns-tcp-keepalive") that
allows DNS servers to signal a variable idle timeout. This
signalling facilitates a better balance of UDP and TCP transport
between individual clients and servers, reducing the impact of
problems associated with UDP transport and allowing the state
associated with TCP transport to be managed effectively with minimal
impact on the DNS transaction time.
Working Group Summary
This document originally was adopted but had a few points of controversy
over the initial size of the keep alive option. Another draft was
written at one with a different solution. The authors ended up
collaborating on this document and the final solution with input from
several working group members.
Personnel
Document Shepherd: Tim Wicinski
Area Director: Joel Jaggeli
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Document Action: 'Chain Query requests in DNS' to Experimental RFC (draft-ietf-dnsop-edns-chain-query-07.txt)
The IESG has approved the following document: - 'Chain Query requests in DNS' (draft-ietf-dnsop-edns-chain-query-07.txt) as Experimental RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ Technical Summary This document was heavily reviewed, and discussed by the Working Group. There had been a few operational issues brought up that were resolved. During the WGLC, there was an argument from one person that this could be solved using a different mechanism. It was pointed out that the other mechanism has never been attempted or implemented. It is worth reading for a sense of the discussion that started here: https://mailarchive.ietf.org/arch/msg/dnsop/YAOKdXMZe4iMt2HV0CT-cAtjVKQ The WG is behind this document. There are some reviews from the Apps Area that helped clean up the document. As this is experimental, there are current attempts to implement this. As operational knowledge becomes available, this document will move toward Proposed Standard. Working Group Summary This document was heavily reviewed, and discussed by the Working Group. There had been a few operational issues brought up that were resolved. During the WGLC, there was an argument from one person that this could be solved using a different mechanism. It was pointed out that the other mechanism has never been attempted or implemented. It is worth reading for a sense of the discussion that started here: https://mailarchive.ietf.org/arch/msg/dnsop/YAOKdXMZe4iMt2HV0CT-cAtjVKQ The WG is behind this document. There are some reviews from the Apps Area that helped clean up the document. Document Quality As this is experimental, there are current attempts to implement this. As operational knowledge becomes available, this document will move toward Proposed Standard. Personnel Document Shepherd: Tim Wicinski Area Director: Joel Jaggeli ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
