| |
|
| |
| | Delegation Revalidation by DNS Resolvers |
| |
|
This document recommends improved DNS resolver behavior with respect to the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. The (A and AAAA) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be re-queried and used to replace the entries with the lower trustworthiness ranking in cache. Resolvers should also periodically revalidate the child delegation by re-querying the parent zone at the expiration of the TTL of the parent side NS RRset. |
| | DNSSEC automation |
| |
|
This document describes an algorithm and protocol to automate the setup, operations, and decomissioning of Multi-Signer DNSSEC [RFC8901] configurations. It employs Model 2 of the multi-signer specification, where each operator has their own distinct KSK and ZSK sets (or CSK sets), Managing DS Records from the Parent via CDS/ CDNSKEY [RFC8078], and Child-to-Parent Synchronization in DNS [RFC7477] to accomplish this. |
| | Domain Control Validation using DNS |
| |
|
Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. |
| | Structured Error Data for Filtered DNS |
| |
|
DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. |
| | Compact Denial of Existence in DNSSEC |
| |
|
This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. Such answers require only one minimally covering NSEC or NSEC3 record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. This document updates RFC 4034 and 4035. |
| | Clarifications on CDS/CDNSKEY and CSYNC Consistency |
| |
|
Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. For the case of DS records, RFC 7344 provides automation by allowing the child to publish CDS and/or CDNSKEY records holding the prospective DS parameters which the parent can ingest. Similarly, RFC 7477 specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g. Registries, Registrars) can query these records from the child and, after validation, use them to update the parent-side RRsets of the delegation. This document specifies that when performing such queries, parent- side entities MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records are consistent across the child's authoritative nameservers, before taking any action based on these records. |
| | Generalized DNS Notifications |
| |
|
This document extends the use of DNS NOTIFY (RFC 1996) beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC bootstrapping and key rollovers hints, and quicker changes to a delegation's NS record set. To enable this functionality, a method for discovering the receiver endpoint for such notification message is introduced, via the new DSYNC record type. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/peterthomassen/draft-ietf-dnsop-generalized-notify (https://github.com/peterthomassen/draft-ietf-dnsop-generalized- notify). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. |
| | Deprecate usage of ECC-GOST within DNSSEC |
| |
|
This document retires the use of ECC-GOST within DNSSEC. RFC5933 (now historic) defined the use of GOST R 34.10-2001 and GOST R 34.11-94 algorithms with DNS Security Extensions (DNSSEC). This document updates RFC5933 by deprecating the use of ECC-GOST. [RFC Editor: please remove this before publication: It is unclear if updating RFC5933 (a Historic document) is the correct thing to do or not. We did it so that it shows up in Datatracker and similar, but this may be a mistake. We are happy to change this if the RFC Editor / IESG / whoever thinks this is a bad idea.] |
| | DNSSEC Cryptographic Algorithm Recommendation Update Process |
| |
|
The DNSSEC protocol makes use of various cryptographic algorithms 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 both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document updates RFC8624 by moving the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC8624 to an IANA registry. This is done both to allow the list to be more easily updated, and to allow the list to be more easily referenced. Future extensions to this registry can be made under new, incremental update RFCs. The document does not change the status (MUST, MAY, RECOMMENDED, etc) of any of the algorithms listed in RFC8624; that is the work of future documents. |
| | Deprecating the use of SHA-1 in DNSSEC signature algorithms |
| |
|
This document deprecates the use of the RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms for the creation of DNSKEY and RRSIG records. It updates RFC4034 and RFC5155 as it deprecates the use of these algorithms. |
| | Greasing Protocol Extension Points in the DNS |
| |
|
Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-grease. |