Subject: [DNSOP] New Version Notification for draft-spacek-edns-camel-diet-00.txt

From: Petr Špaček <[email-masked]>
Date: Wed, 21 Mar 2018 15:58:28 +0000

Hello dnsop,

draft-spacek-edns-camel-diet-00 is a new draft which partially reacts to
The Camel talk from yesterday, and is based on plan of open-source DNS
software vendors to get rid of EDNS workarounds.

This is an attempt to simplify implementations described here:
http://en.blog.nic.cz/2018/03/14/together-for-better-stability-speed-and-further-extensibility-of-the-dns-ecosystem/

We are proposing this draft for Best Current Practice status.

We are happy to discuss this on list and in dnsop session if we can
squeeze it in.

Petr Špaček  @  CZ.NIC

-------- Forwarded Message --------
Subject: New Version Notification for draft-spacek-edns-camel-diet-00.txt
Date: Wed, 21 Mar 2018 08:35:22 -0700
From: [email-masked]
To: Petr Spacek <[email-masked]>, Ondrej Sury <[email-masked]>,
Olafur Gudmundsson <[email-masked]>

A new version of I-D, draft-spacek-edns-camel-diet-00.txt
has been successfully submitted by Petr Spacek and posted to the
IETF repository.

Name:		draft-spacek-edns-camel-diet
Revision:	00
Title:		Minimal EDNS compliance requirements
Document date:	2018-03-19
Group:		Individual Submission
Pages:		3
URL:
https://www.ietf.org/internet-drafts/draft-spacek-edns-camel-diet-00.txt
Status:
https://datatracker.ietf.org/doc/draft-spacek-edns-camel-diet/
Htmlized:       https://tools.ietf.org/html/draft-spacek-edns-camel-diet-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-spacek-edns-camel-diet

Abstract:
   DNS responders must either follow RFC 6891 by implementing EDNS or
   respond with RCODE=FORMERR to queries containing OPT record.  Non-
   compliant implementations are not worth talking to.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 21 Mar 2018 20:17:08 -0400

> software vendors to get rid of EDNS workarounds.

Congratulations on an extremely short, to the point draft.  I think that's
the shortest I've ever read.
I have only one English syntax nit:  I believe "RFC 1035 non-compliant" is
the preferred form (in the Introduction).

---

From: Evan Hunt <[email-masked]>
Date: Thu, 22 Mar 2018 10:39:12 +0000

> the shortest I've ever read.

Indeed! I hesitate to offer trivial rephrasing suggestions because it
might represent such a significant percentage of the final text you'd have
to give me co-author credit. :)

That said, however, "No response...means" is ambiguous: it could be read
as "[there is] no response [which] means".  So I suggest rephrasaing
section 2 as:

  The failure of a server to respond in any way to repeateded DNS queries
  containing EDNS OPT records indicates that the server is not a DNS
  responder. The querier MUST treat this server as nonresponsive, and
  MUST NOT retry queries without EDNS.

Or something like that.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Ralph Dolmans <[email-masked]>
Date: Thu, 22 Mar 2018 12:30:25 +0100

Hi,

>From the introduction:

> EDNS version 0 was standardized in 1999, but non-RFC 1035 compliant
>    implementations still exist and cause lot of extra queries and
>    complicated logic in recursive resolvers.  RFC 6891 clearly states
>    that FORMERR is the only acceptable answer for implementations
>    without support for EDNS.

This is, although factual correct, somewhat misleading. Yes EDNS0 is
standardized in 1999, but that is not the later mentioned RFC6891 (from
2013) that requires a FORMERR RCODE. RFC2761 from 1999 talks about
"NOTIMPL, FORMERR, or SERVFAIL". I also fail to understand the relation
with RFC1035 in the first sentence.

Also the "The Protocol" section does not mention that the retrieved
RCODE (if any) is relevant in the decision whether to retry with or
without EDNS.

-- Ralph

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Mar 2018 13:05:04 +1100

> On 22 Mar 2018, at 10:30 pm, Ralph Dolmans <[email-masked]> wrote:
> 
> Hi,
> 

RFC 1035 says to return FORMERR to a EDNS request. Yes, RFC 1035 said how
to handle unknown extensions. That is what the expected behaviour of a 
STD 13 compliant server *is*.  Non STD 13 compliant servers returned 
NOTIMPL and SERVFAIL.  RFC2761 reported what was seen in the wild. 
FORMERR was the dominate rcode at the time. I don’t see anything other
than FORMERR or NOERROR these days to a plain EDNS(0) query from a non-EDNS
aware server.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]