Feature request

[Joe Abley]

Hi Yuri,

On 7 Mar 2019, at 11:19, Yuri via Unbound-users <unbound-users at nlnetlabs.nl> wrote:

>> 2. explain why you need it in Unbound.
> 
> WCCP supports not only 80 port, but also 53 (and any arbitrary port) ans
> very useful for transparent interception any traffic and locally cache
> it on separate server.
> 
> Thus, technology can drastically reduce outboud internet traffic and/or
> increases LAN security.

I was an early beta-tester of cisco's original cache engine back in the 90s, back when I think the programme was being run by Barry Greene out of Singapore. Transparent caching of web objects made a lot of sense for us since we were severely bandwidth-constrained in New Zealand in advance of southern cross being lit. There were all kinds of bandwidth-conserving shenanigans going on at the time.

However, I don't know that the same advantages would have existed (or do exist, today) for the DNS.

DNS is not generally a significant contributor to traffic volume so long as the DDoS klaxons are not sounding, so the "reduce outbound internet traffic" argument is not especially compelling (nor inbound; I'm not sure why you call out outbound). Increasing LAN security is even more dubious, I think.

In general, DNS involves a number of subtly different protocols, all co-specified but not the same. Transparently proxying a query intended for an authoritative server to a resolver can cause problems (e.g. with RD and AA signalling). Delivering a DNS UPDATE message to the wrong server is going to break the intended behaviour. The only really safe way to avoid these kinds of pitfalls is to not do transparent proxying at all.

If the goal was to use WCCP as a clustering technique without transparent proxying, hashing the (QNAME, QCLASS, QTYPE) tuple across a set of origin servers in order to minimise cache misses, that might be interesting, but it's not clear to me that WCCP is the right way to do that (but perhaps I'm not thinking hard enough about it).


Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190307/31ea660a/attachment.bin>