[Dnsmasq-discuss] forwarding signed requests
simon at thekelleys.org.uk
Thu Mar 19 09:52:46 GMT 2009
Philip Craig wrote:
> Simon Kelley wrote:
>> The intention of the code is to avoid invalidating the signature of
>> signed packets by forwarding queries and returning replies bit-perfect
>> unaltered. The motivation for doing this is to allow DNSSEC to function,
>> not for dynamic dns updates.
> The changelog for 2.36 does specifically mention DDNS updates and
> bit-perfect signed packets. I can see that we might need to do this for
> DNSSEC too, but is that because dnsmasq doesn't have the support to sign
> and verify signatures itself, or would it be needed anyway?
Hmm, I trawled my memory and email archives: that code, and the
changelog entry, where generated in response to this thread.
Which ends rather inconclusively, so it's quite possible that it didn't
ever solve the original problem, for exactly the reason you mention.
>> You should be aware that I'm very unlikely to accept such code into the
>> dnsmasq mainline.
> Understandable, the NXDOMAIN changes are dodgy. I'm trying to solve the
> problem of resolving internal domains across VPNs automatically without
> requiring user configuration. The idea is to query all the VPN servers,
> and take the first response that is not NXDOMAIN. This means things work
> by default, while still allowing user configuration to optimise things
> to avoid unnecessary queries.
> The timeout support is required as part of the above, but I think it
> does give some improvement for the general case too: dnsmasq should be
> smart enough to try another server if the first one is down, without
> requiring a potentially long timeout on the client.
Agreed that timeout support would be nice to have, but the cost is
potentially high. As you've already deduced, to re-try a query before
the original client does, dnsmasq has to keep a copy of each "in flight"
query. The code as it stands can sit there all day forwarding DNS
requests and relaying the answers back, and never allocate any memory at
all. Consequently it scales to very large loads even on very small
hardware (routers and the like). Once it keeps copies of queries, the
memory usage will rise as the load does.
This problem is made worse by the garbage-collection properties of DNS
queries: if you need timeouts, that implies that queries are going to
hanging round unanswered and unanswered queries hang around for a long
time consuming resources. For most of dnsmasq history, the only
resources used were a forwarding-table entry, and that could just stay
until re-used on a LRU basis. With the introduction of random source
ports there's a socket associated with each query so I had to add some
code to time-out abandoned queries and close the sockets. In some ways
the socket per-query code shows the same resource problems that storing
queries would, but there's at least there's the get out that one can
limit the number of open sockets and re-use use them when under heavy load.
More information about the Dnsmasq-discuss