I've checked that TIDs and source ports are not random enough dumping the traffic using dnsget. Then, reading the code so I could fix it, I found the rationale from Michael Tokarev, which I reproduce below.
/* this is how we choose an identifier for a new query (qID). * For now, it's just sequential number, incremented for every query, and * thus obviously trivial to guess. * There are two choices: * a) use sequential numbers. It is plain insecure. In DNS, there are two * places where random numbers are (or can) be used to increase security: * random qID and random source port number. Without this randomness * (udns uses fixed port for all queries), or when the randomness is weak, * it's trivial to spoof query replies. With randomness however, it * becomes a bit more difficult task. Too bad we only have 16 bits for * our security, as qID is only two bytes. It isn't a security per se, n those 16 bits - an attacker can just flood us with fake * replies with all possible qIDs (only 65536 of them), and in this case, * even if we'll use true random qIDs, we'll be in trouble (not protected * against spoofing). Yes, this is only possible on a high-speed network * (probably on the LAN only, since usually a border router for a LAN * protects internal machines from packets with spoofed local addresses * from outside, and usually a nameserver resides on LAN), but it's * still very well possible to send us fake replies. * In other words: there's nothing a DNS (stub) resolver can do against * spoofing attacks, unless DNSSEC is in use, which helps here alot. * Too bad that DNSSEC isn't widespread, so relying on it isn't an * option in almost all cases... * b) use random qID, based on some random-number generation mechanism. * This way, we increase our protection a bit (see above - it's very weak * still), but we also increase risk of qID reuse and matching late replies * that comes to queries we've sent before against new queries. There are * some more corner cases around that, as well - for example, normally, * udns tries to find the query for a given reply by qID, *and* by * verifying that the query DN and other parameters are also the same * (so if the new query is against another domain name, old reply will * be ignored automatically). But certain types of replies which we now * handle - for example, FORMERR reply from servers which refuses to ss EDNS0-enabled packets - comes without all the query parameters * but the qID - so we're forced to use qID only when determining which * query the given reply corresponds to. This makes us even more * vulnerable to spoofing attacks, because an attacker don't even need to * know which queries we perform to spoof the replies - he only needs to * flood us with fake FORMERR "replies". * * That all to say: using sequential (or any other trivially guessable) * numbers for qIDs is insecure, but the whole thing is inherently insecure * as well, and this "extra weakness" that comes from weak qID choosing * algorithm adds almost nothing to the underlying problem. * * It CAN NOT be made secure. Period. That's it. * Unless we choose to implement DNSSEC, which is a whole different story. * Forcing TCP mode makes it better, but who uses TCP for DNS anyway? * (and it's hardly possible because of huge impact on the recursive * nameservers). * * Note that ALL stub resolvers (again, unless they implement and enforce * DNSSEC) suffers from this same problem. * * So, instead of trying to be more secure (which actually is not - false * sense of security is - I think - is worse than no security), I'm trying * to be more robust here (by preventing qID reuse, which helps in normal * conditions). And use sequential qID generation scheme. */ I think that using random ports together with the random qIDs may solve the robustness issue, if you don't have a "collision", which could be tracked using the queries issued themselves. This is a not a trivial patch. So, for now, I would recommend the same recommendations for glibc, regarding this issue. Thadeu Cascardo.
signature.asc
Description: Digital signature
