[dns-operations] does anybody know why yahoo+akamai are doing this?

[Edward Lewis]

At 17:58 +0000 3/23/06, Paul Vixie wrote:

>but note, since yahoo.com's nameservers are not listed in anybody's
>resolv.conf files and are not in any NS RRset for either of the zones
>you asked about, that it should never hear the queries you describe, and
>would be within its rights to just drop them on the floor, or answer with
>REFUSED in both cases.

"Not listed" - that's exactly why I asked the specific question. 
Upward referrals are all about lameness which is triggered only in 
such a situation.

Do you think the protocol ought to define a return code that 
indicates that the server has no means to answer the query?

>(note that to keep DNS out of the DDoS food chain, REFUSED really has to
>become rate-limited, even if that simulates "selective line loss".  sorry.)

If the bit size of a response is < or = the bit size of the query, is 
the DNS any part of the DDoS food chain?  If the response has 
RCODE=Lame, ANCOUNT=0, NSCOUNT=0, and ADCOUNT=0, is there 
amplification?

I'd really prefer if we could avoid a design in which the is 
disincentive to respond to a query.

My motivation - I once was asked to write a tool detecting lame 
delegations.  I had a large number of tests to run, so I was looking 
for heuristics to shorten the time.  I figured that if a server was 
registered for a lot of zones but didn't answer queries for the first 
few of them (to counter network blips), I'd write off the server as 
down, lame for all the zones on it.

But I discovered a certain server that answered for just a few zones, 
dropping the rest.  Because of this, I desided to do complete tests 
on downed servers, having to do a lot of queueing of timeing-out 
queries and a lot of bookkeeping.

I don't like having protocols in an "uncertain" state.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...