DNS Knowledge Base – Statische Netze, ARP, Zonen, TTL

Quellen

  • RFC 9499 – DNS Terminology (März 2024, aktuell)
  • RFC 1034/1035 – DNS Original Spezifikation (1987)
  • RFC 2308 – Negative Caching
  • RFC 1918 – Private Address Space

Teil 1: Bevor DNS – Das Netz selbst verstehen

Warum das wichtig ist

DNS löst Namen in IP-Adressen auf. Aber bevor ein Paket von A nach B kommt,
muss das Netz selbst funktionieren. Kein ARP → kein Layer 2 → kein DNS.
Dieser Teil erklärt die Schicht unter DNS.

1.1 IP-Adressen: Die Klassen-Ära (historisch aber lebendig)

Vor CIDR (Classless Inter-Domain Routing) gab es feste Klassen.
Sie sind heute noch überall – in altem Code, alten Geräten, FreeBSD-Configs.

Klasse A: 1.0.0.0   – 126.255.255.255  /8   16.777.214 Hosts
Klasse B: 128.0.0.0 – 191.255.255.255  /16  65.534 Hosts
Klasse C: 192.0.0.0 – 223.255.255.255  /24  254 Hosts
Klasse D: 224.0.0.0 – 239.255.255.255  Multicast (kein Unicast)
Klasse E: 240.0.0.0 – 255.255.255.255  Reserviert (experimentell)

Sonderfall: 127.x.x.x → Loopback (nie im Netz sichtbar)

Warum Klasse A endet bei 126:

127.x.x.x ist Loopback → 127.0.0.1 = "ich selbst"
0.x.x.x   ist Netzadresse → reserviert
→ Klasse A: nur 1–126 nutzbar

RFC 1918 – Private Adressräume (kein Internet-Routing)

10.0.0.0     – 10.255.255.255    /8   (ein komplettes Klasse-A-Netz)
172.16.0.0   – 172.31.255.255    /12  (16 Klasse-B-Netze)
192.168.0.0  – 192.168.255.255   /16  (256 Klasse-C-Netze)

Diese Adressen werden im Internet nie geroutet.
→ Ideal für RZ-interne Infrastruktur.

1.2 Subnetting und Netmask – kein DHCP, alles statisch

Die Netmask definiert welcher Teil einer IP-Adresse Netz ist
und welcher Host.

IP:      192.168.10.42
Maske:   255.255.255.0   (/24)
         ─────────────
Netz:    192.168.10.0    → Netzadresse (nicht vergebar!)
Host:    .42             → dieser Rechner
Bcast:   192.168.10.255  → Broadcast (nicht vergebar!)
Nutzbar: 192.168.10.1 – 192.168.10.254 → 254 Hosts

CIDR-Notation

/8   = 255.0.0.0         → 16.777.214 Hosts (Klasse A)
/16  = 255.255.0.0       → 65.534 Hosts     (Klasse B)
/19  = 255.255.224.0     → 8.190 Hosts      (dein RZ!)
/24  = 255.255.255.0     → 254 Hosts        (Klasse C)
/25  = 255.255.255.128   → 126 Hosts
/26  = 255.255.255.192   → 62 Hosts
/27  = 255.255.255.224   → 30 Hosts
/28  = 255.255.255.240   → 14 Hosts
/30  = 255.255.255.252   → 2 Hosts (Point-to-Point Links)
/32  = 255.255.255.255   → 1 Host (Loopback, Virtual IP)

/19 auseinandergenommen (dein RZ-Netz)

Netz:    10.0.0.0/19
Maske:   255.255.224.0
Bereich: 10.0.0.1 – 10.0.31.254
Bcast:   10.0.31.255
Hosts:   8.190

Typische Aufteilung im RZ:
10.0.0.0/24   → Management / IPMI
10.0.1.0/24   → Produktiv Server
10.0.2.0/24   → Backup / Storage
10.0.10.0/24  → DMZ
10.0.20.0/24  → Monitoring

