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-12-17 Wed wk51 07:33] – [bind9 config files] baumkpdocker_notes:docker-dns [2026-02-15 Sun wk07 08:37] (current) – [Testing DNS] baumkp
Line 62: Line 62:
  
 ====bind9 config files==== ====bind9 config files====
-I breakdown the named.conf into 3 separate sub configuration 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| ++++/etc/bind/name.conf|
 <code>// Default contents of /etc/bind/named.conf <code>// Default contents of /etc/bind/named.conf
Line 219: Line 222:
 ++++ ++++
  
-++++/etc/bind/name.conf.recursive|+++++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 <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 // recursive DNS resolver. If you want to run an authoritative nameserver
Line 422: 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 445: 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