Feature request

[Yuri]

08.03.2019 00:18, 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.
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 *
*****************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190308/90dc1846/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190308/90dc1846/attachment.bin>