[dns-operations] does anybody know why yahoo+akamai are doing this?
Ed.Lewis at neustar.biz
Thu Mar 23 18:38:49 UTC 2006
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
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
Nothin' more exciting than going to the printer to watch the toner drain...
More information about the dns-operations