in ,

Pi-hole mit unbound (TLS + DNSSEC)

Einleitung

Pi-hole bietet standardmäßig kein DoT (DNS over TLS), also verschlüsselte Übertragung unserer Anfragen an den DNS-Server.

Das wollen wir mit dem Zusatzprogramm unbound realisieren, zudem werden wir hier auch gleich DNSSEC aktivieren (und nicht im Pi-hole selbst), um Authentizität und Integrität von DNS-Antworten zu prüfen.
Das ist nicht zwingend notwendig, aber ein nice to have.

Als Anhaltspunkte dienen uns die Wiki Seiten:
https://docs.pi-hole.net/guides/dns/unbound/
https://wiki.archlinux.org/title/Unbound

Für die DNSSEC Validierungen gibt es das Paket dnssec-anchors und es verwendet die Server von https://data.iana.org/root-anchors/

DNSSEC testen können wir auf der Webseite:
https://wander.science/projects/dns/dnssec-resolver-test/

Aktuell haben wir kein DNSSEC aktiviert:

Unbound installieren und einrichten

Unbound installieren wir mit yay. Die Abhängigkeiten werden automatisch mit installiert. dnssec-anchors war bereits installiert:

yay -S unbound

yay -Q |grep anchor

Nach der Installation benennen wir die originale Config-Datei um:

  • sudo mv /etc/unbound/unbound.conf /etc/unbound/unbound.conf.orig

Die Log-Datei legen wir auch gleich an, und setzen die Berechtigungen für den unbound Benutzer:

  • sudo touch /etc/unbound/unbound.log
  • sudo chown unbound:unbound /etc/unbound/unbound.log

Jetzt befüllen wir die Conf-Datei mit dem Inhalt aus der Pi-hole Dokumentation, und ändern diese gleich für uns ab. Wir ergänzen auch gleich den Eintrag für DNSSEC (trust-anchor-file)

  • sudo vim /etc/unbound/unbound.conf

server:
    # If no logfile is specified, syslog is used
    logfile: "/etc/unbound/unbound.log"
    log-time-ascii: yes
    verbosity: 1
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    
    # May be set to yes if you have IPv6 connectivity
    do-ip6: yes
    
    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    #root-hints: "/var/lib/unbound/root.hints"

    # DNSSEC
    trust-anchor-file: /etc/unbound/trusted-key.key

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.42.0/24
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

    # Ensure no reverse queries to non-public IP ranges (RFC6303 4.2)
    private-address: 192.0.2.0/24
    private-address: 198.51.100.0/24
    private-address: 203.0.113.0/24
    private-address: 255.255.255.255/32
    private-address: 2001:db8::/32
  • Zusätzlich fügen wir noch ein paar Performance Tuning Parameter ein:

######## Performance #########

# More cache memory, rrset=msg*2 | Default: 4m, 4m
msg-cache-size: 32m
rrset-cache-size: 64m

# Time  to  live [minimum|maximum] for RRsets and messages in the cache | Default: 0, 86400
cache-min-ttl: 3600
cache-max-ttl: 86400

# Serve old responses from cache with a TTL of 0 in the response without waiting for the actual resolution to finish | Default: no, 0
serve-expired: yes
serve-expired-ttl: 86400

# Fetch DNSKEYs earlier (DNSSEC): More cpu usage, less latency | Default: no
prefetch-key: yes

# Helps to reduce the query rate towards targets that get a very high nonexistent name lookup rate | Default: no
aggressive-nsec: yes

## Privacy | Default: no, no
hide-identity: yes
hide-version: yes
  • Als nächsten fügen wir die Einträge für DoT ein. Wir verwenden hier die cloudflare Server

######## DNS over TLS #########

tls-upstream: yes
tls-cert-bundle: "/etc/ssl/cert.pem"

# Use an upstream DNS-over-TLS forwarder and do not fall back to cleartext if that fails
forward-zone:
name: "."
forward-tls-upstream: yes

# use DNS-over-TLS forwarder
forward-first: no

# do NOT send direct
# the hostname after "#" is not a comment, it is used for TLS checks:
# cloudflare
forward-addr: 1.1.1.1@853#cloudflar-dns.com
forward-addr: 1.0.0.1@853#cloudflar-dns.com
Unbound aktivieren wir nun für den Autostart and starten es an:
  • sudo systemctl enable unbound
  • sudo systemctl start unbound

Für das Testen orientieren wir uns wieder am Wiki: https://wiki.archlinux.org/title/Unbound#DNSSEC_validation

Der Test sollte uns jetzt ein secure zurückmelden:

unbound-host -vDr go.dnscheck.tools

Da anscheinend alles funktioniert, werden wir die Upstream-Server deaktivieren und unseren unbound-Server unter Settings à DNS eintragen.

Zur Sicherheit starten wir Pi-hole noch einmal neu und testen dann einfach ob wir Webseiten ansurfen können.

  • sudo systemctl restart pihole-FTL

Zum Testen surfen wir gleich die DNSSEC Webseite an und starten den Test:
https://wander.science/projects/dns/dnssec-resolver-test/

Fazit

Unser Pi-hole läuft jetzt über unseren unbound-Server, der die Anfragen verschlüsselt an die cloudflare-Server schickt. Prinzipiell können wir hier alle DNS-Server als forward-addr eintragen, sofern sie TLS unterstützen.

DNSSEC funktioniert ebenfalls, wir benötigen es im Moment allerdings nicht. Trotzdem haben wir eine funktionierende Installation, falls wir es einmal benötigen.

Die 5 Vs von Big Data erklärt

Programmieren mit KI: Was bringt das?