1.3 ARP – Address Resolution Protocol

ARP ist die Brücke zwischen Layer 3 (IP) und Layer 2 (MAC).

DNS sagt: "www.example.com ist 10.0.1.50"
ARP sagt: "10.0.1.50 hat die MAC-Adresse aa:bb:cc:dd:ee:ff"

Ohne ARP kein Ethernet-Frame. Ohne Frame kein Paket.
ARP ist das stille Grundrauschen jedes Netzes.

ARP-Ablauf (vereinfacht)

Server A (10.0.1.10) will zu Server B (10.0.1.20):

1. A prüft: Ist B im gleichen Subnetz?
   10.0.1.10 /24 → Netz 10.0.1.0 → 10.0.1.20 ist drin → ja!

2. A schickt ARP Request (Broadcast):
   "Wer hat 10.0.1.20? Sag es 10.0.1.10"
   → Ziel-MAC: ff:ff:ff:ff:ff:ff (alle im Segment)

3. B antwortet (Unicast):
   "10.0.1.20 bin ich: aa:bb:cc:dd:ee:ff"

4. A speichert das im ARP-Cache
   Pakete fließen jetzt direkt.

ARP-Cache anzeigen und pflegen

# ARP-Cache anzeigen
arp -n                           # Linux
arp -an                          # macOS / FreeBSD
ip neigh show                    # Linux modern

# Statischen ARP-Eintrag setzen (statisches Netz!)
arp -s 10.0.1.20 aa:bb:cc:dd:ee:ff

# ARP-Cache leeren
ip neigh flush all               # Linux
arp -d 10.0.1.20                 # einzelnen Eintrag löschen

# ARP-Requests live beobachten
tcpdump -n -i eth0 arp

ARP im RZ: Segmentierte vs. unsegmentierte Netze

UNSEGMENTIERTES NETZ (flaches Layer 2):
─────────────────────────────────────
Alle Server im gleichen Broadcast-Domain.
z.B. 10.0.0.0/16 ohne VLANs

Problem:
→ Jeder ARP-Broadcast geht an ALLE 65.534 möglichen Hosts
→ Bei 200 Servern: ARP-Gewitter bei vielen Neuverbindungen
→ ARP-Spoofing einfach möglich
→ Ein Fehler kann das gesamte Netz lahmlegen

SEGMENTIERTES NETZ (VLANs / Subnets):
──────────────────────────────────────
Jedes Subnetz = eigene Broadcast-Domain.
z.B. /24 pro Funktionsbereich

Vorteil:
→ ARP-Broadcasts bleiben im Segment
→ Routing zwischen Segmenten → kontrollierbar
→ Firewall-Regeln zwischen Segmenten möglich
→ Ausfall eines Segments isoliert

ARP-Probleme im RZ-Alltag

# Problem: Duplicate IP – zwei Hosts, gleiche IP
# Symptom: Verbindungsabbrüche, flapping ARP
# Diagnose:
arping -I eth0 10.0.1.50   # Wer antwortet auf diese IP?
# Wenn zwei MACs antworten → Duplicate IP gefunden

# Problem: Stale ARP – alter Eintrag nach IP-Umzug
# Symptom: Verbindung zu neuem Host schlägt fehl
# Lösung:
ip neigh flush dev eth0

# ARP-Cache Timeout prüfen (Linux)
cat /proc/sys/net/ipv4/neigh/default/gc_stale_time
# Standard: 60 Sekunden

Teil 2: DNS – Grundkonzepte (RFC 9499 konform)

Was DNS ist

DNS (Domain Name System) ist ein verteiltes, hierarchisches
Namensauflösungssystem. Es übersetzt menschenlesbare Namen
(www.example.com) in maschinenlesbare Adressen (93.184.216.34).

Anfrage:   "Was ist die IP von www.example.com?"
DNS:       "93.184.216.34"
Protokoll: UDP Port 53 (Standard) / TCP Port 53 (Transfers, große Antworten)

