[Dnsmasq-discuss] why not cache data obtained via TCP?
albert.aribaud at free.fr
Fri Jul 29 13:21:38 BST 2016
Le Thu, 28 Jul 2016 21:53:41 +0100
Simon Kelley <simon at thekelleys.org.uk> a écrit:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> On 27/07/16 09:02, Albert ARIBAUD wrote:
> > Hi Ming,
> > Le Wed, 27 Jul 2016 10:06:47 +0800 XMing <mgabcde at gmail.com> a
> > écrit:
> >> is there any regulation or spec about that?
> > There is neither, and DNS records obtained through TCP /are/
> > cached.
> > Or, more to the point, answers are cached (or not, depending on
> > the cache-related settings in dnsmasq) regardless of whether they
> > were obtained through UDP or TCP.
> > What made you believe that answers obtained through TCP would not
> > be cached?
> > Amicalement,
> Actually, they're not cached.
My bad, then. I'd assumed -- yes, I know -- that there was no
> TCP connections are handled by forking a new process for each TCP
> connection. The records which arrive to that new process are not
> inserted into the cache (actually, they may be inserted into the cache
> of the child process, bu that's a copy which evaporates when the TCP
> connection dies, they don't make it to the real cache in the
> long-lived dnsmasq process.
> The reason for this is ease of implementation; it's the simplest and
> smallest way to handle TCP connections. It's not the most efficient,
> and it means that records which come via TCP are not cached. Since TCP
> connections are pretty rare, that's a trade-off worth making, I think.
> Tl;DR data obatined via TCP is not cached. There's no mandate to do
> that in the DNS spec, it just makes the implementation easy.
Got it. For TCP records to get cached, the child process would need an
easy way to pass it to its parent (or the main process would need an
easy way to handle the TCP connections itself).
Thanks for the explanation!
More information about the Dnsmasq-discuss