From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2921 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Jonathan de Boyne Pollard Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: keeping sites off Date: Mon, 30 Mar 2020 09:38:36 +0100 Message-ID: <16c20411-063a-9f7f-4203-f04221fe49a9@NTLWorld.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="116797"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 To: supervision Original-X-From: supervision-return-2510-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Mon Mar 30 10:38:42 2020 Return-path: Envelope-to: gcsg-supervision@m.gmane-mx.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by ciao.gmane.io with smtp (Exim 4.92) (envelope-from ) id 1jIpwP-000UFw-My for gcsg-supervision@m.gmane-mx.org; Mon, 30 Mar 2020 10:38:41 +0200 Original-Received: (qmail 25316 invoked by uid 89); 30 Mar 2020 08:39:05 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 25309 invoked from network); 30 Mar 2020 08:39:04 -0000 X-Originating-IP: [86.10.101.211] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.3 cv=Is0wjo3g c=1 sm=1 tr=0 a=FQ5CjUvp3JFI4KFGyeqcZw==:117 a=FQ5CjUvp3JFI4KFGyeqcZw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=3j4BkbkPAAAA:8 a=rg2V61WcAAAA:8 a=wO_lhhLXZvu7QFFlzl4A:9 a=TId0DXQnkn8Dzssv:21 a=YBFmgVy6C16TLdL_:21 a=QEXdDO2ut3YA:10 a=QXbpJV3-wYUA:10 a=h2Zpg1Gm_F5nnxfnuFwt:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1585557516; bh=CfxQ925Nul2oFAuWhqtkpupTpDGxJiJ+T6A+qrgGiRU=; h=Subject:To:References:From:Date:In-Reply-To; b=Y5m0ZS0ORp/6DaxN7wsRnDw/52KKKJSmRi+hhapKU7+1dEfQ7A2IVUpe9t0Q+pWBR 1p9oozART/CLnapsyEv/8nLXsPP1EgY+fuf1PW+R/EuvYKwRzFv4MDY+yRnDY2aFhb Xp1gUePBbzqgIuYX54fYGehFz6frRaD88jy5u7Mk7wqOwp3TRFNHdcJDgtj46HcT5/ 96NJbsHV7ev3A8uQh/7S4TS0C+VSRXP4wx4yvqlWDLQG2PVa8V8I0dTDsQLdz3LuDp 0VnzP7LkZ+G9PnSMguG0iw/hnBG1pbmW3AkFzPZtGwZ9ZNB34E/I6SO9jr+bJsgnyV yR3xTxbW538gA== In-Reply-To: X-CMAE-Envelope: MS4wfNTBfJ9lkF/Pj5F6iUjgNK0wuD+dtASdOeXjsGqtEEku3izRJNzwUQq8EfUDTfAEO7zIVpBw20VSwoX0XvfI4V89+uNNeCUo1Y0WQKLQFlNEInprUIw5 ItFgFxojXf6WcO3NSLaIPEKfZMJnHN1MMdCgBM/aia34s30cjyQE9SjDVzsqMMFWYvQqEGlXmYDWkc5+q9vi3Yc2PrU3uLh0fMcqVKSUjvMc6NyaCLJA+eZ0 Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2921 Archived-At: 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.