idnits 2.17.1 draft-spacek-edns-camel-diet-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 (March 19, 2018) is 2227 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: 'RFC1035' is defined on line 99, but no explicit reference was found in the text == Unused Reference: 'RFC2671' is defined on line 103, but no explicit reference was found in the text == Unused Reference: 'RFC6891' is defined on line 107, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Spacek 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track O. Gudmundsson 5 Expires: September 20, 2018 Cloudflare 6 O. Sury 7 ISC 8 March 19, 2018 10 Minimal EDNS compliance requirements 11 draft-spacek-edns-camel-diet-00 13 Abstract 15 DNS responders must either follow RFC 6891 by implementing EDNS or 16 respond with RCODE=FORMERR to queries containing OPT record. Non- 17 compliant implementations are not worth talking to. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 20, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 2 57 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 2 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 6. Normative References . . . . . . . . . . . . . . . . . . . . 3 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3 62 1. Introduction 64 EDNS version 0 was standardized in 1999, but non-RFC 1035 compliant 65 implementations still exist and cause lot of extra queries and 66 complicated logic in recursive resolvers. RFC 6891 clearly states 67 that FORMERR is the only acceptable answer for implementations 68 without support for EDNS. The cost of supporting these non-compliant 69 implementations keeps increasing. 71 1.1. Terminology 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119. 77 2. The Protocol 79 No DNS response message to a repeated DNS query containing EDNS 80 extension means that the other side is not a DNS responder and the 81 querier MUST NOT retry its query without EDNS. 83 3. Security Considerations 85 Instruction to follow EDNS standard does not change security 86 properties beyond what is written in RFC 6891. 88 4. Privacy Considerations 90 This has no effect on privacy of DNS. 92 5. IANA Considerations 94 [Note to IANA, to be removed prior to publication: there are no IANA 95 considerations stated in this version of the document.] 97 6. Normative References 99 [RFC1035] Mockapetris, P., "Domain names - implementation and 100 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 101 November 1987, . 103 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 104 RFC 2671, DOI 10.17487/RFC2671, August 1999, 105 . 107 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 108 for DNS (EDNS(0))", STD 75, RFC 6891, 109 DOI 10.17487/RFC6891, April 2013, 110 . 112 Authors' Addresses 114 Petr Spacek 116 Email: petr.spacek@nic.cz 118 Olafur Gudmundsson 120 Email: olafur+ietf@cloudflare.com 122 Ondrej Sury 124 Email: ondrej@isc.org