Hi,
I would like to see WCCPv2 support in Unbound.
Is it possible? Or still not?
WBR, Yuri
Hi Yuri,
Your question would be better if you:
1. describe what WCCPv2 is; and
2. explain why you need it in Unbound.
Not everyone knows what WCCPv2 is, and why would might want it.
Regards,
Anand
07.03.2019 22:14, Anand Buddhdev пишет:
Hi Yuri,
Your question would be better if you:
1. describe what WCCPv2 is; and
http://cauew.blogspot.com/2008/08/wccp-web-cache-communication-protocol.html
https://en.wikipedia.org/wiki/Web_Cache_Communication_Protocol
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.
Not everyone knows what WCCPv2 is, and why would might want it.
No one can Google? Seriously? 
You jokinly me!
Um, sure I can, but it doesn't explain why you want this in Unbound, and
how you think it might work.
I've told the Unbound developers many times that Unbound has become
quite "fat", and I am not in favour of adding even more stuff to it just
because it's possible. You need to make a strong case for adding such a
feature to Unbound, and explain why the existing tools and technologies
we have don't work for this case.
Regards,
Anand
I can explain a bit more.
For DNS interception (to Unbound, of course) I’m using PBR:
ip access-list extended intercept-ports
permit udp any any eq domain
permit tcp any any eq domain
deny ip any any
!
!
route-map redirect_dns permit 30
match ip address intercept-ports
set ip next-hop 192.168.200.3
!
which processes on router CPU and sometimes overload them.
WCCP, instead, processes on control plane, and not touch CPU to process.
Also, WCCP is fully transparent.
Why Unbound? This is simple. Because of we’re use it as best caching DNS server in our production infrastructure.
Well, if Unbound becomes fat - why not makes WCCP as configurable non-default module, which will build on-demand, for such idiots like me?
Anyway. WCCP is caching related. Unbound is caching related. Why not works together?
That would be logical, wouldn’t it?
Hi Yuri,
08.03.2019 00:18, Joe Abley пишет:
Hi Yuri,
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.
That sounds to me like something that should be solvable with a
configuration fix. Maybe this?
https://community.cisco.com/t5/switching/high-cpu-usage-after-configured-pbr/td-p/2325961
Tony.
11.03.2019 19:08, Tony Finch пишет:
For DNS interception (to Unbound, of course) I'm using PBR:
ip access-list extended intercept-ports
permit udp any any eq domain
permit tcp any any eq domain
deny ip any any
!
!
route-map redirect_dns permit 30
match ip address intercept-ports
set ip next-hop 192.168.200.3
!which processes on router CPU and sometimes overload them.
That sounds to me like something that should be solvable with a
configuration fix. Maybe this?
https://community.cisco.com/t5/switching/high-cpu-usage-after-configured-pbr/td-p/2325961
Nop. This is specifix Catalyst 4500 switch solution.
But I'm talking about routers. At least, ISRG2 family.