Outils pour utilisateurs

Outils du site


tutoriaux:docker-related:stacks-pi-hole

Ceci est une ancienne révision du document !


Pi-Hole with unbound upstream server

Il n'est plus nécessaire de présenter pi-hole.net tant cet outil rends le contrôle et la réduction des trackers/publicité facile.

En migrant mon instance pi-Hole vers docker, je me suis heurté à un soucis imprévu, l'image officielle ne contient pas de serveur “upstream” intégré; elle est parfaitement fonctionnelle avec des DNS upstream tel que google, quad9, cloudflare, mais si l'on veut réellement être indépendant, il manque son propre référentiel.

Avec docker, il est très facile d'ajouter un container “unbound” et de le configurer en serveur upstream, pour ensuite faire pointer pi-Hole sur ce container.

Cahier de charges

Le stack doit être basé sur des images officielles et maintenues, pour l'image de pi-hole, c'est facile, ca sera l'image officielle, pour ce qui est unbound, il y a un peu plus de choix; j'ai choisis celle de Matthew Vance.

J'ai décidé de composer mon propre “stack” pour lier les deux containers tout en gardant une configuration un peu particulière: je veux que le serveur unbound soit sur un port différent : 5335 du serveur dns.

Les raisons sont multiples, mais la plus évidente est d'éviter que unbound soit publier par accident sur le réseau (ce DNS serveur n'est absolument pas filtré et peut donc présenter des risques importants).

pour parvenir a ce résultat, il va falloir modifier les configurations du serveur unbound, mais aussi de modifier le healthcheck de ce container

Architecture

tutoriaux:docker-related:dns-pihole-unbound-arch.png

unbound

Le container de Matthew contient tout ce qu'il faut pour avoir un unbound serveur avec un résolveur privé et un indicateur de healthcheck; mais ces deux éléments sont défini pour “écouter” sur le port udp:53 et vérifier la santé du container sur ce même port; il faudra donc modifier la configuration du service unbound ET le compose du container, heureusement le container défini un volume de stockages des configurations:

  volumes: 
    - "unbound-etc:/opt/unbound/etc/unbound"

Par défaut l'image de Matthew utilise les résolvers de cloudflare, ce qui ne nous convient pas; il conviendra donc de modifier ces paramètres.

Nous allons donc remplacer les fichiers “par défaut” de Matthew, en s'inspirant de la documentation de pi-Hole concernant l'usage de unbound comme résolveur.

server:
    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    interface: 0.0.0.0
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
 
    # May be set to yes if you have IPv6 connectivity
    do-ip6: no
 
    # 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"
 
    # 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.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

En particulier le fichier nommé forward-records.conf, que nous allons intégralement mettre en commentaire.

    healthcheck:
      test: drill @127.0.0.1 -p 5335 cloudflare.com || exit 1
      interval: 30s
      timeout: 30s
      retries: 3
      start_period: 10s

fichiers

name:stack-dns-pihole-unbound-custom.yaml
networks:
  infrastructure:
    external: true
    name: "infrastructure"

