Re: Using bind for a local caching name server, is this configuration correct?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2019-07-01 at 10:44 -0700, stan via users wrote:
> I switched DNS from my ISP to free dns services on the web to avoid
> tracking and data being sold. I started seeing a lot of "looking up
> xyz.com" in the browser, so I decided to set up bind as a locally
> caching name server.  However, even though it seems to be configured
> the way it is supposed to be, I am still seeing those messages, even
> when I hit back in the browser, so for pages I just visited that I
> think should be cached.

I've been using (an old version of) BIND for years, because my ISP's
have had slow, failing, and censoring DNS servers.

Once you're able to log lookups, you're going to see lots of such
things.  These days, web-pages rarely are composed of data all from one
service, they tend to incorporate content from many places.  You have
the text that you're reading, graphics on the page, adverts, tracking
images, cookies, scripts, all of which can come from a different
source, and pull in more stuff from yet different sources.

DNS queries are supposed to be cached for a while.  The DNS record has
those time periods set in its data, the DNS server can cache things for
longer (past the record date, past the time it read the record, past
the time some other DNS server sent it the data).  Your browser (and
other software) can also cache the data, internally, for who knows what
time period.

A domain name owner may set their time period long for stability, or
may set it super short so they can change things quickly, or in the
vain attempt at databasing the use of their domain name.

An advertiser providing a script to a webhost may use scripting that
always checks a domain name every time it runs, ignoring any attempts
at caching.

You could have a device on your network which is hard coded to always
check something at a particular domain, but since they designed the
thing, the domain has gone away, but their device keeps plugging away
at trying to contact it.

Using a caching proxy may only help if things are already swung in your
favour (the services are not anti-caching, you keep looking at cachable
content on your system).  Squid has limited HTTPS capabilities, if it
had more it'd be a serious security problem (for HTTPS, itself).

You can use plugins in your browser to try and stop your browser doing
things you want (privoxy, no-script, etc), but that can also seriously
break websites at the same time.  Though you can try just blocking
particular things.

But that won't help you if it isn't your browser doing the annoying
lookups.  e.g. There your mail program, messaging software, any
software on your computer that checks in with mummy to look for updates
or snoop on you.

Now that you run your own DNS server, you can kill of certain things
there.  Few software resolves domain names without the aid of your DNS
server, though there are some, and it's said that Google web browsers
may do that.  I kill of several annoyances with mine, I do it like
this:

In the /etc/named.conf, add some entries for domain names that you'd
like to kill, like this (just bung them down the end of the config
file):


zone "advertising.com"          { type master; file  "dead.zone"; };
zone "doubleclick.net"          { type master; file  "dead.zone"; };
zone "doubleclick.com"          { type master; file  "dead.zone"; };
zone "googleadservices.com"     { type master; file  "dead.zone"; };


They'll refer all queries about those domains, and sub-domains (so 
www.advertising.com, www1.advertising.com, etc), to something that
provides an instant "no answer" response.  Connections are never made,
and attempts are immediately aborted.

Then, in your /var/named/ director, or /var/named/chroot/var/named
directory (if you're chrooting BIND), or wherever you have set the
"directory" in your /etc/named.conf file), create a dead.zone file with
the following contents:


$TTL 10
@       IN      SOA     ns.localdomain.  hostmaster.mail.localdomain. (
                        202 ; serial
                        20 ; refresh
                        20 ; retry
                        20 ; expire     
                        20 ; ttl
                        )


        IN      NS      ns.localdomain.


It has the basic data to fulfil a DNS record, and respond to all
queries to that domain, but provide no actual answers.  It's a very
effective stop to a lot of annoyances.

While other people have traditionally made /etc/hosts entries for
annoying domains (see below), and perhaps aimed the problems at an IP
that has firewall rules of instant death, the problem with that
approach is that it answers queries and directs the connection attempt
somewhere, and the nuisance keeps on doing something.  My DNS deadzone
approach throws a spanner in its works, and completely stops it, and
protects anything on your LAN using that DNS server.

/etc/hosts
127.0.0.1  localhost.localdomain   localhost
127.0.0.1  annoying-domain.com
192.168.1.20 another-annoying.domain.com

Create the dead.zone file.
Stop the DNS server.
Change the config file
Restart the DNS server.

If you really need to minimise the DNS server downtime, it may be
possible to modify the config file while it's running, then reload or
restart the DNS server, but I haven't tried that.

_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux