KPTree Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{tag>linux docker DNS bind9}}
======Docker - DNS Server======
[[https://www.hostinger.com/tutorials/what-is-dns|What Is DNS and How Does It Work – A Comprehensive Guide]]\\
I have been using Bind9 as my home LAN DNS for the past few years. I originally operated it on bare metal on my home router computer.  In mid 2023 I successfully moved my Bind9 primary instance to my main home server in a container and created a slave instance in a container running on my home router computer.  I created a Docker Bind9 Image using base Docker Alpine Linux images, with S6 init system.  

=====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!
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.

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 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====
  *[[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?]]
  *[[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=====
  *''/usr/sbin/named -f'' to start the isc-bind9 application called named, 
    *''-f'' to run in foreground (needed for running with s6)
    *''-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 reload'' to reload the named configuration files
  *''named-checkconf /etc/bind/named.conf''
  *''named-checkzone kptree.net /etc/bind/db.kptree.net''
  *''named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.1.168.192''
  *''cat /log/named/bind.log'' to list bind log file
  *From [[https://serverfault.com/questions/401024/listing-all-zones-loaded-in-bind|Listing all zones loaded in BIND]]
    *''rndc dumpdb -zones''
    *''cat /var/bind/named_dump.db'' to see the database dump
    *''named-checkconf -l'' does this option still exist?
    *''named-checkconf -p'' for a flatened uncomment listing of the configuration files

I have setup a primary DNS server and secondary slave DNS server.  
  *The primary DNS server runs on my main home server, it is the master 
  *The secondary DNS server runs on my router, it is set up as a slave server from the primary server and reads the zone files from the master when available.

=====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====
I use the [[https://wiki.kptree.net/doku.php?id=docker_notes:init#s6_supervision_rc_system| s6 rc system]].  
Notes 
  -I never had much success with the S6_KEEP_ENV when I played around with this earlier.
  -Some of the packages are handy for debugging the container, but not required for normal package operation.  Hence these are commented out.

++++Dockerfile|
<code>FROM alpine:latest

ARG S6_OVERLAY_VERSION=3.1.6.2

ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-x86_64.tar.xz

#ENV S6_KEEP_ENV=1 
#this keeps the environment variables

ENTRYPOINT ["/init"]

#add UID & GID
RUN \
addgroup -g 99 named && \
adduser -G named -u 99  -G named -D -S -h /dev/null named

RUN apk update && \
apk --no-cache add \
bind \
bind-dnssec-tools \
&& \
apk upgrade
#util-linux \
#vim \
#less \

COPY user/* /etc/s6-overlay/s6-rc.d/user/contents.d/

COPY s6-rc.d /etc/s6-overlay/s6-rc.d/

EXPOSE 53/tcp
EXPOSE 53/udp
EXPOSE 953/tcp
</code>
++++
====docker compose====
A key point is the docker network is in host mode. (The ports are opened directly on the host and not routed from the docker internal network.)

++++docker-compose.yml|
<code yaml>---
services:
  bind:
    build: ./
    image: bind:latest
    tty: true
    stdin_open: true
    container_name: kptr-dns-1
    restart: 'always' # always | unless-stopped | no | on-failure [:max-retries]
    volumes:
      - '/mnt/docker_store/bind9/.config:/app/'
      - '/mnt/docker_store/bind9/.config/etc/bind:/etc/bind/'
      - '/mnt/docker_store/bind9/.config/var/bind:/var/bind/'
      - '/mnt/docker_store/bind9/.config/var/log:/var/log/'
    network_mode: host

    command: /bin/sh</code>
++++


=====DNSSEC=====
My local DNS server is a recursive caching type only.  It take local (LAN) DNS queries and answers directly for any LAN name resolution, checks the cache for any external name resolution and then if not found locally or in cache checks the specified external DNS servers to resolve names.  My DNS server is not setup as a public DNS server and is not publicly accessible. Hence DNSSEC is not relevant for this local DNS server query validation.  

For external name resolution Bind9 basically now defaults to automatic use of DNSSEC.  This can be validated with [[https://bind9.readthedocs.io/en/latest/dnssec-guide.html#how-to-test-recursive-server|(How To Test A Recursive Server)]] using:
    *''dig @192.168.1.14 ftp.isc.org. A +dnssec +multiline'', the query return flag ''ad'' indicates the DNS answer returned a validated answer.
    *''dig @192.168.1.2 ftp.isc.org. A +dnssec +multiline''

Equally important the following commands helps confirm that  invalid DNS queries have failed and do not rerun invalid IP address, which would be security risk.  If ''%%dig @192.168.1.14 www.dnssec-failed.org A%%'' receives ''status: SERVFAIL'' then ''%%dig @192.168.1.14 www.dnssec-failed.org A +cd%%'' will disable DNSSEC and return the IP address showing that the SERVFAIL occurred due to DNSSEC failure.

Basic Bind9 DNSSEC configuration options
  * The option (in ''/etc/bind/named.conf.options'') ''dnssec-enable yes;'' is no longer valid and use will cause configuration error.  <fc #ff0000>DO NOT USE!</fc>  DNSSEC is enabled by default.
  * The option ''dnssec-validation'' is set default to ''auto''.  The other setting options are ''yes'' and ''no''.  No action is required, if the option is not specified in the configuration file it is set to auto by default.  

<fc #ff0000>So I do not need to do any configuration for ''DNSSEC'' to function on external queries.</fc>

====reference====
  *[[https://www.cloudflare.com/dns/dnssec/how-dnssec-works/|How DNSSEC Works]]
  *[[https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en|DNSSEC – What Is It and Why Is It Important?]]
  *[[https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions|Domain Name System Security Extensions]]
  *[[https://bind9.readthedocs.io/en/latest/dnssec-guide.html|Bind9 DNSSEC Guide]]
++++ old references |
  *[[https://www.talkdns.com/articles/a-beginners-guide-to-dnssec-with-bind-9/|DNSSEC with BIND 9 A Beginner's Guide to DNSSEC with BIND 9]]
  *[[https://blog.apnic.net/2019/05/23/how-to-deploying-dnssec-with-bind-and-ubuntu-server/|APNIC How to: Deploying DNSSEC with BIND and Ubuntu Server]]
++++
=====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.

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;

        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;

        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>
++++


====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#namedconf-statement-forwarders|Bind Forwarders Grammar]]
    *[[https://bind9.readthedocs.io/_/downloads/en/latest/pdf/|Bind 9 Administrator Reference Manual]]
  *[[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)]]
  *[[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=====
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 ns1.local.kptree.net ns2.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 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
    *use flag ''-t A'' or ''-t AAAA'' to only return IP4 or IP6 results only respectively.  Otherwise both are returned.
  *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=====
   *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>.
   *[[https://www.zytrax.com/books/dns/|DNS for Rocket Scientists]]
   *[[https://hub.docker.com/r/mjkaye/bind9-alpine|mjkaye/bind9-alpine]]
   *[[https://kb.isc.org/docs/aa-00768|Getting started with BIND - how to build and run named with a basic recursive configuration]]
   *[[https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-caching-or-forwarding-dns-server-on-ubuntu-16-04|How To Configure Bind as a Caching or Forwarding DNS Server on Ubuntu 16.04]]
   *[[https://stackoverflow.com/questions/11153958/how-to-enable-named-bind-dns-full-logging|How to enable named/bind/DNS full logging? [closed]]]
   *[[https://á.se/dnssec-bind9-alpine/|dnssec, Bind9 on Alpine]]
   *[[https://www.isc.org/bind/|ISC Bind9]]
   *[[https://hub.docker.com/r/internetsystemsconsortium/bind9|Github internetsystemsconsortium/bind9]]
   *[[https://serverspace.us/support/help/bind9-as-a-secondary-dns-server-on-ubuntu/|How to Configure BIND9 as a Secondary DNS Server on Ubuntu 20.04]]
   *[[https://askubuntu.com/questions/152593/command-line-to-list-dns-servers-used-by-my-system|Command-line to list DNS servers used by my system]]
   *[[https://computingforgeeks.com/configure-slave-bind-dns-server-on-ubuntu/|Configure Slave BIND DNS Server on Ubuntu 22.04|20.04]]

<- docker_notes:docker-mailserver|Back ^ docker_notes:index|Start page ^ docker_notes:docker-dhcp|Next ->