RFC 5452: Measures for Making DNS More Resilient against Forged Answers
In plain English — editorial summary, not part of the RFC
The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation. By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK]
Document record
- Document ID
- RFC5452
- Published
- January 2009
- Authors
- A. Hubert; R. van Mook
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- int
- Pages
- 18
- Also known as
- —
- Updates:
- RFC 2181
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 4871DomainKeys Identified Mail (DKIM) SignaturesObsoleted
May 2007
- RFC 6274Security Assessment of the Internet Protocol Version 4Current
July 2011
- RFC 4408Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1Obsoleted
April 2006
- RFC 4406Sender ID: Authenticating E-MailCurrent
April 2006
- RFC 4405SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail MessageCurrent
April 2006
- RFC 6518Keying and Authentication for Routing Protocols (KARP) Design GuidelinesCurrent
February 2012
- RFC 6651Extensions to DomainKeys Identified Mail (DKIM) for Failure ReportingCurrent
June 2012
- RFC 6652Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting FormatCurrent
June 2012
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?