Die DNS-Hierarchie

.                          ← Root (der unsichtbare Punkt am Ende)
├── com.
│   ├── example.com.
│   │   ├── www.example.com.
│   │   └── mail.example.com.
│   └── google.com.
├── de.
│   └── heise.de.
└── net.
    └── iana.net.

Jede Ebene hat eigene Nameserver.
Jede Delegation ist ein Schnitt in der Hierarchie.

DNS-Komponenten (RFC 9499 Terminologie)

Begriff RFC 9499 Definition Praxis
Resolver Fragt andere DNS-Server /etc/resolv.conf
Recursive Resolver Löst vollständig auf, cached Dein DNS-Server
Authoritative Server Kennt die Zone, gibt definitive Antwort BIND named
Stub Resolver Fragt nur weiter, löst nicht selbst auf glibc im OS
Forwarder Leitet Anfragen an anderen Server weiter Split-DNS
Zone Verwaltungseinheit im DNS example.com Zone
FQDN Fully Qualified Domain Name www.example.com. (mit Punkt!)

2.1 Resource Records – Die Bausteine

Jeder DNS-Eintrag ist ein Resource Record (RR) mit diesem Format:

NAME        TTL    CLASS  TYPE   RDATA
www         3600   IN     A      93.184.216.34
mail        3600   IN     MX     10 smtp.example.com.
example.com 86400  IN     SOA    ns1.example.com. admin.example.com. ...

Die wichtigsten Record-Typen

A      → IPv4-Adresse          www     IN A     93.184.216.34
AAAA   → IPv6-Adresse          www     IN AAAA  2606:2800:220:1:...
CNAME  → Alias (Canonical Name) ftp    IN CNAME www.example.com.
MX     → Mail Exchange          @      IN MX    10 mail.example.com.
NS     → Nameserver             @      IN NS    ns1.example.com.
PTR    → Reverse DNS            50.1.0.10.in-addr.arpa. IN PTR server01.example.com.
SOA    → Start of Authority     @      IN SOA   ns1 admin 2026032601 ...
TXT    → Text (SPF, DKIM, etc.) @      IN TXT   "v=spf1 mx -all"
SRV    → Service Locator        _sip._tcp IN SRV 10 5 5060 sip.example.com.
CAA    → Certificate Authority  @      IN CAA   0 issue "letsencrypt.org"

SOA Record – das Herz jeder Zone

example.com.  86400  IN  SOA  ns1.example.com.  hostmaster.example.com. (
    2026032601  ; Serial    → YYYYMMDDNN Format, bei jeder Änderung erhöhen!
    3600        ; Refresh   → Slave fragt Master alle 3600s (1h)
    900         ; Retry     → Bei Fehler: retry nach 900s (15min)
    604800      ; Expire    → Slave verwirft Zone nach 604800s (7 Tage) ohne Master
    300         ; Minimum   → Negative TTL (NXDOMAIN wird 300s gecacht)
)

2.2 TTL – Time To Live

TTL ist keine Netzwerk-TTL (IP-Hop-Count). DNS-TTL ist Zeit in Sekunden.

TTL = wie lange darf ein Resolver diesen Eintrag cachen?

Hohe TTL (86400 = 1 Tag):
→ Gut: weniger DNS-Traffic, schnellere Auflösung
→ Schlecht: Änderungen brauchen 24h bis sie überall ankommen

Niedrige TTL (60 = 1 Minute):
→ Gut: Änderungen propagieren schnell
→ Schlecht: mehr DNS-Traffic, Lastspitzen

RZ-Empfehlungen:
→ Stabile Server:     86400   (1 Tag)
→ Lastverteilung:     300     (5 Minuten)
→ Vor Migrationen:    300     (erst reduzieren, dann umziehen, dann wieder erhöhen!)
→ Negative TTL (SOA): 300–900 (NXDOMAIN nicht zu lang cachen)

TTL-Praxis: Migration ohne Downtime

