https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #11 from Sidney Markowitz <[email protected]> 2010-01-27 11:37:01 UTC --- (in reply to comment 10) You are correct that the fix to Dan Kaminsky's security problem involved making the port unpredictable, but wouldn't that imply using a port number selected randomly from the entire space of available ports within the 16 bit space? A single server can't keep reusing the same one or few port numbers because then an attacker can spend a little time looking at which ones are being used and it would be predictable. So I would think that maybe we get what we need from the security fix. I haven't had time to test this out, but when we were working on this, before the big DNS security fix, I found that when the OS chose the port it wold just start with the first number in the available range, then increment the port number with each new port, and do that with each process. It woud be interesting to see what the pattern looks like now. I don't see how we can make a timeout work. here is what happens: A query is sent out on port A with 16-bit ID B. No response is received within the lifetime of the listener and the listener times out. Possibly another process sends out a query that also is on port A with ID B. Then the reply from the first query finally arrives from the remote nameserver, arriving on port A with ID B, and that reply is incorrectly processed by the listener that is waiting for the reply to the second query. Where can we or the sysadmin put a timeout that would help in that scenario? The purpose of randomising the port is so that the probability of the almost 32-bit combination of port and ID colliding is too low to worry about. If too few port numbers are used the probability of collision on just the 16 bit ID is too high for the number of DNS queries that are generated in a high volume situation. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
