1 Das Telefonbuch des Internets

Menschen merken sich Namen (fl-pro-consulting.de), Computer brauchen Zahlen (203.0.113.10). DNS übersetzt zwischen beiden — vor jeder Verbindung.

Weil diese Übersetzung am Anfang jeder Verbindung steht, ist DNS eine extrem mächtige Stelle: Wer sie kontrolliert, sieht, wohin du willst — und kann dich umleiten oder blockieren. Genau darum geht es ab Stufe 4.

2 Wie eine Auflösung abläuft

Dein Gerät fragt nicht das ganze Internet — es delegiert an einen rekursiven Resolver, der die Kette für dich abläuft:

Beim ersten Mal läuft die ganze Kette; danach cacht der Resolver die Antwort für die Dauer der TTL (Stufe 2) — die nächste Abfrage derselben Domain ist sofort da.

3 Die Rollen im Überblick

1 Records = die Einträge einer Domain

Eine Domain besteht aus einer Sammlung von Resource Records. Jeder hat einen Typ, der sagt, was gefragt wird. Die wichtigsten:

2 So sieht das in einer Zonendatei aus

; Name        TTL   Klasse Typ   Wert
@             3600  IN     SOA   ns1.example.de. admin.example.de. (
                                  2026061301 ; Serial (Versionsnummer)
                                  7200 3600 1209600 3600 )
@             3600  IN     NS    ns1.example.de.
@             3600  IN     A     203.0.113.10
@             3600  IN     MX    10 mail.example.de.
www           3600  IN     CNAME example.de.
mail          3600  IN     A     203.0.113.20
@             3600  IN     TXT   "v=spf1 mx -all"

3 TTL & Caching

Jeder Record trägt eine TTL (Time To Live) in Sekunden — so lange darf ein Resolver die Antwort cachen, bevor er neu fragt.

1 Das richtige Werkzeug

Je nach System hast du andere Tools an Bord. Wähle oben deine Plattform:

2 Eine Domain abfragen

# A-Record (IPv4)
dig fl-pro-consulting.de A

# nur die nackte Antwort
dig +short fl-pro-consulting.de

# Mailserver der Domain
dig example.de MX +short

# A-Record (IPv4)
dig fl-pro-consulting.de A

# nur die nackte Antwort
dig +short fl-pro-consulting.de

# Mailserver der Domain
dig example.de MX +short

# A-Record (IPv4)
Resolve-DnsName fl-pro-consulting.de -Type A

# Mailserver der Domain
Resolve-DnsName example.de -Type MX

# Klassisch mit nslookup
nslookup -type=MX example.de

Lies die ANSWER SECTION: dort stehen Name, TTL, Typ und Wert. Sinkt die TTL bei wiederholten Abfragen, siehst du den Cache deines Resolvers bei der Arbeit.

3 Einen bestimmten Resolver fragen

Mit @ wählst du gezielt einen DNS-Server — praktisch, um zu vergleichen, ob jemand etwas anders (oder gar nicht) beantwortet:

# Quad9 (9.9.9.9) fragen
dig @9.9.9.9 example.de +short

# Cloudflare (1.1.1.1) zum Vergleich
dig @1.1.1.1 example.de +short

4 Die ganze Kette nachlaufen: +trace

Damit fragt dig selbst von den Root-Servern an nach unten — du siehst Stufe 1 live:

Versionsstand: BIND-dig 9.x / Windows 11 PowerShell · Stand Juni 2026

1 Klassisches DNS ist offen wie eine Postkarte

Die normale DNS-Anfrage läuft über Port 53 — unverschlüsselt. Jeder auf dem Weg (dein Anbieter, der WLAN-Betreiber, ein Angreifer im Netz) kann mitlesen, welche Domains du aufrufst.

Und standardmäßig fragst du den Resolver deines Internetanbieters — denn den verteilt der Router automatisch. Damit liegt diese Übersetzungsstelle, durch die jeder deiner Klicks läuft, in fremder Hand.

2 Was darüber gemacht wird

3 Anbieter-Resolver vs. eigener Weg

1 DoH, DoT & DoQ

Drei Wege, die Postkarte in einen verschlossenen Brief zu verwandeln — dein Anbieter sieht dann nicht mehr, welche Domains du auflöst:

2 Welchen Resolver?

3 Umstellen — wo am besten?

1 Was Pi-hole ist

