From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>
To: supervision <supervision@list.skarnet.org>
Subject: Re: keeping sites off
Date: Mon, 30 Mar 2020 09:38:36 +0100 [thread overview]
Message-ID: <16c20411-063a-9f7f-4203-f04221fe49a9@NTLWorld.COM> (raw)
In-Reply-To: <emd05879fb-3aac-45e4-ab13-6eeee9b3b633@elzian>
Laurent Bercot:
> What I do is:
>
> *
>
> run a tinydns on another IP address (if you only have 1 nic, you
> can still attribute several IPs to it)
>
> *
>
> fill that tinydns with sink data for the things I want to block
>
> *
>
> configure my dnscache to query my internal DNS server for the
> zones I want to block. In your case, if you tell your dnscache
> that your internal DNS server is authoritative for the
> facebook.com zone, any query for graph.facebook.com will go to
> your internal server.
>
> *
>
> no /etc/hosts manipulation needed.
>
This is the third-best way to achieve this. The second-best way is a
variant. In the third-best way there's still a lot of setup and
on-going maintenance involved in the servers/ directory of the dnscache
service, as one adds/removes domain names. In the second-best way,
tinydns also serves up the root of the DNS namespace, delegating to the
next level of servers in the same way that the public root content DNS
servers do, and dnscache is simply configured to start with that root
content server. There's no further on-going dnscache work in this
approach, just the maintenance of the entries in the tinydns database.
A side-benefit is that this also makes your traffic to the root content
DNS server entirely private and not susceptible to network outages.
Whilst it applies less to real existing domain names, this in particular
helps with some of the other stuff that tends to leak out in DNS lookups
(caused by a whole bunch of things from the DNS client library search
path, through non-existent top-level domains, to applications passing
human-form IP addresses to DNS lookup), which would otherwise end up as
negative responses from the public root content DNS servers. Moreover,
properly dnscache should always be providing split-horizon DNS service
for address-to-name lookups of all of your RFC 1918 IP addresses, and
name-to-address lookups of any internal subdomains for your LAN(s),
which are both more private stuff that the outside world should never
see. This also can achieve that, as a further side-benefit, simply with
further additions to the tinydns database, and without need to configure
split-horizon in dnscache.
In the service bundles that accompany the nosh toolset, I supply a
tinydns@127.53.0.1 service bundle that does all of these. Its Makefile
populates its database with RFC 1918 IP address stuff, the root data
pulled from ICANN, and administrator-controlled extra stuff (where the
re-pointed wildcard domain name data would go).
* http://jdebp.uk./Softwares/nosh/guide/services/djbdns.html
The best way, however, is to realize that using the DNS for this breaks
every non-HTTP(S) protocol, and do this for HTTP(S) only. I've myself
done this in two ways in the past: with a custom proxy.pac/wpad.dat file
that the WWW browsers load, redirecting all of the relevant domains in
ECMAScript in the WWW browser itself; and with a fully-fledged proxy
HTTP server that I wrote, that used a database of URL patterns (not just
domain names) and how they should be handled in HTTP, including (as one
of several possibilities) rewriting them into temporary redirects to a
small static content HTTP server that served up coloured rectangles as
placeholder images amongst other things. These are the basic approaches
of most non-toy WWW advert-blockers, you will find.
prev parent reply other threads:[~2020-03-30 8:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-29 20:44 Jorge Almeida
2020-03-29 21:10 ` eric vidal
2020-03-30 0:18 ` Laurent Bercot
2020-03-30 8:38 ` Jonathan de Boyne Pollard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16c20411-063a-9f7f-4203-f04221fe49a9@NTLWorld.COM \
--to=j.deboynepollard-newsgroups@ntlworld.com \
--cc=supervision@list.skarnet.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).