[dns-operations] CERT VU#800113 Multiple DNS implementations vulnerable to cache poisoning
rick.jones2 at hp.com
Sat Jul 12 00:31:04 UTC 2008
Paul Vixie wrote:
>>Making the broad handwaving assumpion that a DNS query is more or less
>>like a static DNS query in its overhead, one can look at the _ancient_
>>SPECweb96 results and see that single-core systems were doing several
>>1000's of URLs a second, even without having to resort to in-kernel http
> how about 100K's of TPS, which is where a lot of dns benchmarks top out?
SPECweb96 was retired before systems got to that level :) An old 8-way
PA-RISC system was at 24K, and that was surpassed by an IBM system in
the 11th hour of the benchmark's lifetime. This is ca 2000.
>>If one doesn't like that handwaving, SPECweb99 has "dynamic" content
>>that could be considered "closer" to what a DNS server does.
>>Those were serving many thousand simultaneous sessions.
> do you think it's also reasonable to worry about the 7 packet minimum
> TCP size vs. the 2 packet UDP size, and the number of RTT's that add
> in, and the slot occupancy time average, and the working set size of
Sure. That's what benchmarks are for - to sooth the fear uncertainty
and doubt we toss about in email :) Maybe I'll even be able to put my
money where my typing is and actually run some.
The last time I had non-trivial DNS server overhead data was very long
ago - the user/space kernel split was about 50/50 (53/47 actually) and
very little of the user space time involved socket calls,it was
searching through the "database." If I ass-u-me (well, perhaps more an
ass of me than anyone else :) that is still the split with 9.5 then
kernel goes up by 7/2 (handwaving that with CKO the cost of a
packet/segment is pretty much equal regardless of type) so we have 50 +
175 or 225 rather than 100 so I need what 2.25X the CPU oomph I had
before. Adjust as necessary for current user/kernel spits.
Actually, given HTTP tunings from the past and perhaps a bit of tweaking
on the server side, we can get that down to 6/2:
SYN; SYN|ACK; ACK,Req; Rsp,FIN; FIN|ACK; ACK
Assuming we aren't going to have persistent DNS TCP connections and what
that might do to FD management up in the server.
We would have one more RTT per hop to get the answer - one RTT for the
establishment, one RTT for the query (previous HTTP tuning means the
query can be carried with the "client's" ACK of the "server's" SYN|ACK).
The RTT for the connection close is not in the latency path for
getting the result.
I suspect the bulk of the additional overhead for the PCB's comes from
TIME_WAIT. HTTP tuning got that rather shrunk, and whether that heavily
affects the servers depends on who closes first.
never fears having an emily litella moment :)
More information about the dns-operations