Tag -2:  TTL auf 300 senken
         → warten bis alte TTL überall abläuft
         → (max. alter TTL-Wert in Sekunden warten!)

Tag 0:   IP ändern
         → alle Caches laufen in max. 300s ab
         → neuer Server bekommt Traffic

Tag +1:  TTL wieder auf 86400 erhöhen

2.3 Zonen und Zonentransfer

Was eine Zone ist

Eine Zone ist der Verwaltungsbereich eines Authoritative Servers.
Sie enthält alle RRs für eine Domäne.

Zonefile: /etc/bind/zones/example.com
Inhalt:
$ORIGIN example.com.
$TTL 86400

@       IN  SOA  ns1.example.com. hostmaster.example.com. (
                 2026032601 3600 900 604800 300 )

@       IN  NS   ns1.example.com.
@       IN  NS   ns2.example.com.

ns1     IN  A    10.0.0.53
ns2     IN  A    10.0.0.54
@       IN  A    10.0.1.10
www     IN  A    10.0.1.10
mail    IN  A    10.0.1.20
@       IN  MX   10 mail.example.com.

Zonentransfer: Master → Slave (AXFR/IXFR)

AXFR (Full Zone Transfer):
→ Komplette Zone wird übertragen
→ Auslöser: Slave fragt nach Refresh-Intervall (SOA)
→ Serial im SOA gestiegen → Transfer startet
→ Serial gleich → kein Transfer

IXFR (Incremental Zone Transfer):
→ Nur Änderungen seit letztem Transfer
→ Effizienter bei großen Zonen
→ Nicht alle BIND-Versionen unterstützen es vollständig

# Manueller Zonentransfer testen
dig AXFR example.com @ns1.example.com

# Häufiges Problem aus den Logs:
# "retry limit for master 10.0.0.53 exceeded"
# → Master nicht erreichbar → Port 53 TCP prüfen!
# (Zonentransfer läuft über TCP, nicht UDP!)

# Zonentransfer-Log prüfen
journalctl -u named | grep -i transfer
journalctl -u named | grep -i "zone.*transfer"

Zonentransfer absichern (TSIG)

# TSIG Key generieren
tsig-keygen -a hmac-sha256 transfer-key

# In named.conf:
key "transfer-key" {
    algorithm hmac-sha256;
    secret "BASE64SECRET==";
};

zone "example.com" {
    type master;
    allow-transfer { key "transfer-key"; };
};

Teil 3: BIND/named – Konfiguration

named.conf Grundstruktur

/etc/bind/named.conf                ← Hauptkonfiguration (Debian/Ubuntu)
/etc/named.conf                     ← RHEL/Rocky/Fedora
/etc/named.conf                     ← Arch
/usr/local/etc/namedb/named.conf    ← FreeBSD!

# named.conf Aufbau:
options {
    listen-on     { 10.0.0.53; 127.0.0.1; };
    listen-on-v6  { none; };
    directory     "/var/cache/bind";        # Debian
    # directory   "/var/named";             # RHEL
    recursion     yes;
    allow-recursion { 10.0.0.0/19; localhost; };
    allow-query   { any; };
    forwarders    { 9.9.9.9; 149.112.112.112; };  # Quad9
    forward       only;                            # oder: first
};

# Eigene Zone (autoritativ):
zone "example.com" {
    type master;
    file "/etc/bind/zones/example.com";    # Debian
    # file "/var/named/example.com.zone";  # RHEL
    allow-transfer { 10.0.0.54; };         # Slave-IP
    notify yes;
};

# Slave-Zone:
zone "example.com" {
    type slave;
    masters { 10.0.0.53; };
    file "/var/cache/bind/example.com.slave";
};

# Reverse-Zone:
zone "0.0.10.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/10.0.0.rev";
};

3.1 Split-DNS (RFC 9499: Private DNS)

Split-DNS liefert intern andere Antworten als extern.

