On 2019-12-17 13:24, jin&hitman&Barracuda wrote:
Sorry for top posting.
Looks like you need an ip address lists which is updated dynamically. But
this method is not like what you described here. It doesn't response back
an IP address but it does block requests which is trying to get those
ad.servers. if you wish you can choose action to "reject" instead of
"drop". I choose to reject requests because of we just have two devices at
home network.
There are couple of sites which shares ad server names and ip addresses as
a list and they update those lists. As described in below link, you can use
a script to stop traffic which you don't want to have. Basically the script
updates 'source of bad ad server list' periodically and feed your pf rules.
https://www.geoghegan.ca/pfbadhost.html
On Tue, Dec 17, 2019, 23:57 lu hu <luhu8...@mail.com> wrote:
Our little home network:
ISP -> ROUTER -> SWITCH -> WIFI APs -> CLIENTS
ROUTER: OpenBSD 6.5, giving DHCP+fwing internet to the WIFI APs. Based on
https://www.openbsd.org/faq/pf/example1.html#pf and
https://www.openbsd.org/faq/pf/example1.html#dhcp
CLIENTS: laptops, smartphones.
So everything is going through the ROUTER.
We can see a https://www.openbsd.org/faq/pf/example1.html#dns DOC for how
to setup a DNS server, ~ok.
AD filtering. We would like to have one, but not a fancy one, just a
working one.
Based on "bad hosts", ex.: if a client queries iamAD.foo, then answer it
back as 127.0.0.1, so the clients will try to connect to themselfes, which
will end up not showing the AD.
The big question: Is there any DOC for OpenBSD about this? What pf rules
needed to redirect any DNS server (ex.: 8.8.8.8 or 1.1.1.1) requests to the
DNS server running on the ROUTER, coming from the CLIENTS?
So ex.: if a smartphone CLIENT wants to query iamAD.foo domain to get ADs,
it will only get back 127.0.0.1
Hey, I'm the author of that script. If you're looking to block ads via
DNS, geoghegan.ca/unbound-adblock.html may be what you're looking for.
It pulls a popular ad server blocklist and makes unbound return NXDOMAIN
when a device tries to query a known ad server. Certain devices have
issues when redirecting their querys to 127.0.0.1 or 0.0.0.0, and some
devices may waste time retrying queries for a long period of time.
Setting static redirects to a particular address causes unbound to eat
up a ton of memory, wheras returning NXDomain uses almost no memory.
Cheers,
Jordan
