Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
docker_notes:docker-dns [2025-11-02 Sun wk44 08:59] – [DDNS] baumkpdocker_notes:docker-dns [2026-02-15 Sun wk07 08:37] (current) – [Testing DNS] baumkp
Line 40: Line 40:
  
 =====Bind9 Controls===== =====Bind9 Controls=====
-  *''/usr/sbin/named -f -4'' to start the isc-bind9 application called named, +  *''/usr/sbin/named -f'' to start the isc-bind9 application called named, 
     *''-f'' to run in foreground (needed for running with s6)     *''-f'' to run in foreground (needed for running with s6)
-    *''-4'' to run ipv4 only+    *''-4'' to run ipv4 only, I am using dual stack now, so this option is not required
   *''rndc stop'' to stop named  <fc #ff0000>- need to implement this in S6</fc>   *''rndc stop'' to stop named  <fc #ff0000>- need to implement this in S6</fc>
   *''rndc reload'' to reload the named configuration files   *''rndc reload'' to reload the named configuration files
Line 60: Line 60:
  
 =====bind9 Docker setup===== =====bind9 Docker setup=====
 +
 +====bind9 config files====
 +I am basically running a caching and forwarding local DNS. The caching and forwarding should allow improved overall DNS performance.  The local DNS also provides local LAN DNS services.  The DNS service is only accessible on the LAN.  The main router fire wall excludes unsolicited external WAN DNS queries to the LAN.
 +
 +I breakdown the ''/etc/bind/named.conf'' configuration file such that it points to 3 separate sub configuration files.  As I am not running a recursive DNS the recursive configuration file is not referenced.
 +
 +++++/etc/bind/name.conf|
 +<code>// Default contents of /etc/bind/named.conf
 +// This is the primary configuration file for the BIND DNS server named.
 +//
 +// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
 +// structure of BIND configuration files in Debian, *BEFORE* you customize
 +// this configuration file.
 +//
 +// If you are just adding zones, please do that in /etc/bind/named.conf.local
 +
 +include "/etc/bind/named.conf.options";
 +include "/etc/bind/named.conf.local";
 +include "/etc/bind/named.conf.default-zones";</code>
 +++++
 +
 +++++/etc/bind/name.conf.options|
 +<code> acl "trusted" {
 +  192.168.1/24;
 +  127.0.0.1;
 +  localhost;
 +  localnets;
 +  ::1;
 +  fe80::/64;
 +  2404:e80:943d:178::/64;
 +  };
 +
 +tls quad9-tls { remote-hostname "dns.quad9.net"; };
 +tls cloudflare-tls { remote-hostname "one.one.one.one"; };
 +tls google-tls { remote-hostname "dns.google"; };
 +
 +options {
 +
 +  directory "/var/bind";
 +
 +  auth-nxdomain no; # conform to RFC1035
 +
 +  // dnssec-validation auto; //set to auto by default
 +  //bind now uses dnssec by default
 +
 +  recursion yes;
 +  allow-recursion {
 +    trusted;
 +    };
 +    
 +    /*  forwarders {
 +    //quad9 with basic malware blocking, no ECS
 +    9.9.9.9;
 +    149.112.112.112;
 +    2620:fe::fe;
 +    2620:fe::9;
 +    //Cloudflare basic
 +    //1.1.1.1;
 +    //1.0.0.1;
 +    //Cloudflare with basic malware blocking
 +    1.1.1.2;
 +    1.0.0.2;
 +    2620:4700:4700::1111;
 +    2620:4700:4700::1001;
 +    //Opendns basic
 +    208.67.222.222;
 +    208.67.220.220;
 +    2620:0:ccc::2;
 +    2620:0:ccd::2;
 +    }; */
 +
 +forwarders port 853 {
 +    9.9.9.9 tls quad9-tls;
 +    149.112.112.112 tls quad9-tls;
 +    2620:fe::fe tls quad9-tls;
 +    2620:fe::9 tls quad9-tls;
 +
 +    1.1.1.1 tls cloudflare-tls;
 +    1.0.0.1 tls cloudflare-tls;
 +    2606:4700:4700::1111 tls cloudflare-tls;
 +    2606:4700:4700::1001 tls cloudflare-tls;
 +
 +    8.8.8.8 tls google-tls;
 +    8.8.4.4 tls google-tls;
 +    2001:4860:4860::8844 tls google-tls;
 +    2001:4860:4860::8888 tls google-tls;
 +  };
 +
 +  allow-query { 
 +    trusted;
 +    };
 +
 +  allow-transfer {
 +    trusted;
 +    };
 +        
 +  //listen-on { any; };
 +  //listen-on-v6 { none; };
 +
 +};
 +
 +logging {
 +    channel bind.log {
 +        file "/var/log/named/bind.log" versions 10 size 20m;
 +        severity notice;
 +        print-category yes;
 +        print-severity yes;
 +        print-time yes;
 +    };
 +  
 +        category queries { bind.log; };
 +        category default { bind.log; };
 +        category config { bind.log; };
 +};
 +</code>
 +++++
 +
 +++++/etc/bind/name.conf.local|
 +<code>// key "rndc-key" {
 +//   algorithm hmac-md5;
 +//   secret "LBLC2Dg8v6hYNE/ecnd6Ag==";
 +// };
 +
 +zone "kptree.net" {
 +  type master;
 +  file "/etc/bind/db.kptree.net";
 +  allow-transfer { trusted; };
 +  also-notify { 192.168.1.2; };
 +//  allow-update { key rndc-key; };
 +};
 +
 +zone "1.168.192.in-addr.arpa" {
 +  type master;
 +  file "/etc/bind/db.1.168.192";
 +  allow-transfer { trusted; };
 +  also-notify { 192.168.1.2; };
 +//  allow-update { key rndc-key; };
 +};
 + </code>
 +++++
 +
 +++++/etc/bind/name.conf.default-zones|
 +<code>zone "." IN {
 +        type hint;
 +        file "named.ca";
 +};
 +
 +zone "localhost" IN {
 +        type master;
 +        file "pri/localhost.zone";
 +        allow-update { none; };
 +        notify no;
 +};
 +
 +zone "127.in-addr.arpa" IN {
 +        type master;
 +        file "pri/127.zone";
 +        allow-update { none; };
 +        notify no;
 +}; </code>
 +++++
 +
 +++++NOT USED, as not running a recursive DNS: /etc/bind/name.conf.recursive|
 +<code>// Copy this file to /etc/bind/named.conf if you want to run bind as a
 +// recursive DNS resolver. If you want to run an authoritative nameserver
 +// instead, see /etc/bind/named.conf.authoritative.
 +//
 +// BIND supports using the same daemon as both authoritative nameserver and
 +// recursive resolver; it supports this because it is the oldest and original
 +// nameserver and so was designed before it was realized that combining these
 +// functions is inadvisable.
 +//
 +// In actual fact, combining these functions is a very bad idea. It is thus
 +// recommended that you run a given instance of BIND as either an authoritative
 +// nameserver or recursive resolver, not both. The example configuration herein
 +// provides a starting point for running a recursive resolver.
 +//
 +//
 +// *** IMPORTANT ***
 +// You should note that running an open DNS resolver (that is, a resolver which
 +// answers queries from any globally routable IP) makes the resolver vulnerable
 +// to abuse in the form of reflected DDoS attacks.
 +//
 +// These attacks are now widely prevalent on the open internet. Even if
 +// unadvertised, attackers can and will find your resolver by portscanning the
 +// global IPv4 address space.
 +//
 +// In one case the traffic generated using such an attack reached 300 Gb/s (!).
 +//
 +// It is therefore imperative that you take care to configure the resolver to
 +// only answer queries from IP address space you trust or control. See the
 +// "allow-recursion" directive below.
 +//
 +// Bear in mind that with these attacks, the "source" of a query will actually
 +// be the intended target of a DDoS attack, so this only protects other networks
 +// from attack, not your own; ideally therefore you should firewall DNS traffic
 +// at the borders of your network to eliminate spoofed traffic.
 +//
 +// This is a complex issue and some level of understanding of these attacks is
 +// advisable before you attempt to configure a resolver.
 +
 +options {
 +        directory "/var/bind";
 +
 +        // Specify a list of CIDR masks which should be allowed to issue recursive
 +        // queries to the DNS server. Do NOT specify 0.0.0.0/0 here; see above.
 +        allow-recursion {
 +                127.0.0.1/32;
 +        };
 +
 +        // If you want this resolver to itself resolve via means of another recursive
 +        // resolver, uncomment this block and specify the IP addresses of the desired
 +        // upstream resolvers.
 +        //forwarders {
 +        //      123.123.123.123;
 +        //      123.123.123.123;
 +        //};
 +
 +        // By default the resolver will attempt to perform recursive resolution itself
 +        // if the forwarders are unavailable. If you want this resolver to fail outright
 +        // if the upstream resolvers are unavailable, uncomment this directive.
 +        //forward only;
 +        
 +        // Configure the IPs to listen on here.
 +        listen-on { 127.0.0.1; };
 +        listen-on-v6 { none; };
 +
 +        // If you have problems and are behind a firewall:
 +        //query-source address * port 53;
 +
 +        pid-file "/var/run/named/named.pid";
 +
 +        // Removing this block will cause BIND to revert to its default behaviour
 +        // of allowing zone transfers to any host (!). There is no need to allow zone
 +        // transfers when operating as a recursive resolver.
 +        allow-transfer { none; };
 +};
 +
 +// Briefly, a zone which has been declared delegation-only will be effectively
 +// limited to containing NS RRs for subdomains, but no actual data beyond its
 +// own apex (for example, its SOA RR and apex NS RRset). This can be used to
 +// filter out "wildcard" or "synthesized" data from NAT boxes or from
 +// authoritative name servers whose undelegated (in-zone) data is of no
 +// interest.
 +// See http://www.isc.org/products/BIND/delegation-only.html for more info
 +
 +//zone "COM" { type delegation-only; };
 +//zone "NET" { type delegation-only; };
 +
 +zone "." IN {
 +        type hint;
 +        file "named.ca";
 +};
 +
 +zone "localhost" IN {
 +        type master;
 +        file "pri/localhost.zone";
 +        allow-update { none; };
 +        notify no;
 +};
 +
 +zone "127.in-addr.arpa" IN {
 +        type master;
 +        file "pri/127.zone";
 +        allow-update { none; };
 +        notify no;
 +};
 + </code>
 +++++
 ====bind9 docker image==== ====bind9 docker image====
 I use the [[https://wiki.kptree.net/doku.php?id=docker_notes:init#s6_supervision_rc_system| s6 rc system]].   I use the [[https://wiki.kptree.net/doku.php?id=docker_notes:init#s6_supervision_rc_system| s6 rc system]].  
Line 156: Line 425:
 DNS over TLS encrypts the DNS data so others can not see the specific DNS query and response.  DNSSEC does not prevent viewing of the DNS data, but rather ensure prevent man in the middle attacks. DNS over TLS encrypts the DNS data so others can not see the specific DNS query and response.  DNSSEC does not prevent viewing of the DNS data, but rather ensure prevent man in the middle attacks.
  
-It looks like Bind9 is still working on support for DNS over TLS (DoT) for forwarders. It may work on the current developer release 9.19. +Bind9 circa version 9.20 allows used of TLS forwarders, e.g. 
 +++++/etc/named.conf| 
 +<code>tls cloudflare-tls { remote-hostname "one.one.one.one"; }; 
 +tls quad9-tls { remote-hostname "dns.quad9.net"; }; 
 +tls google-tls { remote-hostname "dns.google"; }; 
 +options { 
 +    ... 
 +    forwarders port 853 { 
 +        1.1.1.1 tls cloudflare-tls; 
 +        1.0.0.1 tls cloudflare-tls; 
 +        2606:4700:4700::1111 tls cloudflare-tls; 
 +        2606:4700:4700::1001 tls cloudflare-tls;
  
-  *quad9 TLS config data: +        9.9.9.9 tls quad9-tls; 
-    *''9.9.9.9'' ip address +        149.112.112.112 tls quad9-tls; 
-    *''dns.quad9.net'' dns name +        2620:fe::fe tls quad9-tls; 
-    *''sha256''  +        2620:fe::9 tls quad9-tls;
-    *''%%echo | openssl s_client -connect '9.9.9.9:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64%%'' to get the SPKI key for quad9+
  
 +        8.8.8.8 tls google-tls;
 +        8.8.4.4 tls google-tls;
 +        2001:4860:4860::8844 tls google-tls;
 +        2001:4860:4860::8888 tls google-tls;
 +    };
 +};</code>
 +++++
  
  
Line 179: Line 465:
   *[[https://dnsprivacy.org/dns_privacy_clients/|DNS Privacy Project - DNS Privacy Clients]]   *[[https://dnsprivacy.org/dns_privacy_clients/|DNS Privacy Project - DNS Privacy Clients]]
   *[[https://www.internetsociety.org/blog/2018/12/dns-privacy-in-linux-systemd/|DNS-over-TLS in Linux (systemd)]]   *[[https://www.internetsociety.org/blog/2018/12/dns-privacy-in-linux-systemd/|DNS-over-TLS in Linux (systemd)]]
-  *+  *[[https://www.mytinydc.com/en/dns-provisioning/|Datacenter provisioning - Installing DNS Bind9 - [Raspberry PI/Rock64]]] 
 +  *[[https://crc.id.au/2024/10/06/secure-dns-with-bind-and-dot/|Secure DNS with bind and DoT]] 
 +  *DNS Web Check Sites 
 +    *[[https://on.quad9.net/|quad9]] 
 +    *[[https://one.one.one.one/help/|1.1.1.1(Cloudflare)]]
 =====Testing DNS===== =====Testing DNS=====
 My local recursive servers are ''ns1.local.kptree.net'' and ''ns2.local.kptree.net'', which are on separate serves on the local network.  These DNS servers are for local LAN use only and cannot and should not be accessible from outside the LAN. My local recursive servers are ''ns1.local.kptree.net'' and ''ns2.local.kptree.net'', which are on separate serves on the local network.  These DNS servers are for local LAN use only and cannot and should not be accessible from outside the LAN.
   *Using ''host'' command:   *Using ''host'' command:
-    *''host -t A ns1.local.kptree.net ns2.local.kptree.net'' - if both local name servers are running to cross check +    *''host ns1.local.kptree.net ns2.local.kptree.net'' - if both local name servers are running to cross check 
-    *''host -t A ns2.local.kptree.net ns1.local.kptree.net'' - if both local name servers are running to cross check +    *''host ns2.local.kptree.net ns1.local.kptree.net'' - if both local name servers are running to cross check 
-    *''host -t A google.com ns1.local.kptree.net'' - an external services via local name server+    *''host google.com ns1.local.kptree.net'' - an external services via local name server
     *''host -t A mail.kptree.net 9.9.9.9'' - remote address to local hosted external services via an external name server     *''host -t A mail.kptree.net 9.9.9.9'' - remote address to local hosted external services via an external name server
 +    *use flag ''-t A'' or ''-t AAAA'' to only return IP4 or IP6 results only respectively.  Otherwise both are returned.
   *Using ''delv'':   *Using ''delv'':
     *''delv @ns2.local.kptree.net ns1.local.kptree.net'' - if both local name servers are running to cross check     *''delv @ns2.local.kptree.net ns1.local.kptree.net'' - if both local name servers are running to cross check
Line 215: Line 506:
   *[[https://www.techtutorials.tv/sections/linux/how-to-setup-ddns-using-kea-and-bind/|How to Setup Dynamic DNS (DDNS) using Kea and Bind on Debian or Ubuntu]]   *[[https://www.techtutorials.tv/sections/linux/how-to-setup-ddns-using-kea-and-bind/|How to Setup Dynamic DNS (DDNS) using Kea and Bind on Debian or Ubuntu]]
   *[[https://unix.stackexchange.com/questions/777184/bind-kea-and-dynamic-dns|BIND, Kea and Dynamic DNS]]   *[[https://unix.stackexchange.com/questions/777184/bind-kea-and-dynamic-dns|BIND, Kea and Dynamic DNS]]
-  *[[https://arstechnica.com/information-technology/2024/02/doing-dns-and-dhcp-for-your-lan-the-old-way-the-way-that-works/|Doing DNS and DHCP for your LAN the old way—the way that works]]+  *Pre Kea - Using ISC DHCP Server 
 +    *[[https://arstechnica.com/information-technology/2024/02/doing-dns-and-dhcp-for-your-lan-the-old-way-the-way-that-works/|Doing DNS and DHCP for your LAN the old way—the way that works]] 
 +    *[[https://blog.bigdinosaur.org/running-bind9-and-isc-dhcp/|Running BIND9 and ISC-DHCP]]
 =====References===== =====References=====
    *KPTree.net's bare metal implementation of [[linux_router:dns_dhcp|dns - dhcp]], based upon ISC Bind9 and DHCP on Debian 10 <fs xx-small>(was originally Ubuntu)</fs>.    *KPTree.net's bare metal implementation of [[linux_router:dns_dhcp|dns - dhcp]], based upon ISC Bind9 and DHCP on Debian 10 <fs xx-small>(was originally Ubuntu)</fs>.