Extern: www.example.com → 93.184.216.34 (öffentliche IP)
Intern: www.example.com → 10.0.1.10     (interne IP)

Warum?
→ Interne Server sollen intern direkt kommunizieren
→ Kein Hairpin-NAT am Router nötig
→ Interne Dienste nicht nach außen exponiert

# named.conf mit views:
view "internal" {
    match-clients { 10.0.0.0/19; localhost; };
    recursion yes;

    zone "example.com" {
        type master;
        file "/etc/bind/zones/example.com.internal";
    };
};

view "external" {
    match-clients { any; };
    recursion no;

    zone "example.com" {
        type master;
        file "/etc/bind/zones/example.com.external";
    };
};

3.2 Reverse DNS (PTR Records)

PTR-Records sind das Gegenstück zu A-Records.

A-Record:   server01.example.com. → 10.0.1.50
PTR-Record: 10.0.1.50 → server01.example.com.

Die Reverse-Zone für 10.0.1.0/24:
Zonename: "1.0.10.in-addr.arpa"
          ↑ IP-Oktette umgekehrt!

Für 10.0.0.0/19 (mehrere /24):
→ Mehrere Reverse-Zonen nötig:
  "0.0.10.in-addr.arpa"   (für 10.0.0.x)
  "1.0.10.in-addr.arpa"   (für 10.0.1.x)
  usw.

# Reverse-Zonefile:
$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400

@   IN  SOA  ns1.example.com. hostmaster.example.com. (
             2026032601 3600 900 604800 300 )

@   IN  NS   ns1.example.com.
@   IN  NS   ns2.example.com.

50  IN  PTR  server01.example.com.
51  IN  PTR  server02.example.com.
53  IN  PTR  ns1.example.com.
54  IN  PTR  ns2.example.com.

3.3 Distro-Unterschiede: named/BIND

Debian / Ubuntu

# Paket
apt install bind9 bind9utils bind9-doc

# Konfigurationspfade
/etc/bind/named.conf               # Hauptconfig
/etc/bind/named.conf.options       # Options-Block
/etc/bind/named.conf.local         # eigene Zonen
/etc/bind/zones/                   # Zonefiles

# Service
systemctl restart named
systemctl status named

# AppArmor! (Ubuntu Besonderheit)
# named läuft im AppArmor-Profil
# Zonefile außerhalb /etc/bind/ → AppArmor verweigert Zugriff!
aa-status | grep named

# named-checkconf / named-checkzone
named-checkconf
named-checkzone example.com /etc/bind/zones/example.com

# Zone neu laden ohne Restart
rndc reload example.com
rndc reload                        # alle Zonen

RHEL / Rocky / AlmaLinux

# Paket
dnf install bind bind-utils

# Konfigurationspfade
/etc/named.conf                    # Hauptconfig
/var/named/                        # Zonefiles!
/var/named/example.com.zone

# Service
systemctl restart named

