Extended DNS Errors
draft-wkumari-dnsop-extended-error-02

Document Type Replaced Internet-Draft (dnsop WG)
Last updated 2017-08-08 (latest revision 2017-07-17)
Replaced by draft-ietf-dnsop-extended-error
Stream IETF
Intended RFC status Informational
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state Adopted by a WG
Document shepherd No shepherd assigned
IESG IESG state Replaced by draft-ietf-dnsop-extended-error
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-wkumari-dnsop-extended-error-02.txt

Abstract

This document defines an extensible method to return additional information about the cause of DNS errors. The primary use case is to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures. [ Open question: The document currently defines a registry for errors. It has also been suggested that the option also carry human readable (text) messages, to allow the server admin to provide additional debugging information (e.g: "example.com pointed their NS at us. No idea why...", "We don't provide recursive DNS to 192.0.2.0. Please stop asking...", "Have you tried Acme Anvil and DNS? We do DNS right..." (!). Please let us know if you think text is needed, or if a 16bit FCFS registry is expressive enough. ] [ Open question: This document discusses extended *errors*, but it has been suggested that this could be used to also annotate *non- error* messages. The authors do not think that this is a good idea, but could be persuaded otherwise. ]

Authors

Warren Kumari (warren@kumari.net)
Evan Hunt (each@isc.org)
Roy Arends (unknown-email-Roy-Arends)
Wes Hardaker (unknown-email-Wes-Hardaker)
David Lawrence (tale@akamai.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)