A while ago, DNSMASQ changed to roaming client ports to prevent from being a sitting duck for [various response] attacks. Each new request forward is assigned a new client return port. This is a good. Further, the minimum port in the selection of ports can be pushed away from extended low-range server ports (min-port). This was fine in the days of homes with one desktop and maybe one laptop computer. However, this does not scale well for larger user bases behind an IPV4 NAT. Lets say a large house hold with various mobile devices or a coffee shop.
With so many ad happy sights, one browser click can kick off 50 new DNS look-ups for each ad panel and tracker-collector. Lets not forget ad happy "freemium" games on smart phones either. These port openings in the NAT have some period of stickiness and create blocks on other devices generating client ports for normal NAT return. The NAT bumps the inner-device client port about to be remapped-of-the-remap. This then affects even NAT intelligent applications requiring mutual server or per connections like skype. While the collisions probability may seem low, it can cause weird and indeterminate behavior (to the end user). It needs to be recognized how "magically" the apparently random statistics can align. DNSMASQ does allow single address like its old behavior, but we don't want that for the while ago reason. I would like to propose that DNSMASQ move the port every 6-60 seconds random per port# and also DNSMASQ move client ports when so many requests have processed (max-concurrent reused or %10 of cache or random again?). This will keep its profile on the NAT down and it will maintain the moving target against attacks. Random doesn't have to be rand(), it could just be 6 bits of the port XOR with the CPU clock or something cheap for embedded devices. (Please, I want avoid flame over IPV6 because reality is adoption is just slow still. Lets just assume that some will be stuck with ISP providing only IPV4 for a while yet.) ERIC
_______________________________________________ Dnsmasq-discuss mailing list [email protected] http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