# SELinux! (RHEL Besonderheit)
# named darf nur in /var/named schreiben
# Zonefile woanders → SELinux verweigert
ls -Z /var/named/                  # SELinux-Kontext prüfen
restorecon -v /var/named/*.zone    # Kontext reparieren

# named-checkconf / named-checkzone
named-checkconf /etc/named.conf
named-checkzone example.com /var/named/example.com.zone

FreeBSD

# BIND im Basissystem (je nach Version)
# oder via Ports
pkg install bind918

# Konfigurationspfade – KOMPLETT ANDERS!
/usr/local/etc/namedb/named.conf   # Hauptconfig
/usr/local/etc/namedb/master/      # Zonefiles
/usr/local/etc/namedb/slave/       # Slave-Zonen

# /etc/rc.conf Eintrag nötig:
named_enable="YES"

# Service
service named start
service named restart

# rndc funktioniert gleich wie auf Linux
rndc reload
rndc status

Vergleichsmatrix

Aspekt Debian/Ubuntu RHEL/Rocky FreeBSD
Paket bind9 bind bind918 (Port)
Hauptconfig /etc/bind/named.conf /etc/named.conf /usr/local/etc/namedb/named.conf
Zonefiles /etc/bind/zones/ /var/named/ /usr/local/etc/namedb/master/
Sicherheits-Framework AppArmor SELinux keins (Jail optional)
Aktivierung systemctl enable named systemctl enable named named_enable="YES" in rc.conf

Teil 4: DNS-Diagnose – Das tägliche Handwerk

dig – der wichtigste DNS-Werkzeug

# Einfache Abfrage
dig www.example.com

# Nur die Antwort (kein Header-Rauschen)
dig +short www.example.com

# Bestimmten Record-Typ
dig MX example.com
dig NS example.com
dig SOA example.com
dig AAAA www.example.com

# Bestimmten Server befragen
dig @10.0.0.53 www.example.com

# Reverse-DNS
dig -x 10.0.1.50
dig PTR 50.1.0.10.in-addr.arpa

# Zonentransfer testen
dig AXFR example.com @10.0.0.53

# TTL im Cache prüfen (externer Server)
dig @8.8.8.8 www.example.com
# → TTL in der Antwort zeigt verbleibende Cache-Zeit!

# Trace vom Root bis zur Antwort
dig +trace www.example.com

# DNSSEC prüfen
dig +dnssec example.com

nslookup und host (für alte FreeBSD-Admins 😄)

# nslookup (interaktiv oder direkt)
nslookup www.example.com
nslookup www.example.com 10.0.0.53  # bestimmter Server

# host
host www.example.com
host -t MX example.com
host 10.0.1.50                      # Reverse-DNS

rndc – BIND-Steuerung

# Status
rndc status

# Zone neu laden (nach Änderung)
rndc reload example.com

# Cache leeren (bei Debugging!)
rndc flush
rndc flushname www.example.com

# Zone aus dem Speicher dumpen
rndc dumpdb -cache

# Statistiken
rndc stats
cat /var/cache/bind/named_stats.txt  # Debian

Häufige Fehler und Diagnose

# Fehler: SERVFAIL
# → named läuft aber antwortet nicht korrekt
# → SELinux/AppArmor blockiert Zonefile
# → Zonefile-Syntax-Fehler
named-checkzone example.com /etc/bind/zones/example.com
journalctl -u named -n 50

# Fehler: NXDOMAIN
# → Name existiert nicht (oder falsche Zone geladen)
# → Serial nicht erhöht → Slave hat alte Zone
dig SOA example.com @ns1.example.com  # Serial prüfen
dig SOA example.com @ns2.example.com  # Slave-Serial vergleichen

# Fehler: Zonentransfer schlägt fehl
# "retry limit for master exceeded"
# → TCP Port 53 blockiert!
telnet 10.0.0.53 53                   # TCP-Verbindung testen
iptables -L | grep 53                 # Firewall prüfen
netstat -tlnp | grep named            # named lauscht?

# Fehler: named startet nicht (RHEL)
# → SELinux Kontext falsch
ausearch -m AVC -ts recent            # SELinux-Denials
restorecon -Rv /var/named/

# Fehler: named startet nicht (Ubuntu)
# → AppArmor blockiert
dmesg | grep apparmor
journalctl -u apparmor | grep named

Teil 5: DNS im RZ-Kontext

Statisches DNS-Setup für ein RZ (/19 Netz)

Infrastruktur:
10.0.0.53  ns1.example.com  ← Primary Nameserver (Master)
10.0.0.54  ns2.example.com  ← Secondary Nameserver (Slave)

Alle Server bekommen:
/etc/resolv.conf:
  nameserver 10.0.0.53
  nameserver 10.0.0.54
  search example.com
  domain example.com

# Debian/Ubuntu: /etc/resolv.conf wird von systemd-resolved verwaltet!
# Für statisches RZ-Setup:

# Option A: systemd-resolved deaktivieren
systemctl disable systemd-resolved
systemctl stop systemd-resolved
rm /etc/resolv.conf
echo "nameserver 10.0.0.53" > /etc/resolv.conf
echo "nameserver 10.0.0.54" >> /etc/resolv.conf
echo "search example.com" >> /etc/resolv.conf
chattr +i /etc/resolv.conf            # Immutable! Verhindert Überschreiben

# Option B: systemd-resolved konfigurieren
# /etc/systemd/resolved.conf:
[Resolve]
DNS=10.0.0.53 10.0.0.54
Domains=example.com

/etc/hosts – der Urahn vor DNS

# Vor DNS: Jeder Rechner hatte eine /etc/hosts
# Heute: Notfall-Fallback, lokale Overrides

# /etc/hosts wird VOR DNS aufgelöst (nsswitch.conf: files dns)
# Nützlich für:
# → Bootstrap: wenn DNS selbst noch nicht läuft
# → Notfall: wenn DNS ausgefallen ist
# → Overrides: interne Test-URLs

cat /etc/hosts
# 127.0.0.1   localhost
# 10.0.0.53   ns1.example.com ns1
# 10.0.0.54   ns2.example.com ns2

# nsswitch.conf bestimmt Suchreihenfolge
grep hosts /etc/nsswitch.conf
# hosts: files dns    ← zuerst /etc/hosts, dann DNS
# hosts: dns files    ← zuerst DNS, dann /etc/hosts (ungewöhnlich)

Teil 6: DNS-Begriffe nach RFC 9499 (Schnellreferenz)

RFC 9499 Begriff Bedeutung im Alltag
Authoritative Server Weiß die Wahrheit über eine Zone
Recursive Resolver Fragt rum bis er die Antwort hat, cached
Stub Resolver Das OS-Tool (glibc), fragt nur weiter
Forwarder Leitet Anfragen weiter (Split-DNS)
Zone Verwaltungseinheit, eine Datei auf dem Server
Delegation NS-Record der auf anderen Server zeigt
NXDOMAIN Name existiert nicht (negatives Ergebnis)
NOERROR Anfrage erfolgreich (auch wenn keine Records)
SERVFAIL Server-Fehler – konfigurationsproblem!
TTL Wie lange darf gecacht werden (Sekunden)
Serial Versionsnummer der Zone (muss steigen!)
AXFR Vollständiger Zonentransfer
IXFR Inkrementeller Zonentransfer
FQDN Vollständiger Name mit Punkt am Ende: host.example.com.
Glue Record A-Record für NS-Server der in der eigenen Zone liegt
Negative Caching NXDOMAIN-Antworten werden auch gecacht (RFC 2308)

Wichtige Dateipfade – Alle Systeme

Datei Debian/Ubuntu RHEL/Rocky FreeBSD
Hauptconfig /etc/bind/named.conf /etc/named.conf /usr/local/etc/namedb/named.conf
Zonefiles /etc/bind/zones/ /var/named/ /usr/local/etc/namedb/master/
resolv.conf /etc/resolv.conf /etc/resolv.conf /etc/resolv.conf
hosts /etc/hosts /etc/hosts /etc/hosts
nsswitch /etc/nsswitch.conf /etc/nsswitch.conf /etc/nsswitch.conf
rndc-Key /etc/bind/rndc.key /etc/rndc.key /usr/local/etc/namedb/rndc.key
Log journalctl -u named journalctl -u named /var/log/messages

Quellen

  • RFC 9499 – DNS Terminology (März 2024): https://www.rfc-editor.org/rfc/rfc9499
  • RFC 1034 – Domain Concepts and Facilities
  • RFC 1035 – Domain Implementation and Specification
  • RFC 1918 – Private Address Space
  • RFC 2308 – Negative Caching of DNS Queries
  • man named, man named.conf, man dig, man rndc
  • Arch Wiki: https://wiki.archlinux.org/title/BIND
  • Debian BIND9 Docs: https://bind9.readthedocs.io/