idnits 2.17.00 (12 Aug 2021) /tmp/idnits57539/draft-hunt-dns-server-diagnostics-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 31, 2013) is 3216 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 521, but not defined == Missing Reference: 'This' is mentioned on line 575, but not defined ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Hunt 3 Internet-Draft ISC 4 Intended status: Experimental July 31, 2013 5 Expires: February 1, 2014 7 The DNS Extended Server Diagnostics (ESD) Option 8 draft-hunt-dns-server-diagnostics-00 10 Abstract 12 The widespread adoption of DNSSEC implies more frequent DNSSEC 13 failures. Unfortunately, DNSSEC's failure mode is largely opaque to 14 the client: when validation fails, the only signal that the clients 15 of a validating resolver receive is an empty response with a SERVFAIL 16 response code. This note proposes a protocol extension to allow 17 SERVFAIL responses to include additional diagnostic information, 18 giving the client greater insight into what went wrong and a better 19 chance of delivering useful problem reports to DNS operators. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 1, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. The ESD Option . . . . . . . . . . . . . . . . . . . . . . 4 61 2.4. ESD Diagnostic Codes . . . . . . . . . . . . . . . . . . . 5 62 2.4.1. Internal Server Errors . . . . . . . . . . . . . . . . 5 63 2.4.2. General DNS Errors . . . . . . . . . . . . . . . . . . 6 64 2.4.3. Policy-Dependent Security Errors . . . . . . . . . . . 7 65 2.4.4. Temporary Security Errors . . . . . . . . . . . . . . 8 66 2.4.5. Fatal Security Errors . . . . . . . . . . . . . . . . 9 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 4.1. ESD Option Code . . . . . . . . . . . . . . . . . . . . . 12 70 4.2. Diagnostic Codes . . . . . . . . . . . . . . . . . . . . . 12 71 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 DNSSEC's failure mode is largely opaque to the client: when 80 validation fails, the only signal of this that a resolver's clients 81 receive is a SERVFAIL response code. 83 With no information provided to explain the exact cause of a SERVFAIL 84 response, there is no straightforward way for an end user to 85 determine whether a failure occurred due to a broken local resolver, 86 a zone misconfiguration such as expired signatures, or a spoofing 87 attack. This makes it difficult to address complaints and problem 88 reports to the right people, slowing the correction of DNSSEC errors 89 while increasing the support burden on validating resolver operators. 91 This note proposes a protocol extension allowing a name server, upon 92 request from a client, to accompany SERVFAIL responses with detailed 93 diagnostic information indicating what specifically caused the 94 failure. In the typical use case for this mechanism, a validating 95 caching name server would be able to convey specific failure 96 information to a non-validating stub resolver or other client. 98 1.1. Reserved Words 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Protocol 106 A DNS client such as a non-validating stub resolver may use an 107 EDNS(0) [RFC2671] option, ESD, to solicit extended diagnostic 108 information from a DNS server. The ESD option payload includes a 16- 109 bit "flags" field and a 16-bit diagnostic code; additional payload 110 data may be included in the response. 112 One bit in the "flags" field is defined as "human-readable": if this 113 bit is set in the solicitation, it indicates a desire for the server 114 to return human-readable text, in addition to machine-readable 115 diagnostic data; this text can be displayed or sent to a logging 116 facility such as syslog [RFC5424]. All other payload data MUST be 117 left empty in the solicitation. 119 The response payload, in addition to the flags field and the 120 diagnostic code, may also include a supplemental data field whose 121 content and schema are dependent on the diagnostic code being 122 returned. If the "human-readable" flag is set in the response, then 123 the response also includes human-readable text in a counted string, 124 i.e., a single length octet followed by that number of characters, as 125 in the TXT RDATA format [RFC1035]. 127 2.1. Client Behavior 129 A stub resolver or other DNS client requests extended diagnostic data 130 by sending an ESD option (Section 2.3) in an EDNS(0) OPT pseudo-RR in 131 the query message. The requestor MAY set the "human-readable" bit in 132 the flags field of the request payload. The requestor MUST NOT 133 include any other payload data in the ESD option. 135 The requestor MUST ignore any ESD option included in a response that 136 does not have response code SERVFAIL. 138 2.2. Server Behavior 140 A resolver or other name server which encounters a server failure 141 while answering a query that included an ESD option MAY add an ESD 142 option to the SERVFAIL response. If the query did not include an ESD 143 option, then the response MUST NOT include one. The server MUST NOT 144 include an ESD option in any non-SERVFAIL response. 146 2.3. The ESD Option 148 The OPTION-CODE for the ESD option is [TBD]. 150 The format for the OPTION-DATA portion of an ESD option is shown 151 below: 153 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 154 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | FLAGS |H| DIAGCODE | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 \ HRTEXT (optional, resonse only) \ 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 \ SUPPDATA (optional, response only) \ 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 in which the fields are defined as follows: 165 FLAGS A 16-bit field. Bit 15 (H) is defined to mean "human- 166 readable"; when set in the solicitation, this bit signals a 167 desire for human-readable text to be included in the 168 response; when set in the response, it signals that such 169 text has been included. All other bits in the field MUST 170 be set to zero. 172 DIAGCODE A 16-bit diagnostic code (Section 2.4) indicating the 173 reason for the SERVFAIL response. In the solicitation 174 payload, this field MUST be set to zero. 176 HRTEXT An counted string, containing human-readable text suitable 177 for logging. The first octet defines the length of the 178 following text; if the first octet contains 0, the string 179 is emty. This is intended as an opaque string to be passed 180 through to a logging mechanism; content and encoding are 181 outside the scope of the protocol. This field MUST NOT be 182 included in a solicitation payload. 184 SUPPDATA Optional supplementary data about the cause of the server 185 failure. The presence or absence, content, and schema of 186 this field are entirely dependent on the diagnostic code 187 being returned in the DIAGCODE field (Section 2.4). This 188 field MUST NOT be included in a solicitation payload. 190 2.4. ESD Diagnostic Codes 192 Diagnostic codes are grouped in five general categories: Internal 193 server error conditions (diagnostic codes 1-255), general DNS 194 failures (256-511), policy-dependent security errors (512-767), 195 temporary security errors (768-1023), and fatal security errors 196 (1024-1279). Space has been reserved in the namespace for additional 197 categories and codes. All diagnostic codes are optional; there is no 198 requiremnt to impelement all of them. 200 The DIAGCODE field MUST be set to zero (No Error) in ESD 201 solicitations. 203 2.4.1. Internal Server Errors 205 These diagnostic codes indicate a system failure in the responding 206 server. 208 2.4.1.1. Internal Error, Not Otherwise Specified 210 Diagnostic code 1 indicates an unspecified internal server error 211 unrelated to DNSSEC. A server MAY return this code in place of any 212 other internal server error, at the discretion of the implementor or 213 operator, if information about the internal state of the server is 214 regarded as security sensitive. This code has no supplemental data. 216 2.4.1.2. Out of Memory 218 Diagnostic code 2 indicates that the server was not able to 219 dynamically allocate memory. This code has no supplemental data. 221 2.4.1.3. Resource Unavailable 223 Diagnostic code 3 indicates that a needed resource was not available. 224 This code has no supplemental data. 226 2.4.1.4. Zone Not Loaded 228 Diagnostic code 4: The server has been configured to be authoritative 229 for a zone which is an ancestor of the query name, but was unable to 230 load it. The supplemental data contains the name of the zone the 231 server was unable to load, in DNS wire format. 233 2.4.1.5. Invalid Zone 235 Diagnostic code 5: The server has been configured to be authoritative 236 for a zone which is an ancestor of the query name, but the zone 237 contents are invalid; for example, there is no SOA RR or NS RRset at 238 the zone apex. The supplemental data contains the name of the zone 239 in DNS wire format. 241 2.4.1.6. Configuration Error 243 Diagnostic code 6: The server could not be initialized, e.g., as a 244 result of an error in loading or parsing the configuration file. 245 This code has no supplemental data. 247 2.4.1.7. Timeout 249 Diagnostic code 7: Query processing timed out. This code has no 250 supplemental data. 252 2.4.1.8. Shutting Down 254 Diagnostic code 8: The server is shutting down. This code has no 255 supplemental data. 257 2.4.2. General DNS Errors 259 These codes describe failure conditions due to bad or inconsistent 260 data in the DNS not specifically related to DNSSEC. 262 2.4.2.1. Lame Delegation 264 Diagnostic code 256: The name servers which have been delegated 265 responsibility for a zone cannot be reached or are not performing 266 name service for that zone. The supplemental data contains the zone 267 apex name of the faulty zone. 269 2.4.2.2. Name Expansion Failure 271 Diagnostic code 257: A CNAME [RFC1034] or DNAME [RFC6672] record 272 fails sanity checks after name expansion. The supplemental data 273 contains the name and RR type (CNAME or DNAME) of the faulty record, 274 in the following format: 276 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 277 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | RRTYPE | NAME \ 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 2.4.2.3. Protocol Not Supported 284 Diagnostic code 258: Processing this query requires a protocol 285 extension that is not supported. This code has no supplemental data. 287 2.4.3. Policy-Dependent Security Errors 289 These are errors returned due to locally-configured policy 290 constraints on DNSSEC processing or other security considerations. 292 2.4.3.1. Key Too Large 294 Diagnostic code 512: Local policy disallows a DNSKEY being used to 295 validate a record on the grounds that it is too large. The 296 supplemental data specifies the owner name (in DNS wire format) and 297 key tag of the problematic DNSKEY, using the following format: 299 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 300 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | TAG | NAME \ 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 2.4.3.2. Key Too Small 307 Diagnostic code 513: Local policy disallows a DNSKEY being used to 308 validate a record on the grounds that it is too small. The 309 supplemental data contains the nam5 and tag of the problematic key, 310 in the format specified in Section 2.4.3.1. 312 2.4.3.3. Key Not Authorized 314 Diagnostic code 514: Local policy does not authorize a key to be used 315 for validation. The supplemental data contains the name and tag of 316 the problematic key, in the format specified in Section 2.4.3.1. 318 2.4.3.4. Key Algorithm Refused 320 Diagnostic code 515: Local policy prohibits validation using a given 321 signing algorithm. The supplemental data contains a 16-bit unsigned 322 integer indicating which algorithm has been disallowed. 324 2.4.3.5. Unauthorized Signer 326 Diagnostic code 516: Local policy disallows accepting signatures 327 created by this signer. The supplemental data contains the name of 328 the signer that has been disallowed. 330 2.4.3.6. No Trust Anchor 332 Diagnostic code 517: There is no trust anchor for the chain of trust 333 needed to validate this data, but local policy requires validation. 334 This code has no supplemental data. 336 2.4.3.7. Too Many Links 338 Diagnostic code 518: The chain of trust is longer than local policy 339 permits. This code has no supplemental data. 341 2.4.3.8. Response Blocked 343 Diagnostic code 519: The response to this query has been blocked by 344 local policy. This code has no supplemental data. 346 2.4.4. Temporary Security Errors 348 These are error conditions occurring from DNSSEC processing which are 349 time-dependent: i.e., problems due to signature validity interval or 350 key expiry. 352 2.4.4.1. Signature Expired 354 Diagnostic code 768: An RRSIG is past its useful lifetime. The 355 supplemental data contains the name and covering RR type of the 356 failed RRSIG, in the format specified in Section 2.4.2.2. 358 2.4.4.2. Signature Not Yet Active 360 Diagnostic code 769: An RRSIG has not yet begun its useful lifetime. 361 The supplemental data contains the name and covering RR type of the 362 invalid RRSIG, in the format specified in Section 2.4.2.2. 364 2.4.4.3. Trust Anchor Expired 366 Diagnostic code 770: A trust anchor can no longer be used. The 367 supplemental data contains the name of the expired trust anchor in 368 wire format. 370 2.4.5. Fatal Security Errors 372 These error conditions due to DNSSEC processing are always fatal, 373 regardless of time or local policy. 375 2.4.5.1. Bogus Data 377 Diagnostic code 1024: Cryptographic validation failed. The 378 supplemental data contains the name and RR type of data which failed 379 to validate, in the format specified in Section 2.4.2.2. 381 2.4.5.2. Signature Missing 383 Diagnostic code 1025: There was no RRSIG found for an RRset, but one 384 should have been present. The supplemental data contains the name 385 and RR type of the data that should have been signed, in the format 386 specified in Section 2.4.2.2. 388 2.4.5.3. DNSKEY Missing 390 Diagnostic code 1026: No DNSKEY was found, but one should have been 391 present. The supplemental data contains the zone apex name at which 392 the DNSKEY should have been found, in wire format. 394 2.4.5.4. Key Tag Mismatch 396 Diagnostic code 1027: RRSIG records have been found for an RRset 397 which is to be validated, but none of them has a key tag matching a 398 valid DNSKEY. The supplemental data contains the name and covering 399 RR type for the faulty RRSIG, in the format specified in 400 Section 2.4.2.2. 402 2.4.5.5. DS Missing 404 Diagnostic code 1028: No DS record was found, but there should have 405 been one present. The supplemental data contains the name at which 406 the DS record should have been found. 408 2.4.5.6. Next-Secure Record Missing 410 Diagnostic code 1029: No NSEC [RFC4034] or NSEC3 [RFC5155] record was 411 found, but there should have been one present. The supplemental data 412 contains the name and RR type (NSEC or NSEC3) of the record that was 413 expected, in the format specified in Section 2.4.2.2. 415 2.4.5.7. Overreaching Next-Secure Record 417 Diagnostic code 1030: The "next owner" name in an NSEC or NSEC3 418 record goes beyond another record which is known to exist. The 419 supplemental data contains the name and RR type (NSEC or NSEC3) of 420 the invalid record, in the format specified in Section 2.4.2.2. 422 2.4.5.8. Next-Secure Record Pointing Backward 424 Diagnostic code 1031: The ordering of records in the NSEC or NSEC3 425 chain does not follow canonical ordering rules. The supplemental 426 data contains the name and RR type (NSEC or NSEC3) of the invalid 427 record, in the format specified in Section 2.4.2.2. 429 2.4.5.9. Irrelevant Proof 431 Diagnostic code 1032: A proof of non-existence was provided for a 432 record whose non-existence did not need to be proven. This code has 433 no supplemental data. 435 2.4.5.10. Incomplete Proof 437 Diagnostic code 1033: Proof of non-existence is incomplete. The 438 supplemental data contains the name and RR type of the data whose 439 non-existence needed to be proven, in the format specified in 440 Section 2.4.2.2. 442 2.4.5.11. Wrong RRSIG Owner 444 Diagnostic code 1034: The RRSIG being used for verification is 445 incorrect for the RR in question. The supplemental data contains the 446 name and covering RR type of the invalid RRSIG, in the format 447 specified in Section 2.4.2.2. 449 2.4.5.12. Unknown DNSKEY Protocol 451 Diagnostic code 1035: The DNSKEY protocol value is not set to 3. The 452 supplemental data contains the name and tag of the faulty key, in the 453 format specified in Section 2.4.3.1. 455 2.4.5.13. DS/DNSKEY Mismatch 457 Diagnostic code 1036: A mismatch was found between the DNSKEY in a 458 zone and the DS record in the parent. The supplemental data contains 459 the name and tag of the DNSKEY that should have been found, in the 460 format specified in Section 2.4.3.1. 462 2.4.5.14. Unknown Algorithm 464 Diagnostic code 1037: An algorithm specified in a DNSKEY, DS, RRSIG, 465 NSEC3 or NSEC3PARAM record is not recognized by the server. The 466 supplemental data contains the name and RR type of the record that 467 referenced the invalid algorithm. 469 2.4.5.15. Algorithm Not Supported 471 Diagnostic code 1038: An algorithm specified in a DNSKEY, DS, RRSIG, 472 NSEC3 or NSEC3PARAM record is recognized by the server but is not 473 implemented. The supplemental data contains the name and RR type of 474 the record that referenced the unsupported algorithm. 476 2.4.5.16. Not a Zone Key 478 Diagnostic code 1039: The key that is used to verify signatures on 479 zone data does not have the "Zone Key" flag [RFC4034] set. The 480 supplemental data contains the name and tag of the faulty key, in the 481 format specified in Section 2.4.3.1. 483 2.4.5.17. Key Revoked 485 Diagnostic code 1040: A key that is required to complete a chain of 486 trust has its REVOKED bit [RFC5011] set. The supplemental data 487 contains the name and tag of the revoked key, in the format specified 488 in Section 2.4.3.1. 490 3. Security Considerations 492 An ESD option response contains channel diagnostic data, to be used 493 for logging, troubleshooting, and debugging; it falls outside the 494 scope of DNSSEC per se. Ensuring integrity of the response requires 495 the use of a channel security mechanism such as TSIG [RFC2845] or 496 SIG(0) [RFC2931]. In the absence of any such mechanism, ESD 497 responses MUST NOT be used by clients to make policy decisions with 498 respect to DNSSEC validation, as this could allow an attacker to 499 force a security downgrade or denial of service by forging SERVFAIL 500 messages containing particular ESD responses. 502 Some of the data in an ESD option response may be security sensitive, 503 particularly those responses which increase the transparency of the 504 current state of a running resolver. In the case of SERVFAIL 505 responses due to authoritative server misconfiguration or other non- 506 local conditions, this is generally not a concern, as the data which 507 caused the failure are readily available in the DNS and can be 508 obtained by other means. However, information about server failures 509 due to local problems such as out-of-memory conditions may be of 510 tactical use to an attacker. Implementors may wish to provide a 511 mechanism for operators to disable certain types of diagnostic 512 response while allowing others. 514 4. IANA Considerations 516 IANA is requested to make the assignments in this section. 518 4.1. ESD Option Code 520 This document requests the allocation of an EDNS(0) option code for 521 the ESD option, whose value is [TBD]. 523 4.2. Diagnostic Codes 525 This document requests the creation of a new registry of ESD 526 diagnostic codes. The registry policy is "Specification Required" 527 [RFC5226]. The initial entries in the registry are: 529 +------------+--------------------------------------+-----------+ 530 | Value | Description | Reference | 531 +------------+--------------------------------------+-----------+ 532 | 0 | No Error | | 533 | 1 | Internal Error | [This] | 534 | 2 | Out of Memory | [This] | 535 | 3 | Resource Unavailable | [This] | 536 | 4 | Zone Not Loaded | [This] | 537 | 5 | Invalid Zone | [This] | 538 | 6 | Configuration Error | [This] | 539 | 7 | Timeout | [This] | 540 | 8 | Shutting Down | [This] | 541 | 9-255 | Unassigned | | 542 | 256 | Lame Delegation | [This] | 543 | 257 | Name Expansion Failure | [This] | 544 | 258 | Protocol Not Supported | [This] | 545 | 259-511 | Unassigned | | 546 | 512 | Key Too Large | [This] | 547 | 513 | Key Too Small | [This] | 548 | 514 | Key Not Authorized | [This] | 549 | 515 | Algorithm Refused | [This] | 550 | 516 | Unauthorized Signer | [This] | 551 | 517 | No Trust Anchor | [This] | 552 | 518 | Too Many Links | [This] | 553 | 519 | Response Blocked | [This] | 554 | 520-767 | Unassigned | | 555 | 768 | Signature Expired | [This] | 556 | 769 | Signature Not Yet Active | [This] | 557 | 770 | Trust Anchor Expired | [This] | 558 | 771-1023 | Unassigned | | 559 | 1024 | Bogus Data | [This] | 560 | 1025 | Signature Missing | [This] | 561 | 1026 | DNSKEY Missing | [This] | 562 | 1027 | Key Tag Mismatch | [This] | 563 | 1028 | DS Missing | [This] | 564 | 1029 | Next-Secure Record Missing | [This] | 565 | 1030 | Overreaching Next-Secure Record | [This] | 566 | 1031 | Next-Secure Record Pointing Backward | [This] | 567 | 1032 | Irrelevant Proof | [This] | 568 | 1033 | Incomplete Proof | [This] | 569 | 1034 | Wrong RRSIG Owner | [This] | 570 | 1035 | Unknown DNSKEY Protocol | [This] | 571 | 1036 | DS/DNSKEY Mismatch | [This] | 572 | 1037 | Unknown Algorithm | [This] | 573 | 1038 | Algorithm Not Supported | [This] | 574 | 1039 | Not a Zone Key | [This] | 575 | 1040 | Key Revoked | [This] | 576 | 1041-65535 | Unassigned | | 577 +------------+--------------------------------------+-----------+ 579 5. Acknowledgments 581 Thanks to Wes Hardaker, Jakob Schlyter, Sam Weiler and Francis Dupont 582 for assistance in categorizing SERVFAIL error types, and Paul Vixie 583 for design input. 585 6. References 587 6.1. Normative References 589 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 590 STD 13, RFC 1034, November 1987. 592 [RFC1035] Mockapetris, P., "Domain names - implementation and 593 specification", STD 13, RFC 1035, November 1987. 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, March 1997. 598 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 599 RFC 2671, August 1999. 601 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 602 Wellington, "Secret Key Transaction Authentication for DNS 603 (TSIG)", RFC 2845, May 2000. 605 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 606 SIG(0)s)", RFC 2931, September 2000. 608 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 609 Rose, "Resource Records for the DNS Security Extensions", 610 RFC 4034, March 2005. 612 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 613 Trust Anchors", RFC 5011, September 2007. 615 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 616 Security (DNSSEC) Hashed Authenticated Denial of 617 Existence", RFC 5155, March 2008. 619 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 620 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 621 May 2008. 623 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 624 DNS", RFC 6672, June 2012. 626 6.2. Informative References 628 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 630 Author's Address 632 Evan Hunt 633 ISC 634 950 Charter St 635 Redwood City, CA 94063 636 USA 638 Email: each@isc.org