RFC 8198: Aggressive Use of DNSSEC-Validated Cache
In plain English — editorial summary, not part of the RFC
The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. 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 increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances. This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards.
Document record
- Document ID
- RFC8198
- Published
- July 2017
- Authors
- K. Fujiwara; A. Kato; W. Kumari
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- ops
- Pages
- 13
- Also known as
- —
Topics
Referenced by
One later RFC formally updates or obsoletes part of this document.
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 9276Guidance for NSEC3 Parameter SettingsCurrent
August 2022
- RFC 5155DNS Security (DNSSEC) Hashed Authenticated Denial of ExistenceUpdated
March 2008
- RFC 7129Authenticated Denial of Existence in the DNSCurrent
February 2014
- RFC 3845DNS Security (DNSSEC) NextSECure (NSEC) RDATA FormatObsoleted
August 2004
- RFC 3755Legacy Resolver Compatibility for Delegation Signer (DS)Obsoleted
May 2004
- RFC 8199YANG Module ClassificationCurrent
July 2017
- RFC 8195Use of BGP Large CommunitiesCurrent
June 2017
- RFC 8194A YANG Data Model for LMAP Measurement AgentsCurrent
August 2017
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?