services:
  unbound:

    cap_drop:
      - "AUDIT_CONTROL"
      - "BLOCK_SUSPEND"
      - "DAC_READ_SEARCH"
      - "IPC_LOCK"
      - "IPC_OWNER"
      - "LEASE"
      - "LINUX_IMMUTABLE"
      - "MAC_ADMIN"
      - "MAC_OVERRIDE"
      - "NET_ADMIN"
      - "NET_BROADCAST"
      - "SYSLOG"
      - "SYS_ADMIN"
      - "SYS_BOOT"
      - "SYS_MODULE"
      - "SYS_NICE"
      - "SYS_PACCT"
      - "SYS_PTRACE"
      - "SYS_RAWIO"
      - "SYS_RESOURCE"
      - "SYS_TIME"
      - "SYS_TTY_CONFIG"
      - "WAKE_ALARM"

    command:
      - "/unbound.sh"

    healthcheck:
      test: drill @127.0.0.1 -p 5335 cloudflare.com || exit 1
      interval: 30s
      timeout: 30s
      retries: 3
      start_period: 10s
      
    container_name: dns_unbound

    environment:
      - "PATH=/opt/unbound/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      - "NAME=unbound"
      - "SUMMARY=is a validating, recursive, and caching DNS resolver."
      - "DESCRIPTION=is a validating, recursive, and caching DNS resolver."
      - "TZ=Europe/Brussels"

    expose:
      - "5335/tcp"
      - "5335/udp"

    hostname: "97b5d3c8a2cc"

    image: "mvance/unbound:latest"

    ipc: "private"

    labels:
      maintainer: "Matthew Vance"
      org.opencontainers.image.description: "a validating, recursive, and caching DNS resolver"
      org.opencontainers.image.licenses: "MIT"
      org.opencontainers.image.source: "https://github.com/MatthewVance/unbound-docker"
      org.opencontainers.image.title: "mvance/unbound"
      org.opencontainers.image.url: "https://github.com/MatthewVance/unbound-docker"
      org.opencontainers.image.vendor: "Matthew Vance"
      org.opencontainers.image.version: ""

    logging:
      driver: "json-file"
      options: {}

    networks:
      infrastructure:
        ipv4_address: 172.20.0.200

    restart: "unless-stopped"

    volumes:
      - "unbound-etc:/opt/unbound/etc/unbound"

    working_dir: "/opt/unbound"

  dns-pihole:

    cap_drop:
      - "AUDIT_CONTROL"
      - "BLOCK_SUSPEND"
      - "DAC_READ_SEARCH"
      - "IPC_LOCK"
      - "IPC_OWNER"
      - "LEASE"
      - "LINUX_IMMUTABLE"
      - "MAC_ADMIN"
      - "MAC_OVERRIDE"
      - "NET_ADMIN"
      - "NET_BROADCAST"
      - "SYSLOG"
      - "SYS_ADMIN"
      - "SYS_BOOT"
      - "SYS_MODULE"
      - "SYS_NICE"
      - "SYS_PACCT"
      - "SYS_PTRACE"
      - "SYS_RAWIO"
      - "SYS_RESOURCE"
      - "SYS_TIME"
      - "SYS_TTY_CONFIG"
      - "WAKE_ALARM"

    container_name: dns_pihole

    entrypoint:
      - "/s6-init"

    environment:
      - "PATH=/opt/pihole:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      - "phpver=php"
      - "PHP_ERROR_LOG=/var/log/lighttpd/error-pihole.log"
      - "IPv6=True"
      - "S6_KEEP_ENV=1"
      - "S6_BEHAVIOUR_IF_STAGE2_FAILS=2"
      - "S6_CMD_WAIT_FOR_SERVICES_MAXTIME=0"
      - "FTLCONF_LOCAL_IPV4=0.0.0.0"
      - "FTL_CMD=no-daemon"
      - "DNSMASQ_USER=pihole"
      - "TZ=Europe/Brussels"
      - "WEBPASSWORD=Mdr2Pq3*"

    hostname: "pi-Hole"

    image: "pihole/pihole:latest"

    ipc: "private"

    labels:
      org.opencontainers.image.created: "2024-06-16T19:54:20.386Z"
      org.opencontainers.image.description: "Pi-hole in a docker container"
      org.opencontainers.image.licenses: "NOASSERTION"
      org.opencontainers.image.revision: "4149693092ea364c7aab6c30ba0b308e4bc45716"
      org.opencontainers.image.source: "https://github.com/pi-hole/docker-pi-hole"
      org.opencontainers.image.title: "docker-pi-hole"
      org.opencontainers.image.url: "https://github.com/pi-hole/docker-pi-hole"
      org.opencontainers.image.version: "2024.06.0"

    logging:
      driver: "json-file"
      options: {}

    networks:
      infrastructure:
        ipv4_address: 172.20.0.201

    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "81:80/tcp"

    restart: "unless-stopped"

    volumes:
      - "pihole_config:/etc/pihole"
      - "pihole_dnsmasq:/etc/dnsmasq.d"
 

volumes:
  unbound-etc:
  pihole_config:
  pihole_dnsmasq:
  
tutoriaux/docker-related/stacks-pi-hole.1720261307.txt.gz · Dernière modification : 2024/07/06 12:21 de frater