So betreiben Sie DNS mit einem Hidden Primary und öffentlichen Secondaries

Der Server, auf dem Sie Ihre DNS-Zonen bearbeiten, muss dem Internet nicht antworten, und er sollte es auch nicht. Ein Hidden Primary hält die autoritative Kopie und nimmt Änderungen von Ihren Leuten und Ihrer Automatisierung entgegen. Eine Gruppe öffentlicher Secondaries, die einzigen Server in Ihren NS-Einträgen, beantwortet jede Anfrage. Der Primary kann gepatcht, neu gestartet oder von niemandem angegriffen werden, weil niemand draußen weiß, wo er ist. Dieser Artikel zeigt, wie Sie das mit PowerDNS bauen, die zwei Wege, Daten vom Primary zu den Secondaries zu bringen, und die Prüfungen, die beweisen, dass der Primary wirklich verborgen ist.

Die Form des Entwurfs

• Ein Primary in einem privaten Netzwerk, ohne öffentliche Adresse, nie in NS- oder SOA-Einträgen genannt. Er betreibt die API und die Weboberfläche, die Ihr Team nutzt.
• Zwei oder mehr öffentliche Secondaries an verschiedenen Standorten, idealerweise in verschiedenen Netzwerken und bei verschiedenen Anbietern oder Plattformen, damit kein einzelner Ausfall alle zugleich trifft.
• Ein privater Pfad vom Primary zu jedem Secondary, nur für die Replikation.
• Die Secondaries antworten weiter, wenn der Primary verschwindet. Sie halten eine vollständige Kopie, also bedeutet ein toter Primary «eine Weile keine Änderungen», nicht «Domain offline».

Es gibt zwei Wege, die Secondaries zu speisen. Beide funktionieren. Sie passen zu unterschiedlichen Teams.

Option eins: Zonentransfers mit NOTIFY und TSIG

Das ist Standard-DNS und funktioniert mit jeder Mischung von DNS-Servern. Der Primary sendet ein NOTIFY, wenn sich eine Zone ändert. Der Secondary prüft die SOA-Seriennummer und holt die Zone per AXFR oder IXFR.

Auf dem Primary, in pdns.conf:

primary=yes
allow-axfr-ips=192.0.2.21/32,198.51.100.31/32
also-notify=192.0.2.21,198.51.100.31
only-notify=

Diese Adressen sind die privaten Adressen der Secondaries. Wenn only-notify leer bleibt und die Ziele in also-notify stehen, geht das NOTIFY nur an Ihre Secondaries, nie an das, was zufällig in den NS-Einträgen steht.

Signieren Sie dann die Transfers. Eine IP-Erlaubnisliste allein vertraut dem Netzwerk. Ein TSIG-Schlüssel beweist, dass die Anfrage von Ihrem Secondary kommt.

# on the primary
pdnsutil generate-tsig-key xfr hmac-sha256
pdnsutil activate-tsig-key example.com xfr primary
pdnsutil list-tsig-keys      # copy the secret

# on each secondary (pdns.conf contains: secondary=yes)
pdnsutil import-tsig-key xfr hmac-sha256 '<secret>'
pdnsutil create-secondary-zone example.com 203.0.113.10
pdnsutil activate-tsig-key example.com xfr secondary

Dabei ist 203.0.113.10 die private Adresse des Primary. Damit Sie nicht jede Zone auf jedem Secondary von Hand anlegen müssen, kann PowerDNS sie automatisch erzeugen, wenn der Primary ein NOTIFY für eine neue Zone sendet. Richten Sie den Primary auf jedem Secondary als Autoprimary ein:

pdnsutil add-autoprimary 203.0.113.10 ns1.example.net

und setzen Sie autosecondary=yes auf den Secondaries.

Option zwei: native Zonen und Datenbankreplikation

PowerDNS kann DNS-Transfers auch ganz überspringen. Markieren Sie Zonen als NATIVE, halten Sie sie in einem MySQL-, MariaDB- oder PostgreSQL-Backend und lassen Sie die Datenbank die Daten des Primary auf eine schreibgeschützte Replik auf jedem Secondary replizieren.

pdnsutil set-kind example.com native

Auf jedem Secondary liest PowerDNS aus seiner lokalen Replik-Datenbank, schreibgeschützt konfiguriert. Die Replikation läuft ausschließlich über das private Netzwerk.

Warum man das wählt:

