DNS Delegation Extensions
draft-arends-parent-only-record-signalling-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Roy Arends | ||
| Last updated | 2025-01-09 (Latest revision 2024-07-08) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
New RR types have been proposed that appear only at the parent side of a delegation, similar to the DS resource record (RR) type. Supporting parent side RR types requires modifications to the DNS Security Extensions (DNSSEC). Without these modifications, validating resolvers are susceptible to response modification attacks. An on-path adversary could potentially remove the parent-side resource records without being detected. To detect the removal of a parent-side RR type, an authenticated denial record (such as NSEC or NSEC3) is necessary to confirm presence or absence of a parent-side RR type. Currently, validating resolver do not expect authenticated denial records in a secure delegation response. Therefore, a secure signal is needed to inform the validating resolver to anticipate authenticated denial records for a delegation. To support the future deployment of parent-side RR types, this draft designates a range of yet unallocated RR types specifically for parent-side use. Authoritative servers will include these records in a delegation response without requiring upgrades.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)