Subject: edns0-bis submitted

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Feb 2008 19:43:57 +0000

the -00 draft was submitted to [email-masked] last night but has
not shown up yet (presumably the secretariat is busy).  a courtesy copy can
be read at

http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 27 Feb 2008 17:08:40 +0200

> http://sa.vix.com/~vixie/draft-ietf-dnsext-rfc2671bis-edns0-00.txt

Back in 2002, David Conrad pointed out some problems with the
interaction between EDNS0 and DNSSEC in

  <http://www.ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01798.html>

It seems to me that this update fails to address those problems, and
may even make them them worse by explicitly allowing requestors to take
packet loss as an indication that a responder doesn't support EDNS0.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 27 Feb 2008 17:33:01 +0000

> packet loss as an indication that a responder doesn't support EDNS0.

i don't think there is a fix for the problem david describes.  does anybody
have any suggestions, given that EDNS is deployed, and useful, and necessary,
and DNSSEC is not deployed, and may not be finished yet (see NSEC3 and DLV),
and the world is not exactly beating a path to DNSSEC's door?

"send diffs."

---

From: Brian Dickson <[email-masked]>
Date: Wed, 27 Feb 2008 16:38:31 -0500

> and the world is not exactly beating a path to DNSSEC's door?
Well, what about having some way to detect EDNS0 capability, via a 
non-EDNS0 query?

Rather than doing what effectively amounts to negative caching, do 
backwards-compatible forward probing.

Since servers supporting EDNS0 are much more likely to be running more 
recent code, and more likely
to update their code reasonably often (more than once a decade), a 
recommended future implementation "hack",
that allows signaling capabilities in the data itself, is one 
possibility that is definitely feasible and doesn't require
changes to the protocol proper, per se.

E.g. similar to the 'id.server CH txt "foo.bar"', something similar that 
says 'edns0.server CH txt "yes"'.

Thoughts?

Brian Dickson

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 27 Feb 2008 22:38:04 +0100

Source of confusion, and possible lack of perceived interest:

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-00.txt

Same file name different content: http://tinyurl.com/yvnxlr

The new draft may not appear given the conflict in filename. I do not  
know exactly how the software/secretariat deals with this.

--Olaf

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Feb 2008 10:21:45 +1100

> and the world is not exactly beating a path to DNSSEC's door?

	You just don't take packet loss as a indication of no EDNS
	support.  A RFC 1034 nameserver should respond to EDNS
	packets.  One that doesn't is not RFC compliant.  RFC 1034
	had error codes for a reason.  They are supposed to be used.

	The only transitions allowed for packet loss should be.

		EDNS -> EDNS @512 (for broken firewalls)

	If a firewall is not going to allow EDNS though then it should be
	responding to the query with FORMERR.

	I'm tempted to say don't do any fallbacks on packet loss and
	just treat "packet loss" as "packet loss".

	Mark

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

---

From: Chris Thompson <[email-masked]>
Date: Wed, 27 Feb 2008 23:59:55 +0000 (GMT)

> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-00.txt

(updated 28 December)

Yup, thank you for the clarification(?). My original thought when I saw
Paul Vixie's message was "but I had that one month(s) ago". And also,
"how does Paul know how many times it has been fetched from the Internet 
Drafts mirrors, anyway?". Not to mention "I fetch them by ftp, dammit,
not http, like it or lump it".

-- 
Chris Thompson
Email: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Feb 2008 00:42:45 +0000

> not http, like it or lump it".

olafur told me to resubmit it as a -00 before the -00 deadline so i did.

i'll change it to say -01 and submit it again.

---

From: Evan Hunt <[email-masked]>
Date: Thu, 28 Feb 2008 01:57:04 +0000

> i don't think there is a fix for the problem david describes.

The problem he describes--part of it, anyway--is that an RCODE of
SERVFAIL, FORMERR or NOTIMPL is ambiguous; it might mean "What is
this 'EDNS0' of which you speak?" or it might mean some other stuff.

However, section 5.1 of the draft says including an OPT RR in a
message unambiguously declares that the server *does* grok EDNS0.

So, tie them together:  A responder MUST include an OPT RR in any
message to an EDNS0 requestor, even if the message is a SERVFAIL,
NOTIMPL, or FORMERR.  No more ambiguity; if the OPT is there, that
means the error was *not* related to a lack of EDNS0 support.

(For all I know that may already be SOP among server implementations;
it seems worth specifying anyway.)

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Feb 2008 13:53:33 +1100

> this 'EDNS0' of which you speak?" or it might mean some other stuff.

	SERVFAIL is query dependent.

	FORMERR/NOTIMPL is server dependent.