• Jede Änderung kommt als Zeile an, sobald die Datenbank sie verschickt. Es gibt keine Seriennummer, deren Erhöhung man vergessen, und kein NOTIFY, das man verlieren könnte.
• AXFR kann überall abgeschaltet werden, es gibt also gar keine Transferschnittstelle zu schützen.
• Neue Zonen erscheinen auf den Secondaries automatisch, weil auch sie Zeilen sind.
• DNSSEC-Schlüssel replizieren zusammen mit den Einträgen, und jeder Secondary signiert die Antworten selbst.

Warum nicht: Jeder Secondary muss dasselbe Backend betreiben, und Sie betreiben nun Datenbankreplikation, die ihr eigenes Monitoring für Verzögerung und abgerissene Threads braucht. Wenn Ihre Secondaries das DNS eines anderen Herstellers einschließen, sind Transfers die einzige Option.

Wir bauen unsere mit nativen Zonen und Datenbankreplikation, weil das die Transferfläche vollständig entfernt und die Datenbank zur einen, offensichtlichen Quelle der Wahrheit macht.

DNSSEC mit einem Hidden Primary

Beide Optionen unterstützen das Signieren:

• Mit Transfers signieren Sie auf dem Primary. Die Secondaries erhalten die signierte Zone und liefern sie als vorsignierte Daten aus. PowerDNS markiert die Zone automatisch als PRESIGNED, wenn es signierte Einträge überträgt.
• Mit Datenbankreplikation liegen die Schlüssel in der Datenbank, also signiert jeder Secondary live mit denselben Schlüsseln und antwortet identisch.

Testen Sie die Validierung in jedem Fall von außen mit einem validierenden Resolver:

dig +dnssec example.com SOA @1.1.1.1
delv example.com SOA

delv sollte «fully validated» melden.

Nennen Sie die richtigen Server

Der Sinn eines Hidden Primary geht verloren, wenn sein Name in die Einträge sickert, die die Welt liest.

• Die NS-Einträge nennen nur die öffentlichen Secondaries.
• Das Feld SOA MNAME nennt einen öffentlichen Secondary, nicht den Primary. In PowerDNS setzt default-soa-content es für neue Zonen. Bestehende korrigieren Sie mit pdnsutil edit-zone.
• Das Glue bei der Registry zeigt nur auf die öffentlichen Adressen der Secondaries.

Manche Werkzeuge tragen standardmäßig den eigenen Servernamen in das SOA MNAME ein. Prüfen Sie es bei jeder Zone, nicht nur bei der ersten.

Sichern Sie jede Rolle ab

• Stellen Sie vor jeden öffentlichen Secondary ein DNS-bewusstes Frontend wie dnsdist, um Anfragetypen abzulehnen, die Amplification ermöglichen, die Rate zu begrenzen und Anfragen für Zonen zu verwerfen, die Sie nicht ausliefern.
• Lehnen Sie auf den Secondaries NOTIFY von überall außer vom Primary ab, und lehnen Sie AXFR-Anfragen aus dem Internet ab.

Prüfen Sie es von außen

# NS and SOA name only public secondaries
dig +short NS example.com
dig +short SOA example.com

# Every secondary has the same serial
for ns in $(dig +short NS example.com); do
  printf '%s ' "$ns"; dig +short SOA example.com @"$ns" | awk '{print $3}'
done

# Transfers are refused from the internet
dig AXFR example.com @ns1.example.net

# The primary does not answer from outside (expect a timeout)
dig example.com SOA @<primary-address> +time=2 +tries=1

Führen Sie den Vergleich der Seriennummern dauerhaft aus, nicht einmalig. Ein Secondary, der keine Aktualisierungen mehr erhält, antwortet weiterhin selbstbewusst mit alten Daten. Das einzige Symptom ist eine Seriennummer, die zurückbleibt. Alarmieren Sie darauf, und alarmieren Sie, wenn Name oder Adresse des Primary je in einem NS- oder SOA-Eintrag auftauchen.

Kurz gefasst

Der Primary ist, wo Sie bearbeiten, die Secondaries sind, wo die Welt fragt, und die beiden begegnen sich nur in einem privaten Netzwerk. Wählen Sie Transfers, wenn Sie DNS-Hersteller mischen, Datenbankreplikation, wenn Sie gar keine Transferfläche wollen. Nennen Sie nur die Secondaries, signieren Sie die Zone, und behalten Sie die Seriennummern im Blick.

Wir bauen und betreiben PowerDNS-Cluster auf diese Weise für Kunden, die ihr DNS selbst besitzen wollen. Wenn Sie eines planen, helfen wir gern.

CTA

Mit einem Ingenieur sprechen

Related

Verwandt: Autoritatives und rekursives DNS auf PowerDNS · Autoritatives DNS und Reverse DNS, betrieben als Infrastruktur