On 10/05/2011 08:06, Simon Kelley wrote: > Yes, I would consider such a feature request, and in principle, passing > information over from incoming DNS requests to outgoing DNS requests is > quite simple. The pointer to Squid is good, it gives API examples which > show that this is quite easy. HOWEVER, I think the showstopper is the > concept of a "connection". The vast majority of DNS traffic runs over > UDP, so there's no network-level connection to track. You could force > everything to TCP, but that would be slow, and use more of your > precious upsteam bandwidth than is strictly necessary. Have I got this > wrong somewhere?
Actually netfilter conntrack tries very hard to turn almost anything at all into a kind of "connection". It has a concept of "related" packets and so for example if you send a bunch of pings somewhere then those are seen both as a separate bunch of ICMP through iptables and optionally you can see them through conntrack as a single "connection" Really there is still a "connection" with UDP (or you wouldn't know what the answer to your request was). From dnsmasqs' point of view all that is needed is to ensure that a new socket is created for each request? The subtlety here is that usually you setup your iptables rules to take the packet mark (ie that dnsmasq sets), copy that to the "connection mark" (used by conntrack), then when the reply packet comes back, conntrack will match it for us and apply the same mark so that we will tag it as the same users traffic (whether UDP or TCP) So the main thing needed is to read incoming packet marks and apply them to the outgoing request. iptables/conntrack does everything else for us? Grateful for your thoughts on whether this could be implemented in dnsmasq? Thanks! Ed W
