[dns-operations] CERT VU#800113 Multiple DNS implementations vulnerable to cache poisoning

[Rick Jones]

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 
>>acceleration.
> 
> 
> 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
> PCB's?

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.

rick jones
never fears having an emily litella moment :)