supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / Atom feed
* keeping sites off
@ 2020-03-29 20:44 Jorge Almeida
  2020-03-29 21:10 ` eric vidal
  2020-03-30  0:18 ` Laurent Bercot
  0 siblings, 2 replies; 4+ messages in thread
From: Jorge Almeida @ 2020-03-29 20:44 UTC (permalink / raw)
  To: supervision

(This may be somewhat OT, so I apologize in advance)

I use dnscache, in home computers. I have
order hosts, bind
in /etc/host.conf
and in /etc/hosts I have stuff like

0.0.0.0         www.facebook.com

The problem is that /etc/hosts does not support wildcards, so
graph.facebook.com (for example) is not filtered. So, is there any
solution? Should I replace dnscache by something else? (something else
trustworthy and supervision-friendly) Any other setup compatible with
dnscache?
Any suggestion?
Thanks

Jorge Almeida


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: keeping sites off
  2020-03-29 20:44 keeping sites off Jorge Almeida
@ 2020-03-29 21:10 ` eric vidal
  2020-03-30  0:18 ` Laurent Bercot
  1 sibling, 0 replies; 4+ messages in thread
From: eric vidal @ 2020-03-29 21:10 UTC (permalink / raw)
  To: supervision

On Sun, 29 Mar 2020 21:44:18 +0100
Jorge Almeida <jjalmeida@gmail.com> wrote:

> (This may be somewhat OT, so I apologize in advance)
> 
> I use dnscache, in home computers. I have
> order hosts, bind
> in /etc/host.conf
> and in /etc/hosts I have stuff like
> 
> 0.0.0.0         www.facebook.com
> 
> The problem is that /etc/hosts does not support wildcards, so
> graph.facebook.com (for example) is not filtered. So, is there any
> solution? Should I replace dnscache by something else? (something else
> trustworthy and supervision-friendly) Any other setup compatible with
> dnscache?
> Any suggestion?
> Thanks
> 
> Jorge Almeida

hi there,

try to redirect to your local address in your /etc/hosts

127.0.0.1 www.facebook.com
127.0.0.1 *facebook.com
-- 
eric vidal <eric@obarun.org>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: keeping sites off
  2020-03-29 20:44 keeping sites off 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
  1 sibling, 1 reply; 4+ messages in thread
From: Laurent Bercot @ 2020-03-30  0:18 UTC (permalink / raw)
  To: supervision

>The problem is that /etc/hosts does not support wildcards, so
>graph.facebook.com (for example) is not filtered. So, is there any
>solution? Should I replace dnscache by something else? (something else
>trustworthy and supervision-friendly) Any other setup compatible with
>dnscache?

  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.

--
  Laurent



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: keeping sites off
  2020-03-30  0:18 ` Laurent Bercot
@ 2020-03-30  8:38   ` Jonathan de Boyne Pollard
  0 siblings, 0 replies; 4+ messages in thread
From: Jonathan de Boyne Pollard @ 2020-03-30  8:38 UTC (permalink / raw)
  To: supervision

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.



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-29 20:44 keeping sites off 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

supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit

Archives are clonable: git clone --mirror http://inbox.vuxu.org/supervision

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.supervision.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git