08.03.2019 00:18, Joe Abley пишет: > Hi Yuri, > > On 7 Mar 2019, at 11:19, Yuri via Unbound-users <[email protected]> > 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. Saving bandwidth makes sense in all cases when Internet traffic is sold in batches (in fact, truly unlimited traffic, if it exists, costs absolutely impossible money). > > 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 fact, I meant both types of traffic. Both incoming and outgoing. Imagine a business center (building), with two dozen companies (not users). At the moment we have one Internet channel 10 Mbit. To all consumers. By our CIsco statistics, we're have up to 10-20% DNS requests overall bandwith. So, you already see, yes? This is why we're uses only Unbound, this is why we're intercepting 53 port (whenever user devices settings). > > 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. Our solution (with PBR interception) works approx. from 2011 year. No issues you describing. Since the DNS traffic is taken from our cache with a pure content, we guarantee the absence of provider hijacking (which is always performed in our country). In addition, we completely control Internet traffic by blocking some of the advertising (and malware) in the local area of Unbound. For security this is directly related. This is an obvious application, on my opinion. > > 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). I have already described the goals above. DNS failover is completely enough for HA. But - I repeat - WCCP performs on control plane, instead PBR, which performs on CPU /and sometimes eats it up./ This is the reason why I would like to see support for this protocol. As far as I know, SQUID has support for both versions of this protocol for over 10 years (we are actively using it now). I see no reason why this support could not be realized in Unbound. Actually, I do not insist. I just asked a question. I was not going to give lectures or teach anyone at all. In principle, I do not care enough whether there will be support or not. I just think that "it would be nice to have" rather than "we will never do it, because personally we do not see *strong enough* reason for doing this." That’s all. Thank you. > > > Joe -- "C++ seems like a language suitable for firing other people's legs." ***************************** * C++20 : Bug to the future * *****************************
signature.asc
Description: OpenPGP digital signature
