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 [2024-07-21 Sun wk29 15:38] – [DNS over TLS (DoT)] baumkpdocker_notes:docker-dns [2025-12-17 Wed wk51 07:39] (current) – [bind9 config files] baumkp
Line 5: Line 5:
  
 =====Linux setup to forward packets===== =====Linux setup to forward packets=====
 +<color #ed1c24>[This probably needs to be moved and consolidated elsewhere and then highlevel only reference here]</color>
 +
 The main router must be set to forward packets! The main router must be set to forward packets!
-The ability to forward packets must be set / allowed, edit or add the following parameters in ''sudo vim /etc/sysctl.conf'': +It would seem that as of Debian 13 the ''/etc/sysctl.conf'' file is not longer used, and is deleted on upgrade, including any user changes.  Instead overrides must be copied into *.conf files in /etc/sysctl.d/. Normally user conf files in *.d directories are not affected by upgrades. 
-  *net.ipv4.ip_forward = 1 + 
-  *net.ipv4.conf.all.proxy_arp = 1 +The command ''sudo sysctl -a | less'' can be used to list all current kernel parameters and their current setting, or ''sudo sysctl net.ipv4.ip_forward'' to list a specific one. 
-  * ''sudo sysctl net.ipv6.conf.all.forwarding=1'' similar for ipv6  + 
-After applying these changes reboot or apply setting using ''sudo sysctl -p /etc/sysctl.conf''+++++sudo vim /etc/sysctl.d/ip_forward.conf| 
 +<code>net.ipv4.ip_forward = 1 
 +net.ipv4.conf.all.proxy_arp = 1 
 +net.ipv6.conf.all.forwarding=1</code> 
 +++++ 
 +After applying these changes reboot or apply setting using ''sudo sysctl -p /etc/sysctl.d/ip_forward.conf'' (Note that ''sudo sysctl -p'' defaults to using ''/etc/sysctl.conf'' and will error if this file is not available.) 
 +  * ''sudo sysctl -w net.ipv6.conf.all.forwarding=1'' will immediately set this parameter, but it will not be permanent and lost on reboot. 
 + 
 +The boot systemctl reads the following configuration files to adjust kernel parameters at boot: 
 +  */etc/sysctl.d/*.conf 
 +  */run/sysctl.d/*.conf 
 +  */usr/local/lib/sysctl.d/*.conf 
 +  */usr/lib/sysctl.d/*.conf 
 +  */lib/sysctl.d/*.conf 
 + 
  
 ====References==== ====References====
 +  *[[https://thequickadvisor.com/is-ip-forwarding-required-for-docker/|Is IP forwarding required for Docker?]] (It would seem yes.)
   *[[https://askubuntu.com/questions/311053/how-to-make-ip-forwarding-permanent|How to make IP forwarding permanent?]]   *[[https://askubuntu.com/questions/311053/how-to-make-ip-forwarding-permanent|How to make IP forwarding permanent?]]
 +  *[[http://linux-ip.net/html/index.html|Guide to IP Layer Network Administration with Linux]]
 +  *[[https://linuxize.com/post/sysctl-command-in-linux/|Sysctl Command in Linux]]
 +  *[[https://commandmasters.com/commands/sysctl-linux/|How to Use the Command 'sysctl' (with Examples)]]
 +  *[[https://load-balancer.inlab.net/knowledge-base/how-to-deal-with-arp-problems-on-linux/|How to deal with ARP-Problems on Linux]]
 +  *[[https://undercodetesting.com/understanding-arp-and-nat-core-networking-protocols-for-cybersecurity/|Understanding ARP and NAT: Core Networking Protocols for Cybersecurity]]
 +  *[[https://documentation.ubuntu.com/server/how-to/wireguard-vpn/on-an-internal-system/|WireGuard on an internal system (peer-to-site)]]
  
 =====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 36: 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 130: Line 423:
 ++++ ++++
 =====DNS over TLS (DoT)===== =====DNS over TLS (DoT)=====
 +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. 
 +
   *quad9 TLS config data:   *quad9 TLS config data:
     *''9.9.9.9'' ip address     *''9.9.9.9'' ip address
Line 135: Line 432:
     *''sha256''      *''sha256'' 
     *''%%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     *''%%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
 +
 +
  
 ====reference==== ====reference====
 +  *Bind9
     *[[https://bind9.readthedocs.io/en/latest/reference.html#tls-block-grammar|Bind TLS Block Grammar]]     *[[https://bind9.readthedocs.io/en/latest/reference.html#tls-block-grammar|Bind TLS Block Grammar]]
     *[[https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-forwarders|Bind Forwarders Grammar]]     *[[https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-forwarders|Bind Forwarders Grammar]]
-    *[[https://medium.com/nlnetlabs/privacy-using-dns-over-tls-with-the-new-quad9-dns-service-1ff2d2b687c5|Privacy: Using DNS-over-TLS with the Quad9 DNS Service]] +    *[[https://bind9.readthedocs.io/_/downloads/en/latest/pdf/|Bind 9 Administrator Reference Manual]] 
-    *[[https://unix.stackexchange.com/questions/735368/how-to-use-dns-over-tls-with-bind9-forwarders|How to use DNS-over-TLS with BIND9 forwarders]]+  *[[https://medium.com/nlnetlabs/privacy-using-dns-over-tls-with-the-new-quad9-dns-service-1ff2d2b687c5|Privacy: Using DNS-over-TLS with the Quad9 DNS Service]] 
 +  *[[https://unix.stackexchange.com/questions/735368/how-to-use-dns-over-tls-with-bind9-forwarders|How to use DNS-over-TLS with BIND9 forwarders]] 
 +  *[[https://unix.stackexchange.com/questions/756994/enable-tls-on-bind9|Enable TLS on BIND9]] 
 +  *QUAD9 
 +    *[[https://www.quad9.net/|quad9]] 
 +    *[[https://quad9.net/support/faq/|quad9 FAQ]] 
 +  *[[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)]] 
 +  * 
 +=====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. 
 +  *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 -t A 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 -t A mail.kptree.net 9.9.9.9'' - remote address to local hosted external services via an external name server 
 +  *Using ''delv'': 
 +    *''delv @ns2.local.kptree.net ns1.local.kptree.net'' - if both local name servers are running to cross check 
 +    *''delv @ns1.local.kptree.net ns2.local.kptree.net'' - if both local name servers are running to cross check 
 +    *''delv @ns2.local.kptree.net google.com''  - an external services via local name server 
 +    *''delv @1.1.1.1 mail.kptree.net'' - remote address to local hosted external services via an external name server 
 +  *Using ''dig'': 
 +    *''dig @ns2.local.kptree.net -p 53 ns1.local.kptree.net any'' 
 +    *''dig @ns2.local.kptree.net -p 53 kptree.net any'' 
 +    *''dig @ns2.local.kptree.net -tAXFR  kptree.net'' gave me the full name list from ns2.local.kptree.net 
 +    *''dig @ns1.local.kptree.net -tAXFR  kptree.net'' gave me the full name list from ns1.local.kptree.net  
 +      *Note that bind9 needs to be setup to allow-transfer from the requesting ip address, I include my LAN address range in the bind9 acl. 
 + 
 +\\ 
 +To find the version of bind9 used, anywhere from the LAN: 
 +  *''nslookup -q=txt -class=CHAOS version.bind ns1.local.kptree.net'' 
 +  *''dig -t txt -c chaos VERSION.BIND @ns1.local.kptree.net'' 
 +=====Public DNS Provideders===== 
 +See internal webpage [[https://wiki.kptree.net/doku.php?id=tech_notes:dns#public_dns_providers|Public DNS Providers]] for more details. 
 + 
 + 
 +=====DDNS===== 
 +DDNS (Dynamic DNS) is used to update the DNS server with the DHCP assignments.  I previously used this with ISC Bind9 and ISC DHCP server. I did not like how the updates changed my bind9 zone configuration file. Basically the dynamic entries would be added randomly throughout the zone file.  I would prefer if my static assignments were in a separate file to the dynamic ones, however I am not sure if this configuration is possible. 
 + 
 +To further complicate matters I have 2 Bind9 servers in a master-slave configuration across to separate computers on my LAN as well as 2 separate Kea DHCP servers in a primary-secondary back-up configuration also on 2 separate computers on my LAN. This has worked really well for me.  If one DNS or DHCP server are not functional my LAN operates well, previously without backup is the DNS or DHCP servers were not operational the LAN would loose functionality.  I would need DDNS to function correctly within my backup DNS and DHCP configurations. 
 + 
 +  *Kea read the Docs: [[https://kea.readthedocs.io/en/latest/arm/ddns.html|The DHCP-DDNS Server]] 
 +  *[[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]] 
 +  *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>.