Pi-hole ist ein DNS-Server für dein Heimnetz: Alle Geräte fragen ihn, er filtert Werbe- und Tracker-Domains per Blocklisten heraus (Antwort = „gibt's nicht") und leitet alles andere an einen Upstream-Resolver weiter.

2 Pi-hole mit Docker starten

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"      # DNS
      - "80:80/tcp"       # Web-Oberfläche
    environment:
      TZ: 'Europe/Berlin'
      FTLCONF_webserver_api_password: 'BITTE-AENDERN'
      FTLCONF_dns_upstreams: '9.9.9.9;149.112.112.112'  # Quad9, vorerst
      FTLCONF_dns_listeningMode: 'all'
    volumes:
      - './etc-pihole:/etc/pihole'
    restart: unless-stopped

3 Einrichten & ins Netz hängen

1. Web-Oberfläche öffnen: http://<pi-hole-ip>/admin, mit dem Passwort anmelden.
2. Unter Lists die Blocklisten prüfen — Standard reicht für den Anfang; bei Bedarf weitere seriöse Listen ergänzen.
3. Router: im DHCP-Server den DNS-Server auf die Pi-hole-IP setzen. Jetzt nutzen alle Geräte automatisch Pi-hole.
4. Auf einem Gerät kurz testen (Werbung weg?) und im Pi-hole-Dashboard die Abfragen live mitlaufen sehen.

1 Warum noch ein Baustein?

Pi-hole filtert, fragt für den Rest aber einen öffentlichen Resolver — der dann doch alle deine Domains sieht. Unbound ist ein eigener, rekursiver und validierender Resolver: er läuft die Kette aus Stufe 1 selbst ab und braucht keinen Dritten.

2 Unbound danebenstellen

services:
  pihole:
    # … wie Stufe 6, aber Upstream auf Unbound zeigen:
    environment:
      FTLCONF_dns_upstreams: 'unbound#53'
    depends_on: [unbound]

  unbound:
    container_name: unbound
    image: mvance/unbound:latest
    volumes:
      - './unbound:/opt/unbound/etc/unbound'
    restart: unless-stopped

3 Prüfen, dass DNSSEC validiert

Versionsstand: Unbound 1.2x · Stand Juni 2026

1 Rekursiv vs. autoritativ

Bisher hast du Resolver gebaut, die für dich fragen (rekursiv). Ein autoritativer Server ist das Gegenteil: er liefert die Antworten für eine Zone, die dir gehört.

2 Mit CoreDNS eine Zone betreiben

CoreDNS ist modern, in Go geschrieben und Docker-freundlich. Es liest ein Corefile und Zonendateien:

heim.lan:53 {
    file /etc/coredns/db.heim.lan
    log
    errors
}
.:53 {
    forward . 192.168.1.53   # alles andere an Pi-hole/Unbound
    cache
}

$TTL 3600
@   IN SOA ns.heim.lan. admin.heim.lan. ( 2026061301 7200 3600 1209600 3600 )
@   IN NS  ns.heim.lan.
ns  IN A   192.168.1.53
nas IN A   192.168.1.10
pi  IN A   192.168.1.53

3 Damit die Welt deine Zone findet

Für eine öffentliche Domain müssen zwei Dinge stimmen — sonst findet dich niemand:

1. NS-Delegation: beim Registrar die NS-Records auf deinen Server zeigen lassen.
2. Glue-Record: ein A-Record für den NS-Hostnamen selbst (sonst Henne-Ei-Problem). Voraussetzung: eine statische, öffentliche IP — also ein VPS.

4 Praxis-Bonus: DDNS & Zertifikate

1 Gegen Manipulation absichern

2 Datenschutz beim Logging

Query-Logs sind hochsensibel — sie verraten alles, was im Netz aufgerufen wird.

• Pi-hole: Privacy-Level hochsetzen, Aufbewahrung kurz halten.
• Im Firmen-/Familienkontext: wer sehen darf, was geloggt wird, ist eine echte DSGVO-Frage.
• So wenig speichern wie möglich — Statistik ja, Vollprotokoll selten nötig.

3 Backup & Ausfallsicherheit

1. Backup: Pi-hole-Einstellungen per Teleporter exportieren; docker-compose.yml + Volumes sichern.
2. Fallback-Resolver: am Client/Router einen zweiten DNS hinterlegen — fällt dein Pi-hole aus, bleibt das Netz erreichbar.
3. Monitoring: Verfügbarkeit überwachen (z. B. Uptime-Kuma — siehe Self-Hosting-Schulung).
4. Server härten: SSH absichern, Updates fahren — siehe SSH und Docker.

🔎 Abfragen

# A-Record, nur die Antwort
dig +short example.de

# bestimmten Typ abfragen
dig example.de MX
dig example.de TXT

# gezielt einen Resolver fragen
dig @9.9.9.9 example.de

# ganze Kette ab Root nachlaufen
dig +trace example.de

# Windows (PowerShell)
Resolve-DnsName example.de -Type A

📇 Record-Typen

🕳️ Pi-hole + Unbound (Docker)

services:
  pihole:
    image: pihole/pihole:latest
    ports: ["53:53/tcp", "53:53/udp", "80:80/tcp"]
    environment:
      FTLCONF_webserver_api_password: 'AENDERN'
      FTLCONF_dns_upstreams: 'unbound#53'
    volumes: ['./etc-pihole:/etc/pihole']
    restart: unless-stopped
  unbound:
    image: mvance/unbound:latest
    volumes: ['./unbound:/opt/unbound/etc/unbound']
    restart: unless-stopped

🔐 Resolver & Verschlüsselung