Network Working Group E. Hunt Internet-Draft ISC Intended status: Experimental July 31, 2013 Expires: February 1, 2014 The DNS Extended Server Diagnostics (ESD) Option draft-hunt-dns-server-diagnostics-00 Abstract The widespread adoption of DNSSEC implies more frequent DNSSEC failures. Unfortunately, DNSSEC's failure mode is largely opaque to the client: when validation fails, the only signal that the clients of a validating resolver receive is an empty response with a SERVFAIL response code. This note proposes a protocol extension to allow SERVFAIL responses to include additional diagnostic information, giving the client greater insight into what went wrong and a better chance of delivering useful problem reports to DNS operators. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 1, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Hunt Expires February 1, 2014 [Page 1] Internet-Draft dns-server-diagnostics July 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 4 2.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 2.3. The ESD Option . . . . . . . . . . . . . . . . . . . . . . 4 2.4. ESD Diagnostic Codes . . . . . . . . . . . . . . . . . . . 5 2.4.1. Internal Server Errors . . . . . . . . . . . . . . . . 5 2.4.2. General DNS Errors . . . . . . . . . . . . . . . . . . 6 2.4.3. Policy-Dependent Security Errors . . . . . . . . . . . 7 2.4.4. Temporary Security Errors . . . . . . . . . . . . . . 8 2.4.5. Fatal Security Errors . . . . . . . . . . . . . . . . 9 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4.1. ESD Option Code . . . . . . . . . . . . . . . . . . . . . 12 4.2. Diagnostic Codes . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Hunt Expires February 1, 2014 [Page 2] Internet-Draft dns-server-diagnostics July 2013 1. Introduction DNSSEC's failure mode is largely opaque to the client: when validation fails, the only signal of this that a resolver's clients receive is a SERVFAIL response code. With no information provided to explain the exact cause of a SERVFAIL response, there is no straightforward way for an end user to determine whether a failure occurred due to a broken local resolver, a zone misconfiguration such as expired signatures, or a spoofing attack. This makes it difficult to address complaints and problem reports to the right people, slowing the correction of DNSSEC errors while increasing the support burden on validating resolver operators. This note proposes a protocol extension allowing a name server, upon request from a client, to accompany SERVFAIL responses with detailed diagnostic information indicating what specifically caused the failure. In the typical use case for this mechanism, a validating caching name server would be able to convey specific failure information to a non-validating stub resolver or other client. 1.1. Reserved Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Protocol A DNS client such as a non-validating stub resolver may use an EDNS(0) [RFC2671] option, ESD, to solicit extended diagnostic information from a DNS server. The ESD option payload includes a 16- bit "flags" field and a 16-bit diagnostic code; additional payload data may be included in the response. One bit in the "flags" field is defined as "human-readable": if this bit is set in the solicitation, it indicates a desire for the server to return human-readable text, in addition to machine-readable diagnostic data; this text can be displayed or sent to a logging facility such as syslog [RFC5424]. All other payload data MUST be left empty in the solicitation. The response payload, in addition to the flags field and the diagnostic code, may also include a supplemental data field whose content and schema are dependent on the diagnostic code being returned. If the "human-readable" flag is set in the response, then the response also includes human-readable text in a counted string, Hunt Expires February 1, 2014 [Page 3] Internet-Draft dns-server-diagnostics July 2013 i.e., a single length octet followed by that number of characters, as in the TXT RDATA format [RFC1035]. 2.1. Client Behavior A stub resolver or other DNS client requests extended diagnostic data by sending an ESD option (Section 2.3) in an EDNS(0) OPT pseudo-RR in the query message. The requestor MAY set the "human-readable" bit in the flags field of the request payload. The requestor MUST NOT include any other payload data in the ESD option. The requestor MUST ignore any ESD option included in a response that does not have response code SERVFAIL. 2.2. Server Behavior A resolver or other name server which encounters a server failure while answering a query that included an ESD option MAY add an ESD option to the SERVFAIL response. If the query did not include an ESD option, then the response MUST NOT include one. The server MUST NOT include an ESD option in any non-SERVFAIL response. 2.3. The ESD Option The OPTION-CODE for the ESD option is [TBD]. The format for the OPTION-DATA portion of an ESD option is shown below: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FLAGS |H| DIAGCODE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ HRTEXT (optional, resonse only) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ SUPPDATA (optional, response only) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in which the fields are defined as follows: FLAGS A 16-bit field. Bit 15 (H) is defined to mean "human- readable"; when set in the solicitation, this bit signals a desire for human-readable text to be included in the response; when set in the response, it signals that such text has been included. All other bits in the field MUST be set to zero. Hunt Expires February 1, 2014 [Page 4] Internet-Draft dns-server-diagnostics July 2013 DIAGCODE A 16-bit diagnostic code (Section 2.4) indicating the reason for the SERVFAIL response. In the solicitation payload, this field MUST be set to zero. HRTEXT An counted string, containing human-readable text suitable for logging. The first octet defines the length of the following text; if the first octet contains 0, the string is emty. This is intended as an opaque string to be passed through to a logging mechanism; content and encoding are outside the scope of the protocol. This field MUST NOT be included in a solicitation payload. SUPPDATA Optional supplementary data about the cause of the server failure. The presence or absence, content, and schema of this field are entirely dependent on the diagnostic code being returned in the DIAGCODE field (Section 2.4). This field MUST NOT be included in a solicitation payload. 2.4. ESD Diagnostic Codes Diagnostic codes are grouped in five general categories: Internal server error conditions (diagnostic codes 1-255), general DNS failures (256-511), policy-dependent security errors (512-767), temporary security errors (768-1023), and fatal security errors (1024-1279). Space has been reserved in the namespace for additional categories and codes. All diagnostic codes are optional; there is no requiremnt to impelement all of them. The DIAGCODE field MUST be set to zero (No Error) in ESD solicitations. 2.4.1. Internal Server Errors These diagnostic codes indicate a system failure in the responding server. 2.4.1.1. Internal Error, Not Otherwise Specified Diagnostic code 1 indicates an unspecified internal server error unrelated to DNSSEC. A server MAY return this code in place of any other internal server error, at the discretion of the implementor or operator, if information about the internal state of the server is regarded as security sensitive. This code has no supplemental data. 2.4.1.2. Out of Memory Diagnostic code 2 indicates that the server was not able to dynamically allocate memory. This code has no supplemental data. Hunt Expires February 1, 2014 [Page 5] Internet-Draft dns-server-diagnostics July 2013 2.4.1.3. Resource Unavailable Diagnostic code 3 indicates that a needed resource was not available. This code has no supplemental data. 2.4.1.4. Zone Not Loaded Diagnostic code 4: The server has been configured to be authoritative for a zone which is an ancestor of the query name, but was unable to load it. The supplemental data contains the name of the zone the server was unable to load, in DNS wire format. 2.4.1.5. Invalid Zone Diagnostic code 5: The server has been configured to be authoritative for a zone which is an ancestor of the query name, but the zone contents are invalid; for example, there is no SOA RR or NS RRset at the zone apex. The supplemental data contains the name of the zone in DNS wire format. 2.4.1.6. Configuration Error Diagnostic code 6: The server could not be initialized, e.g., as a result of an error in loading or parsing the configuration file. This code has no supplemental data. 2.4.1.7. Timeout Diagnostic code 7: Query processing timed out. This code has no supplemental data. 2.4.1.8. Shutting Down Diagnostic code 8: The server is shutting down. This code has no supplemental data. 2.4.2. General DNS Errors These codes describe failure conditions due to bad or inconsistent data in the DNS not specifically related to DNSSEC. 2.4.2.1. Lame Delegation Diagnostic code 256: The name servers which have been delegated responsibility for a zone cannot be reached or are not performing name service for that zone. The supplemental data contains the zone apex name of the faulty zone. Hunt Expires February 1, 2014 [Page 6] Internet-Draft dns-server-diagnostics July 2013 2.4.2.2. Name Expansion Failure Diagnostic code 257: A CNAME [RFC1034] or DNAME [RFC6672] record fails sanity checks after name expansion. The supplemental data contains the name and RR type (CNAME or DNAME) of the faulty record, in the following format: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RRTYPE | NAME \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.4.2.3. Protocol Not Supported Diagnostic code 258: Processing this query requires a protocol extension that is not supported. This code has no supplemental data. 2.4.3. Policy-Dependent Security Errors These are errors returned due to locally-configured policy constraints on DNSSEC processing or other security considerations. 2.4.3.1. Key Too Large Diagnostic code 512: Local policy disallows a DNSKEY being used to validate a record on the grounds that it is too large. The supplemental data specifies the owner name (in DNS wire format) and key tag of the problematic DNSKEY, using the following format: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAG | NAME \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.4.3.2. Key Too Small Diagnostic code 513: Local policy disallows a DNSKEY being used to validate a record on the grounds that it is too small. The supplemental data contains the nam5 and tag of the problematic key, in the format specified in Section 2.4.3.1. 2.4.3.3. Key Not Authorized Diagnostic code 514: Local policy does not authorize a key to be used for validation. The supplemental data contains the name and tag of the problematic key, in the format specified in Section 2.4.3.1. Hunt Expires February 1, 2014 [Page 7] Internet-Draft dns-server-diagnostics July 2013 2.4.3.4. Key Algorithm Refused Diagnostic code 515: Local policy prohibits validation using a given signing algorithm. The supplemental data contains a 16-bit unsigned integer indicating which algorithm has been disallowed. 2.4.3.5. Unauthorized Signer Diagnostic code 516: Local policy disallows accepting signatures created by this signer. The supplemental data contains the name of the signer that has been disallowed. 2.4.3.6. No Trust Anchor Diagnostic code 517: There is no trust anchor for the chain of trust needed to validate this data, but local policy requires validation. This code has no supplemental data. 2.4.3.7. Too Many Links Diagnostic code 518: The chain of trust is longer than local policy permits. This code has no supplemental data. 2.4.3.8. Response Blocked Diagnostic code 519: The response to this query has been blocked by local policy. This code has no supplemental data. 2.4.4. Temporary Security Errors These are error conditions occurring from DNSSEC processing which are time-dependent: i.e., problems due to signature validity interval or key expiry. 2.4.4.1. Signature Expired Diagnostic code 768: An RRSIG is past its useful lifetime. The supplemental data contains the name and covering RR type of the failed RRSIG, in the format specified in Section 2.4.2.2. 2.4.4.2. Signature Not Yet Active Diagnostic code 769: An RRSIG has not yet begun its useful lifetime. The supplemental data contains the name and covering RR type of the invalid RRSIG, in the format specified in Section 2.4.2.2. Hunt Expires February 1, 2014 [Page 8] Internet-Draft dns-server-diagnostics July 2013 2.4.4.3. Trust Anchor Expired Diagnostic code 770: A trust anchor can no longer be used. The supplemental data contains the name of the expired trust anchor in wire format. 2.4.5. Fatal Security Errors These error conditions due to DNSSEC processing are always fatal, regardless of time or local policy. 2.4.5.1. Bogus Data Diagnostic code 1024: Cryptographic validation failed. The supplemental data contains the name and RR type of data which failed to validate, in the format specified in Section 2.4.2.2. 2.4.5.2. Signature Missing Diagnostic code 1025: There was no RRSIG found for an RRset, but one should have been present. The supplemental data contains the name and RR type of the data that should have been signed, in the format specified in Section 2.4.2.2. 2.4.5.3. DNSKEY Missing Diagnostic code 1026: No DNSKEY was found, but one should have been present. The supplemental data contains the zone apex name at which the DNSKEY should have been found, in wire format. 2.4.5.4. Key Tag Mismatch Diagnostic code 1027: RRSIG records have been found for an RRset which is to be validated, but none of them has a key tag matching a valid DNSKEY. The supplemental data contains the name and covering RR type for the faulty RRSIG, in the format specified in Section 2.4.2.2. 2.4.5.5. DS Missing Diagnostic code 1028: No DS record was found, but there should have been one present. The supplemental data contains the name at which the DS record should have been found. 2.4.5.6. Next-Secure Record Missing Diagnostic code 1029: No NSEC [RFC4034] or NSEC3 [RFC5155] record was found, but there should have been one present. The supplemental data Hunt Expires February 1, 2014 [Page 9] Internet-Draft dns-server-diagnostics July 2013 contains the name and RR type (NSEC or NSEC3) of the record that was expected, in the format specified in Section 2.4.2.2. 2.4.5.7. Overreaching Next-Secure Record Diagnostic code 1030: The "next owner" name in an NSEC or NSEC3 record goes beyond another record which is known to exist. The supplemental data contains the name and RR type (NSEC or NSEC3) of the invalid record, in the format specified in Section 2.4.2.2. 2.4.5.8. Next-Secure Record Pointing Backward Diagnostic code 1031: The ordering of records in the NSEC or NSEC3 chain does not follow canonical ordering rules. The supplemental data contains the name and RR type (NSEC or NSEC3) of the invalid record, in the format specified in Section 2.4.2.2. 2.4.5.9. Irrelevant Proof Diagnostic code 1032: A proof of non-existence was provided for a record whose non-existence did not need to be proven. This code has no supplemental data. 2.4.5.10. Incomplete Proof Diagnostic code 1033: Proof of non-existence is incomplete. The supplemental data contains the name and RR type of the data whose non-existence needed to be proven, in the format specified in Section 2.4.2.2. 2.4.5.11. Wrong RRSIG Owner Diagnostic code 1034: The RRSIG being used for verification is incorrect for the RR in question. The supplemental data contains the name and covering RR type of the invalid RRSIG, in the format specified in Section 2.4.2.2. 2.4.5.12. Unknown DNSKEY Protocol Diagnostic code 1035: The DNSKEY protocol value is not set to 3. The supplemental data contains the name and tag of the faulty key, in the format specified in Section 2.4.3.1. 2.4.5.13. DS/DNSKEY Mismatch Diagnostic code 1036: A mismatch was found between the DNSKEY in a zone and the DS record in the parent. The supplemental data contains the name and tag of the DNSKEY that should have been found, in the Hunt Expires February 1, 2014 [Page 10] Internet-Draft dns-server-diagnostics July 2013 format specified in Section 2.4.3.1. 2.4.5.14. Unknown Algorithm Diagnostic code 1037: An algorithm specified in a DNSKEY, DS, RRSIG, NSEC3 or NSEC3PARAM record is not recognized by the server. The supplemental data contains the name and RR type of the record that referenced the invalid algorithm. 2.4.5.15. Algorithm Not Supported Diagnostic code 1038: An algorithm specified in a DNSKEY, DS, RRSIG, NSEC3 or NSEC3PARAM record is recognized by the server but is not implemented. The supplemental data contains the name and RR type of the record that referenced the unsupported algorithm. 2.4.5.16. Not a Zone Key Diagnostic code 1039: The key that is used to verify signatures on zone data does not have the "Zone Key" flag [RFC4034] set. The supplemental data contains the name and tag of the faulty key, in the format specified in Section 2.4.3.1. 2.4.5.17. Key Revoked Diagnostic code 1040: A key that is required to complete a chain of trust has its REVOKED bit [RFC5011] set. The supplemental data contains the name and tag of the revoked key, in the format specified in Section 2.4.3.1. 3. Security Considerations An ESD option response contains channel diagnostic data, to be used for logging, troubleshooting, and debugging; it falls outside the scope of DNSSEC per se. Ensuring integrity of the response requires the use of a channel security mechanism such as TSIG [RFC2845] or SIG(0) [RFC2931]. In the absence of any such mechanism, ESD responses MUST NOT be used by clients to make policy decisions with respect to DNSSEC validation, as this could allow an attacker to force a security downgrade or denial of service by forging SERVFAIL messages containing particular ESD responses. Some of the data in an ESD option response may be security sensitive, particularly those responses which increase the transparency of the current state of a running resolver. In the case of SERVFAIL responses due to authoritative server misconfiguration or other non- local conditions, this is generally not a concern, as the data which Hunt Expires February 1, 2014 [Page 11] Internet-Draft dns-server-diagnostics July 2013 caused the failure are readily available in the DNS and can be obtained by other means. However, information about server failures due to local problems such as out-of-memory conditions may be of tactical use to an attacker. Implementors may wish to provide a mechanism for operators to disable certain types of diagnostic response while allowing others. 4. IANA Considerations IANA is requested to make the assignments in this section. 4.1. ESD Option Code This document requests the allocation of an EDNS(0) option code for the ESD option, whose value is [TBD]. 4.2. Diagnostic Codes This document requests the creation of a new registry of ESD diagnostic codes. The registry policy is "Specification Required" [RFC5226]. The initial entries in the registry are: +------------+--------------------------------------+-----------+ | Value | Description | Reference | +------------+--------------------------------------+-----------+ | 0 | No Error | | | 1 | Internal Error | [This] | | 2 | Out of Memory | [This] | | 3 | Resource Unavailable | [This] | | 4 | Zone Not Loaded | [This] | | 5 | Invalid Zone | [This] | | 6 | Configuration Error | [This] | | 7 | Timeout | [This] | | 8 | Shutting Down | [This] | | 9-255 | Unassigned | | | 256 | Lame Delegation | [This] | | 257 | Name Expansion Failure | [This] | | 258 | Protocol Not Supported | [This] | | 259-511 | Unassigned | | | 512 | Key Too Large | [This] | | 513 | Key Too Small | [This] | | 514 | Key Not Authorized | [This] | | 515 | Algorithm Refused | [This] | | 516 | Unauthorized Signer | [This] | | 517 | No Trust Anchor | [This] | | 518 | Too Many Links | [This] | | 519 | Response Blocked | [This] | Hunt Expires February 1, 2014 [Page 12] Internet-Draft dns-server-diagnostics July 2013 | 520-767 | Unassigned | | | 768 | Signature Expired | [This] | | 769 | Signature Not Yet Active | [This] | | 770 | Trust Anchor Expired | [This] | | 771-1023 | Unassigned | | | 1024 | Bogus Data | [This] | | 1025 | Signature Missing | [This] | | 1026 | DNSKEY Missing | [This] | | 1027 | Key Tag Mismatch | [This] | | 1028 | DS Missing | [This] | | 1029 | Next-Secure Record Missing | [This] | | 1030 | Overreaching Next-Secure Record | [This] | | 1031 | Next-Secure Record Pointing Backward | [This] | | 1032 | Irrelevant Proof | [This] | | 1033 | Incomplete Proof | [This] | | 1034 | Wrong RRSIG Owner | [This] | | 1035 | Unknown DNSKEY Protocol | [This] | | 1036 | DS/DNSKEY Mismatch | [This] | | 1037 | Unknown Algorithm | [This] | | 1038 | Algorithm Not Supported | [This] | | 1039 | Not a Zone Key | [This] | | 1040 | Key Revoked | [This] | | 1041-65535 | Unassigned | | +------------+--------------------------------------+-----------+ 5. Acknowledgments Thanks to Wes Hardaker, Jakob Schlyter, Sam Weiler and Francis Dupont for assistance in categorizing SERVFAIL error types, and Paul Vixie for design input. 6. References 6.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. Hunt Expires February 1, 2014 [Page 13] Internet-Draft dns-server-diagnostics July 2013 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June 2012. 6.2. Informative References [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. Author's Address Evan Hunt ISC 950 Charter St Redwood City, CA 94063 USA Email: each@isc.org Hunt Expires February 1, 2014 [Page 14]