Subject: Re: [dnsext] Support for EDSN0 PING

From: Mark Andrews <[email-masked]>
Date: Mon, 01 Jun 2009 10:04:24 +1000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

In message <[email-masked]>, Paul Vixie writes:
> > From: Florian Weimer <[email-masked]>
> > Date: Sun, 31 May 2009 10:44:33 +0200
> > 
> > * Paul Vixie:
> > 
> > > it's controversial because it only works when it works, and when it
> > > fails, there's no distinction between an attack and a failure.  we were
> > > not idiots back in the old days when EDNS was being crafted.  we knew
> > > we needed a larger QID.  we tried hard to include it.  there's no way
> > > to do it and still properly negotiate EDNS.
> > 
> > But this is not the fault of any extended query ID proposal, it's the
> > fault of EDNS.
> 
> right.
> 
> > DNSCurve shows a fully backwards-compatible way to signal protocol
> > version information to recursive resolvers.
> > 
> > I mean, let's look at what elements of EDNS0 actually work:
> > 
> >   * extended RCODEs (but I'm not sure about that)

	extended RCODEs were badly done.  We should have had a basic
	rcode which indicated that there was a extended rcode in the
	OPT record.  Concatentating the bits was a bad idea.
 
> >   * extended query flags (the DO bit seems pretty interoperable, even
> >     though it's overused, but this is not EDNS0's fault)
> > 
> > What does not work:
> > 
> >   * the official fallback algorithm (section 5.3)

	It actually works quite well 99.999% of the time.  It doesn't
	work when you talk to non RFC 1034 compliant servers or you
	have firewalls that interfere with DNS UDP messages.

	To work around non-compliant servers and firewalls a second
	fallback algorithm is needed to take into account timeouts.

> >   * large responses (interoperability problems, DoS amplification)

	Moving to SCTP won't get rid of the DoS amplification problem
	as we can never stop servicing UDP/53 queries.  BCP 38
	deployment is the best way to stop DoS amplifications.

> >   * extended label types (already officially dead)
> >
> >   * options (a FORMERR/SERVFAIL does not tell you which option caused
> >     the error, making fallback impossible; there is also a significant
> >     non-interoperating server base)
> >
> > I wonder if there should be an actually working EDNS0 replacement
> > which could then be used to implement extended query IDs.
> 
> you forgot "fragmentation is bad".  (dnscurve avoids this with small crypto.)

DNSCurve still requires fragmentation.  Support for 4K UDP buffers messages
is implied with DNSCurve.

> TCP/53 is unusable for queries for a variety of reasons of its own.
> 
> that's why i'm pounding the table for SCTP/53, on which EDNS wouldn't be
> optional, therefore avoiding the fallback problems.  EDNS PING isn't needed
> in SCTP due to SCTP's own transport protection, but if needed it would work,
> since EDNS would not be optional (no fallback problem.)
> 
> --
> 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/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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/>