Subject: Re: EDNS0 revisions

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Jan 2008 12:22:18 +1100

> At 9:13 +1100 12/22/07, Mark Andrews wrote:
> 
> >	I think formalising the reaction to timeout for EDNS failues
> >	to fall back to plain DNS is wrong.  As dependany of EDNS
> >	increases (e.g. DNSSEC) it is much more important that
> >	packet loss is treated as packet loss and not broken servers
> >	/ middle boxes.
> 
> I side with Paul's opinion - it's better to let non responses cause 
> state changes.  In 2004 or so I ran some tests for lame servers and 
> observed these two things:

> 1) I would reissue a query up to 10 times before giving up to see 
> what was the tipping point - at what point were retries generally not 
> worth the effort.  From my now lost records and dusty memory, 
> counting 100% as the pool of queries ever answered, over 99% were 
> answered on the first try.  The number answering to the 2nd, 3rd, 
> ..., 10th try, never went to 0 but were all pretty negligible.
> 
> Caveat - YMMV...as is always the case with any experiment.  I was on 
> an office-grade T-1 and self-rate-limited the UDP's out so they 
> didn't trip on themselves at the first hop.

	Yet we know that there are clients behind overloaded links.
	These clients should be able to talk to EDNS servers like
	they talk to DNS servers.  A timeout should not trigger
	fallback to DNS.  Repeated timeouts to the same server
	could protentially trigger a fallback.
 
> 2) There are name server implementations that will silently discard a 
> query by policy.  One implementation refused to respond to any query 
> it felt it wasn't supposed to see.  I would have expected (as BIND 
> does in this case) to see a referral to the root.

	And such behaviour should be specifically discouraged as
	it overloads what timeout means.  It turns configuration
	errors into denial of service attacks against caching
	servers.  RFC 1034 has REFUSED for a reason.
 
> After some discussion I was convinced that there was merit to this 
> approach, although the puritanical client-server protocol guy I am 
> bristles with the notion that silence means error.  But that's the 
> network we have now.
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> Think glocally.  Act confused.
> 
> --
> 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/>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 2 Jan 2008 09:55:53 -0500

At 12:22 +1100 1/2/08, Mark Andrews wrote:
>Responding to my (Ed) words :

I said that in the sense that I was careful not to drop many packets 
at my end.  The experiment was a "fan out" - no single server got 
many requests (one per zone it was alleged to be serving neglecting 
retries).

>	could protentially trigger a fallback.

There's a tradeoff between complexity and results.  If a 
query-issuing DNS process was thorough it would keep tabs on sources 
like we keep mental notes on local restaurants.  But all that work on 
top of managing sessions on UDP is a lot of overhead (in code, not 
just in performance).

My experiment told me that for the most part, if a server is able to 
respond at all it will do so on the first try.  Under normal network 
weather conditions, a second try is usually superfluous (wasted 
effort).

>>  query by policy.
...
>>  bristles with the notion that silence means error.  But that's the

I feel compelled to repeat the previous paragraph again, but it's 
there and this is the second time I've sent it in a message - so I 
guess I did repeat it.

One technique in operations to stop a flood of traffic from a single 
source is to black hole all traffic from that IP address (block, 
etc.).  This is done at layer 3, not layer 7.  Usually the source in 
this case is not playing nicely anyway and is not retrying the 
unanswered queries.  In this sense, when abuse is suspected it's okay 
to not answer.  One implementation just believes that queries "it 
feels it shouldn't be seeing" is a symptom of abuse.  As much as I 
feel that is overly paranoid, I also see the point.