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

[stan via users <users@xxxxxxxxxxxxxxxxxxxxxxx>]

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.

Here is my /etc/named.conf.

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8)
DNS // server as a caching only nameserver (as a localhost DNS resolver
only). //
// See /usr/share/doc/bind*/sample/ for example named configuration
files. //

options {
        listen-on port 53 { 127.0.0.1; };
//      listen-on-v6 port 53 { ::1; };
  forwarders  { 1.1.1.1; 9.9.9.9; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        secroots-file   "/var/named/data/named.secroots";
        recursing-file  "/var/named/data/named.recursing";
        allow-query     { localhost; 192.168.0.0/24; };
        allow-query-cache     { localhost; 192.168.0.0/24; };

        /* 
         - If you are building an AUTHORITATIVE DNS server, do NOT
        enable recursion.
         - If you are building a RECURSIVE (caching) DNS server, you
        need to enable recursion. 
         - If your recursive DNS server has a public IP address, you
        MUST enable access control to limit queries to your legitimate
        users. Failing to do so will cause your server to become part
        of large scale DNS amplification attacks. Implementing BCP38
        within your network would greatly reduce such attack surface 
        */
        recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";

        /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
        include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";



Would I be better off using something like privoxy or squid?  I saw
something on the web about squid not working for https addresses, which
is problematic since the movement is to everything https.  Is this a
concern?
_______________________________________________
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