idnits 2.17.1 draft-ietf-dnsind-dns-error-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The IANA-registered text SHOULD be consistent with the registered Error Code value (Section 6). The specific error text SHOULD be further debugging information that will be interpreted by a user or administrator. Client software SHOULD not attempt to parse and interpret the specific text field. The software version identifier is optional, but if server software chooses to provide an identifier, it SHOULD do so consistently. Clients MAY optionally parse the software version identifier, but this information is intended for manual debugging. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (8 March 1998) is 9546 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2065' is defined on line 356, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC2137' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'TSIG' is defined on line 366, but no explicit reference was found in the text -- Duplicate reference: RFC1034, mentioned in 'RFC1035', was also mentioned in 'RFC1034'. ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2137 (Obsoleted by RFC 3007) == Outdated reference: A later version (-13) exists of draft-ietf-dnsind-tsig-02 Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 draft-ietf-dnsind-dns-error-00.txt R. Watson 3 INTERNET-DRAFT TIS 4 O. Gudmundsson 5 TIS 6 8 March 1998 7 Expires in six months 9 Error Record (ERR) for DNS 11 Status of this Document 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 The DNS protocol defines a 4-bit RCODE field in the header of the DNS 32 envelope. This field is used to indicate the completion status of 33 requests. Defined values exist to describe successful completion as 34 well as a variety of error conditions that could result from DNS 35 server operations. As DNS has been expanded to perform additional 36 functions, the number of possible error conditions has increased 37 significantly, and the field no longer has space for new error codes 38 to be added. To address this problem, a new RR type is defined. 40 The Error Record contains a machine-readable extended error value, as 41 well as an optional human-readable ASCII text string. Additionally, 42 it contains a domain-name source field to identify the entity 43 generating the error condition. This RR may also be used in non- 44 error conditions to provide extended information about server 45 responses, such as security information on specific records in the 46 response. 48 1. Introduction 50 The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated 51 hierarchical distributed database system that provides information 52 fundamental to Internet operations, such as name <=> address 53 translation and mail handling information. With recent additions, it 54 can now also provide this information in a secure manner [RFC2065, 55 TSIG], as well as support dynamic changes to its contents [RFC2136, 56 RFC2137]. These features (and others) have resulted in much greater 57 functionality, but also many more possible error conditions. 59 The database requires synchronization and atomicity of update, as 60 well as the ability to report various problems with an update 61 request. With DNS Security and Transaction Signatures, authorization 62 to complete or deliver a request can fail for a variety of reasons. 63 The ability to report these problems in an accurate manner is vital 64 for the maintenance of the system, as the inability to diagnose a 65 serious configuration problem may lead to a loss of service for 66 members of the Internet population. 68 The DNS protocol defines a 4-bit response code field set in the DNS 69 envelope for server responses to indicate successful completion of a 70 request or provide a functional justification for the failure to 71 perform an operation. This space is insufficient for storage of the 72 more complicated errors possible with additional features, as well as 73 not providing any indication of the actual source of the error. As 74 some operations may involve passing a request packet through a series 75 of servers, SERVFAIL may not be sufficient information to correct the 76 problem without extensive debugging. 78 1.1 Keywords Used 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119. 84 2. Error Record Format 86 To provide storage for the error message information, a new RR type 87 is defined with mnemonic ERR. ERR is a meta-RR and it cannot be 88 stored; its type code is TBD. ERR is pronounced with a rolling 89 Icelandic "r". For the existing defined RCODE values, the ERR record 90 exists to provide source and debugging information, and is optional. 91 For RCODE of EXTERR (value TBD), an ERR MUST be included to define 92 the error condition. Additional ERR records MAY also be included. 93 When RCODE is NOERROR (0), ERR records MAY be used to provide 94 optional information. 96 2.1 Record Format: 98 NAME The domain-name of the server reporting the error. This 99 must be the fully qualified domain name of the entity. 100 TYPE ERR 101 CLASS IN 102 TTL Serial Number Arithmetic value of the time the message was 103 generated in seconds since Jan 1, 1970 UTC. 104 RdLen (variable) 105 RDATA 107 Field Name Data Type Notes 108 ------------------------ ------------ -------------------------- 109 Error Code u_int16_t For existing RCODE values, 110 Error Code should be set 111 to the RCODE value. For 112 RCODE of EXTERR, an IANA- 113 assigned value will be 114 used. 115 Referred Dname domain-name A domain name specifying 116 another entity or key 117 involved in the error. 118 Use of this field varies 119 by error. 120 Type u_int16_t For messages associated 121 with a particular RR Name/ 122 Type, this will allow 123 differentiation. This is 124 useful in the context of 125 Dynamic Update, for 126 example. This should be 127 set to 0 where unused. 128 Message Size u_int8_t Number of octets in the 129 error message. 130 Message octet stream The user-readable error 131 message. 132 Other Data undefined Ignore any following RDATA 134 * All multi-octet integer values are in Network Byte Order 136 2.2 Example 138 RCODE SERVFAIL (2) 139 NAME DNS-1.PROVIDER.XX. 140 TYPE ERR 141 CLASS IN 142 TTL 869769589 143 RdLen 72 144 RDATA 146 Field Name Contents 147 -------------- -------------- 148 Error Code 2 149 Referred Name FLEDGE.WATSON.ORG. 150 Type 0 151 Message Size 58 152 Message Server Failure: Timeout on forwarded request 153 (BIND 8.1.1) 155 3. Error Message Generation 157 When an error occurs, the entity generating the error has the option 158 of reporting the error to the client. A normal packet is 159 constructed, with the RCODE in the header set appropriately. If the 160 RCODE is EXTERR, it MUST attach an ERR record. Otherwise, the ERR 161 record is optional. ERR records MAY be placed in any section of a 162 DNS packet where resources records can occur. 164 Informational ERR records are expected to be interspersed with 165 existing RRs or RRsets, and in the event an ERR record is associated 166 with another record, it MUST follow that record. For example, an ERR 167 record might indicate the security status of an A record, in which 168 case it would follow that resource record in the Answer section. 169 When ERR RRs are not associated with another RR, they MUST be placed 170 in the Additional Data section. For example, a Server Failure error 171 packet would have RCODE of SERVFAIL (2), and an ERR RR (such as seen 172 in the above example) in the Additional Data section. 174 If a packate containing required error codes it too long for a UDP 175 packet, the message MUST be truncated, and the TC bit set, indicating 176 that the client should retry over TCP to retrieve the complete 177 answer. 179 In constructing the ERR RRs, the fully qualified domain name of the 180 entity generating the message SHOULD be used as the resource record 181 name. In all identified cases, this will be a name server. The 182 class MUST be IN, and the TTL must be set to the time (in seconds 183 since Jan 1, 1970 UTC) that the error occurred. 185 Inside the RDATA of the RR, the Error Code SHUOLD be set either to 186 the existing RCODE value, or in the case of NOERROR or EXTERR, to the 187 IANA-assigned Error Code for the error or message type being 188 reported. If multiple error messages are included, and only one uses 189 an RCODE-defined value, that value MUST be used in the packet's RCODE 190 field. If multiple RCODE-defined values are present, the first of 191 these values MUST used for the packet header RCODE field. This 192 provides backwards compatibility, as existing DNS operations abort on 193 the first error discovered, and that error is reported. The referral 194 domain name depends on the type of message being transmitted. 196 Referral name values for common RCODEs are described in Section 7. 197 The message text will be stored in an octet-stream of up to 255 198 octets in length. The message MUST be interpreted as USASCII text. 199 The length of the message will be stored in the Message Size field. 201 3.1 Message Text Format 203 To provide a more consistent message format, the following formatting 204 SHOULD be applied to the message field in the RR: 206 IANA-registered text: specific error text (software version 207 identifier) 209 The IANA-registered text SHOULD be consistent with the registered 210 Error Code value (Section 6). The specific error text SHOULD be 211 further debugging information that will be interpreted by a user or 212 administrator. Client software SHOULD not attempt to parse and 213 interpret the specific text field. The software version identifier is 214 optional, but if server software chooses to provide an identifier, it 215 SHOULD do so consistently. Clients MAY optionally parse the software 216 version identifier, but this information is intended for manual 217 debugging. 219 Client behavior on receiving an extended error message SHOULD depend 220 on the error received. Clients are not required to display extended 221 error information to the user, although they MAY do so in the event 222 of a serious failure. Interpretation of the text message SHOULD NOT 223 be relied upon by the server: the resolver or update software is only 224 required to interpret the Error Code itself. 226 4.Storage Considerations 228 ERR RRs are transient in nature, and SHOULD NOT be stored or reused 229 beyond the query that they are created for. In particular, DNS 230 servers MUST NOT cache the ERR records and return them to other 231 clients. 233 5. Additional RCODE Values 235 Mnemonic Value Description 236 ------------- ------- -------------------- 237 EXTERR TBD Error RR(s) attached 239 6. Reserved Error Codes 241 Range Mnemonic ValueRequired Name 242 ----------- ------------------------------------------ 243 0..15 Existing RCODE Values 245 NOERROR 0 (invalid value) 246 FORMERR 1 Format Error 247 SERVFAIL 2 Server Failure 248 NXDOMAIN 3 Non-existent Domain 249 NOTIMP 4 Function Not Implemented 250 REFUSED 5 Action Refused 251 YXDOMAIN 6 Name that ought not exist 252 does exist 253 XRRSET 7 RRset that ought not exist 254 does exist 255 XRRSET 8 RRset that ought to exist 256 does not 257 NOTAUTH 9 Server Not Authoritative for 258 Zone 259 NOTZONE 10 Name not in Zone 261 EXTERR TBD (invalid value) 263 16-63 Reserved for RCODE Extension 264 64-4095 Error Message assigned by IANA 265 4096-8191 Information Message assigned by IANA 266 8192-16383 Error Message for Servers (IANA Blocks) 267 16384-32767 Information Message for Servers (IANA Blocks) 268 32768-65535 Private (for general undefined use) 270 Values 16-63 are reserved for possible extension of the RCODE bit- 271 range. In the event that it is determined that additional RCODE 272 values are required, this bit space in an ERR RR could be used to 273 extend the RCODE space. 275 Values 64-4095 are reserved for use similar to existing RCODE values. 276 They will be assigned by IANA, one per error, and have an associated 277 mnemonic, as well as a registered required message text. 279 Values 4096-8191 are reserved for informational messages optionally 280 provided to clarify information from the server. For example, such a 281 message could be used to indicate the authentication status of a RR 282 in a packet marked as containing unauthenticated data. 284 Values 8192-16383 are reserved for allocation by IANA in blocks to 285 specific server software. These values may be used for debugging the 286 server software, or for communication between these servers in a non- 287 standard manner. For example, error 8193 could be used by BIND to 288 indicate a failure in a particular block of code when authenticating 289 a request, and the text of the error message could identify the line 290 of code and variable values. These values SHOULD be used for error 291 messages. 293 Values 16384-32767 are for information messages specific to server 294 software, and allocated in blocks by IANA similar to the 8192-16383 295 range. 297 Values 32767-65535 are reserved for private use. These values do not 298 require allocation by IANA, but on receiving such a message from an 299 unidentified server, no assumptions SHOULD be made as to meaning. 301 7. Referral Name Use in Existing RCODEs 303 In many cases, the referral name is useful in clarifying existing 304 RCODE responses. 306 Mnemonic Use of Referral Name 307 ----------- ----------------------------- 308 NOERROR (invalid value) 309 FORMERR (not useful) 310 SERVFAIL Name of server not responding, if applicable 311 NXDOMAIN Domain name not found (Type field if applicable) 312 NOTIMP (not useful) 313 REFUSED If a key error, the name of the key 314 YXDOMAIN Domain name that was found (Type field if applicable) 315 YXRRSET Domain name that was found 316 NXRRSET Domain name that was not found 317 NOTAUTH Zone name 318 EXTERR (invalid value) 320 8. Security Considerations 322 As with all DNS packet data, ERR RRs are subject to modification or 323 spoofing if appropriate measures are not taken (such as DNSSEC SIG(0) 324 or TSIG) to protect the data and transaction integrity. For the 325 purposes of signature generation, ERR records should be treated as 326 normal DNS data, and included in the signature. As a result, ERR 327 records MUST NOT be added to packets that have already been signed, 328 as this will cause packet verification to fail. 330 ERR records MUST NOT be included in an RRset during DNSsec signature 331 verification, as this dynamic data will not have been signed with the 332 zone or dynamic update key. 334 It is important that debugging information delivered to the client 335 not be confidential, as no privacy protection is current defined for 336 DNS. 338 Some caution SHOULD be used in the logging and display of ERR error 339 message text, as malicious entities might insert unreadable binary 340 data or control codes, causing problems on terminal-oriented 341 displays. 343 Information messages MUST NOT be used by the server to determine the 344 status of RRset authentication unless the transmission is protected 345 by some authentication mechanism (such as TSIG or SIG(0)), and the 346 information comes from a trusted host. 348 9. References 350 [RFC1034] P. Mockapetris, "Domain Names - Concepts and 351 Facilities", RFC 1034, ISI, November 1987. 353 [RFC1035] P. Mockapetris, "Domain Names - Implementation and 354 Specification," RFC 1034, ISI, November 1987. 356 [RFC2065] D. Eastlake, C. Kaufman, "Domain System Security 357 Extensions," RFC 2065, CyberCash & Irix, January 1997. 359 [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, 360 "Dynamic Updates in the Domain Name System," RFC 2136, 361 ISC, Bellcore, Cisco, DEC, April 1997. 363 [RFC2137] D. Eastlake, "Secure Domain Name System Dynamic 364 Update", RFC 2137, Cybercash, April 1997. 366 [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, 367 "Secret Key Transaction Signatures for DNS," 368 draft-ietf-dnsind-tsig-02, ISC, TIS, CyberCash, 370 10. Author's Addresses 372 Robert Watson Olafur Gudmundsson 373 7100 Marbury Rd. Trusted Information Systems 374 Bethesda, MD 20817 3060 Washington Road, Route 97 375 +1 301 229 2822 Glenwood, MD 21738 376 +1 301 854 6889 377