Kapitel 4. Zonendaten verwalten
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Bei traditionellen DNS-Servern wie BIND verwalten die Administratoren die Daten der primären Zone normalerweise als Dateien. In jüngerer Zeit haben DNS-Server begonnen, das Laden von Primärzonendaten aus anderen Quellen, wie z. B. Datenbanken, zu unterstützen.
CoreDNS unterstützt eine Vielzahl von Methoden zur Verwaltung von Zonendaten. Einige werden DNS-Administratoren sehr vertraut sein, wie z. B. Zonendateien; andere sind moderner, wie z. B. die Verwendung von Git, während einige geradezu retro sind (Host-Tabellen, jemand?). In diesem Kapitel gehen wir auf alle diese Methoden ein.
Zusammen bieten diese Optionen den Administratoren Flexibilität und in einigen Fällen auch erweiterte Funktionen für die Verwaltung der Zonendaten. Host-Tabellen bieten zum Beispiel eine einfache Möglichkeit, Zuordnungen von Namen zu Adressen und Adressen zu Namen hinzuzufügen, ohne dass eine ganze Zonendatei erstellt und gepflegt werden muss. Git hingegen bietet Funktionen zur verteilten Versionskontrolle.
Beginnen wir mit dem file Plug-in, das Zonendateien unterstützt. Das haben wir bereits in Kapitel 3 behandelt, aber hier gehen wir es noch einmal genauer durch.
Die Datei Plug-in
Für einen Administrator, der Erfahrung mit der Verwaltung von Zonendateien hat, ist das file Plug-in wahrscheinlich der bekannteste Mechanismus, den CoreDNS bietet. file konfiguriert CoreDNS als primären DNS-Server für eine oder mehrere Zonen. In seiner einfachsten Form hat das file Plug-in die in Beispiel 4-1 gezeigte Syntax.
Beispiel 4-1. Einfache Datei-Plugin-Syntax
file DBFILE [ZONES...]
DBFILE ist eine Zonendatei, die Ressourcendatensätze enthält. Du kannst DBFILE als vollständigen Pfadnamen oder als relativen Pfadnamen angeben; relative Pfadnamen werden relativ zu einem mit der Direktive root festgelegten Pfad interpretiert.
ZONES ist eine optionale Liste von einer oder mehreren Zonen, die durch die Ressourcendatensätze in DBFILE beschrieben werden. Wenn ZONES weggelassen wird, verwendet CoreDNS die Zonen aus dem Konfigurationsblock.
Beispiel 4-2 zeigt ein einfaches Beispiel für ein file Plug-in, und Beispiel 4-3 zeigt die Zonendatendatei, auf die es sich bezieht.
Beispiel 4-2. Einfaches Beispiel für ein Datei-Plug-in
foo.example {
file db.foo.example
}
Beispiel 4-3. db.foo.example
@ 3600 IN SOA ns1.foo.example. root.foo.example. ( 2019041900 3600 600 604800 600 ) 3600 IN NS ns1.foo.example. 3600 IN NS ns2.foo.example. ns1 IN A 10.0.0.53 IN AAAA 2001:db8:42:1::53 ns2 IN A 10.0.1.53 IN AAAA 2001:db8:42:2::53 www IN A 10.0.0.1 IN AAAA 2001:db8:42:1:1
Da die Ressourcendatensätze in der Zonendatei db.foo.example alle an relative Domainnamen angehängt sind (z. B. ns1 und www und nicht an vollqualifizierte Domainnamen mit Punkt-Endung), kann die Datei geladen werden, um mehrere Zonen zu beschreiben, wie in Beispiel 4-4 gezeigt.
Beispiel 4-4. Verwendung einer einzelnen Zonendatei für mehrere Zonen
. {
file db.foo.example foo.example bar.example
}
Das setzt natürlich voraus, dass die Inhalte von foo.example und bar.example identisch sein sollen - zum Beispiel, dass sowohl www.foo.example als auch www.bar.example auf die IPv4-Adresse 10.0.0.1 abgebildet werden sollen.
Das file Plug-in unterstützt auch eine umfangreichere Syntax, mit der du festlegen kannst, welche DNS-Server die Zone(n) übertragen dürfen und wie oft die Zonendatendatei auf Änderungen überprüft werden soll, wie in Beispiel 4-5 gezeigt.
Beispiel 4-5. Ausführlichere Syntax des Datei-Plug-ins
file DBFILE [ZONES... ] {
transfer to ADDRESS...
reload DURATION
upstream [ADDRESS...]
}
Ohne die Direktive transfer lässt CoreDNS keine Zonentransfers der Zone(n) zu, die durch das Plug-in file beschrieben werden. Um NOTIFY Nachrichten an einen bestimmten sekundären DNS-Server zu senden und um Zonentransfers zu diesem sekundären Server zuzulassen, musst du die IP-Adresse des sekundären Servers angeben. Für mehrere sekundäre Server kannst du ihre IP-Adressen in einer einzigen transfer Direktive auflisten oder mehrere Direktiven verwenden. Du kannst auch ein Netzwerk in der Classless Inter-Domain Routing (CIDR)-Notation angeben, um Zonentransfers von jeder IP-Adresse in diesem Netzwerk zuzulassen, oder *, um Zonentransfers von überall her zuzulassen , wie in Beispiel 4-6 dargestellt.
Beispiel 4-6. Detailliertes Beispiel für das Datei-Plug-in
foo.example {
file db.foo.example {
transfer to 10.0.1.53
transfer to *
}
}
reload kannst du festlegen, wie oft CoreDNS die Zonendatendatei überprüft, um festzustellen, ob sich die Seriennummer im SOA-Eintrag (Start of Authority) geändert hat. Wenn CoreDNS eine neue Seriennummer feststellt, lädt er die Datei neu (als eine oder mehrere Zonen) und sendet NOTIFY-Nachrichten an die sekundären DNS-Server, die in den transfer Direktiven angegeben sind. Die Standardeinstellung reload ist eine Minute; die Einstellung 0 deaktiviert die periodische Überprüfung. Gültige Werte sind eine Zahl gefolgt von "s" für Sekunden, "m" für Minuten und "h" für Stunden; zum Beispiel 30s für 30 Sekunden.
Das file Plug-in ist gut, wenn du CoreDNS als primären DNS-Server für ein paar Zonen konfigurierst. Aber was ist, wenn du CoreDNS als primären Server für Hunderte von Zonen konfigurieren willst? In diesem Fall brauchst du das auto Plug-in.
Das Auto-Plug-in
Das auto Plug-in bietet eine clevere Möglichkeit, eine große Anzahl von Zonen aus mehreren Zonendateien auf einmal zu laden. Dies minimiert die Länge und Komplexität des Corefiles und bietet die Möglichkeit, CoreDNS automatisch als primäre Datei für neue Zonen zu konfigurieren. Beispiel 4-7 zeigt die Syntax.
Beispiel 4-7. Syntax des Auto-Plug-ins
auto [ZONES...] {
directory DIR [REGEXP ORIGIN_TEMPLATE]
transfer to ADDRESS...
reload DURATION
}
auto weist CoreDNS an, das Verzeichnis nach Dateien zu durchsuchen, die dem Muster db.* entsprechen. Jede Datei wird als Zonendatei interpretiert, deren Ursprung auf db. folgt. Dieser Ursprung muss innerhalb der Zone(n) liegen, die in ZONES aufgeführt sind, falls angegeben.
Angenommen, das Verzeichnis /etc/coredns/zones enthält die Zonendateien db.foo.example und db.bar.example, die die Zonen foo.example bzw. bar.example beschreiben. Das in Beispiel 4-8 gezeigte auto Plug-in würde CoreDNS anweisen, das gesamte Verzeichnis zu lesen und die Zonen foo.example und bar.example aus diesen Dateien zu laden.
Beispiel 4-8. Ein Auto-Plug-in
auto example {
directory /etc/coredns/zones
}
Außerdem kannst du eine weitere Zone (jedenfalls unter der Beispieldomäne ) erstellen, indem du einfach eine neue Zonendatei mit dem Namen in /etc/coredns/zones anlegst.
Du kannst neben db.* auch einen regulären Ausdruck angeben, nach dem CoreDNS in dem Verzeichnis suchen soll, und CoreDNS Anweisungen geben, wie es den Ursprung (und den Domänennamen der Zone) aus dem Dateinamen erstellen soll. Wenn du zum Beispiel deine Zonendateien <Domäne>.zone nennst, könntest du das in Beispiel 4-9 vorgestellte Plug-in auto verwenden.
Beispiel 4-9. Ein weiteres Auto-Plug-in
auto example {
directory /etc/coredns/zones (.*)\.zone {1}
}
Es wird erwartet, dass der reguläre Ausdruck (regex) im Wesentlichen eine Perl-Erfassungsgruppe enthält: Die Klammern um ".*" geben den Teil des Dateinamens an, der den Ursprung enthält (in diesem Fall alles vor .zone); {1} ist ein Rückverweis auf diesen Teil des regex. Du kannst natürlich auch andere Rückverweise verwenden, wie z. B. {2} für die zweite Fanggruppe.
Schließlich kannst du mit den Direktiven file transfer , reload und upstream steuern, welche DNS-Server Zonentransfers dieser Zonen durchführen können (und NOTIFY-Nachrichten von CoreDNS erhalten), wie oft das Verzeichnis auf geänderte Zonendatendateien gescannt wird und welche DNS-Server für die Auflösung externer Domainnamen verwendet werden sollen.
Verwendung des Auto-Plug-ins mit Git
Eifrige Nutzer des verteilten Versionskontrollsystems Git können das Plug-in auto einfach mit einem Skript wie git-sync kombinieren, um regelmäßig Zonendaten-Dateien aus einem Git-Repository in ein Verzeichnis zu ziehen. CoreDNS scannt dann das Verzeichnis und lädt neue und geänderte Zonen. Mit Git können mehrere Administratoren gemeinsam eine Reihe von versionskontrollierten Zonendateien verwalten, so dass die Administratoren Änderungen an den Zonendaten verfolgen können.
git-sync ist, wenig überraschend, als Container implementiert. Hier ein Beispiel für die Verwendung von git-sync, um ein GitHub-Repository regelmäßig nach neuen Zonendaten-Dateien zu durchsuchen, wie in Beispiel 4-10 gezeigt.
Beispiel 4-10. git-sync in Aktion
docker run -d \ -v /etc/coredns/zone:/tmp/git \ registry/git-sync \ --repo=https://github.com/myzonedata --branch=master --wait=30
Dieser Befehl verwendet den Container git-sync, um Dateien aus dem Repository https://github.com/myzonedata nach /etc/coredns/zone zu synchronisieren und das Repository alle 30 Sekunden auf Änderungen zu überprüfen.
Was, wenn du das gegenteilige Problem hast, das auto löst - nämlich, dass du nur ein paar Ressourcendatensätze in CoreDNS laden willst, ohne den Overhead einer Zonendatei. In diesem Fall ist das hosts Plug-in sehr nützlich.
Das Hosts Plug-in
Das hosts Plug-in wird verwendet, um CoreDNS so zu konfigurieren, dass es Zonendaten aus einer Host-Tabelle (z. B. /etc/hosts) generiert. Die Host-Tabelle muss im Standard-Host-Tabellenformat vorliegen:
<IP address> <canonical name> [aliases...]
Die IP-Adresse kann entweder eine IPv4- oder eine IPv6-Adresse sein. Der kanonische Name und alle Aliasnamen müssen Domänennamen sein. Nachdem die Host-Tabelle gelesen wurde, erzeugt hosts Folgendes:
- Ein Datensatz für jeden Eintrag mit einer IPv4-Adresse, der den kanonischen Namen und alle Aliase auf die angegebene IPv4-Adresse abbildet
- AAAA-Einträge für jeden Eintrag mit einer IPv6-Adresse, die den kanonischen Namen und alle Aliase der angegebenen IPv6-Adresse zuordnen
- Ein PTR-Eintrag für eine IPv4- oder IPv6-Adresse, der die Adresse dem kanonischen Namen zuordnet
Beachte, dass die Aliase zu A- oder AAAA-Datensätzen werden, nicht zu CNAME-Datensätzen (kanonischer Name).
Beispiel 4-11 zeigt die Syntax des hosts Plug-ins.
Beispiel 4-11. Syntax des hosts-Plug-ins
hosts [FILE [ZONES...]] {
[INLINE]
ttl SECONDS
no_reverse
reload DURATION
fallthrough [ZONES...]
}
FILE gibt den Namen der Hosts-Datei an, die gelesen und ausgewertet werden soll; standardmäßig liest CoreDNS /etc/hosts. Wenn FILE ein relativer Pfadname ist, wird er relativ zu dem in der Direktive ROOT angegebenen Verzeichnis interpretiert.
ZONES ist eine optionale Liste mit einer oder mehreren Zonen, die aus der Host-Tabelle geladen werden. Wenn ZONES nicht angegeben ist, verwendet CoreDNS die Zonen aus dem umschließenden Serverblock. Die Domänennamen werden nur in die Zonen geladen, zu denen sie gehören. Wenn du also die Hosttabelle aus Beispiel 4-12 sowohl als foo.example als auch als bar.example lädst, wird host1.foo.example in die Zone foo.example und host2.bar.example in bar.example geladen.
Beispiel 4-12. Beispiel Host-Tabelle
10.0.0.1 host1.foo.example 10.0.1.1 host2.bar.example
Zonen, deren Daten mit dem hosts Plug-in gelesen werden, sind nicht wirklich vollständige Zonen; sie haben zum Beispiel keine SOA-Einträge und können daher nicht auf einen anderen DNS-Server übertragen werden. Daher wird hosts normalerweise nicht für die Verwaltung einer ganzen Zone verwendet, sondern eher für das Laden einzelner Domainnamen. Manche Leute laden zum Beispiel eine Host-Tabelle, die Domainnamen enthält, die für die Schaltung von Werbung verwendet werden, und die diese Domainnamen der IP-Adresse 0.0.0.0 zuordnet.
[INLINE] ermöglicht es dir, eine oder mehrere Zeilen im Host-Tabellenformat direkt in der Direktive anzugeben, wie in Beispiel 4-13 zeigt.
Beispiel 4-13. Inline-Host-Tabelleneinträge
foo.example {
hosts {
10.0.0.1 host1.foo.example
10.0.1.1 host2.foo.example
}
}
TTL legt den TTL-Wert (Time-to-live) für Datensätze fest, die aus Host-Tabelleneinträgen synthetisiert werden; standardmäßig ist die TTL auf 3600 Sekunden oder 1 Stunde eingestellt. Der Wert muss als Ganzzahl angegeben werden (also keine Einheiten wie "s" für Sekunden angeben).
no_reverse verhindert die Erstellung von PTR-Einträgen aus Host-Tabelleneinträgen.
Standardmäßig lädt CoreDNS die Host-Tabelle alle 5 Sekunden neu. Unter reload kannst du dieses Intervall ändern, indem du einen skalierten Wert (d.h. eine Zahl gefolgt von einer Zeiteinheit) mit den folgenden Einheiten angibst :
- ns für Nanosekunden
- us oder µs für Mikrosekunden
- ms für Millisekunden
- s für Sekunden
- m für Minuten
- h für Stunden
Ich bin mir nicht sicher, ob du wirklich die Möglichkeit brauchst, ein Nachladeintervall von 500.000.000 Nanosekunden (mit 500000000 ns) festzulegen, aber mit CoreDNS kannst du das!
Schließlich steuert fallthrough, ob Abfragen für die Zonen, die vom hosts Plug-in bearbeitet werden, an ein anderes Plug-in weitergeleitet werden, wenn keine Antwort gefunden wird. Du könntest zum Beispiel wollen, dass Abfragen nach foo.example vom hosts Plug-in an ein file Plug-in weitergeleitet werden, wenn die Antwort nicht in der Host-Tabelle gefunden wurde. Standardmäßig wird durch die Angabe von fallthrough wird CoreDNS angewiesen, alle Anfragen, die vom hosts Plug-in bearbeitet werden, zu bearbeiten. Wenn du nur für eine Teilmenge dieser Abfragen einen Fall-Through durchführen willst, kannst du eine Liste von Zonen als Argument angeben.
Als Nächstes schauen wir uns an, wie wir Zonendaten von Amazons Route 53 Service laden können.
Das route53 Plug-in
Viele Unternehmen nutzen den Amazon Route 53 Service, um autoritative DNS-Dienste aus der Amazon Web Services (AWS) Cloud bereitzustellen. CoreDNS bietet ein Plug-in, route53, mit dem es Zonendaten von Route 53 synchronisieren kann, ähnlich wie ein sekundärer DNS-Server Zonendaten von einem Master-DNS-Server übertragen würde. CoreDNS kann dann autoritativ auf Anfragen nach Domainnamen in der synchronisierten Zone antworten.
Beispiel 4-14. Syntax des route53 Plug-ins
route53 [ZONE:HOSTED_ZONE_ID...] {
[aws_access_key AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY]
upstream
credentials PROFILE [FILENAME]
fallthrough [ZONES...]
}
Um die Zone zu synchronisieren, muss CoreDNS den Domänennamen der Zone und eine spezielle "Hosted Zone ID" bereitstellen, die in AWS als verwendet wird, sowie Anmeldedaten, die CoreDNS bei Route 53 authentifizieren.1 Um die Zonen-ID zu erhalten, melde dich im AWS Dashboard an, gehe zum Route 53 Service und klicke dann auf "Hosted Zones". Daraufhin wird eine Zonentabelle angezeigt, die die Hosted Zone ID jeder Zone enthält.
Das route53 Plug-in erfordert, dass du den Domänennamen der Zone und die Hosted Zone ID in einem bestimmten (und besonders unflexiblen) Format angibst: den Domänennamen der Zone, abgeschlossen mit einem Punkt, gefolgt von einem Doppelpunkt, dann die Hosted Zone ID. Beispiel 4-15 veranschaulicht dieses Format.
Beispiel 4-15. Das route53 Plug-in
route53 foo.example.:Z3CDX6AOCUSMX3 {
fallthrough
}
Du kannst mehrere Zonen angeben, wenn du möchtest, dass CoreDNS sie alle über Route 53 synchronisiert.
Standardmäßig ermittelt CoreDNS die zu verwendenden AWS-Anmeldedaten aus Umgebungsvariablen oder einer AWS-Anmeldedatei. Du kannst dieses Verhalten außer Kraft setzen, indem du die Anmeldeinformationen direkt im route53 Plug-in angibst, wie in Beispiel 4-16 gezeigt.
Beispiel 4-16. route53-Plugin mit expliziten Anmeldedaten
route53 foo.example.:Z3CDX6AOCUSMX3 {
aws_access_key AKIAIMSX7F33X4MOVBZA SnA4XxFPx/BDEMbty3EKVze7Xi3DkQ5a8akRO9j9
}
Du kannst auch eine andere AWS-Anmeldedatei als die Standarddatei angeben, indem du die credentials Unterdirektive in Beispiel 4-17 angeben.
Beispiel 4-17. route53 Plug-in mit Anmeldedatei
route53 foo.example.:Z3CDX6AOCUSMX3 {
credentials default .awscredentials
}
defaultgibt in diesem Fall ein bestimmtes Profil in der Anmeldedatei an.
Wie hosts unterstützt das route53 Plug-in fallthrough andere Plug-ins für alle oder einen bestimmten Satz von Zonen, die von Route 53 synchronisiert werden. Und wie file unterstützt route53 die Angabe eines upstream DNS-Servers, um Verweise auf externe Domainnamen in den Zonendaten von Route 53 aufzulösen.
Das ist das letzte der Plug-ins für die Verwaltung von Zonendaten in CoreDNS. Wir hoffen, dass du unter den vier Optionen (fünf, wenn du das auto Plug-in mit Git verwendest) eine findest, die deinen Bedürfnissen entspricht.
Obwohl CoreDNS ein flexibler und leistungsfähiger primärer DNS-Server ist, liegt seine Stärke natürlich in der Unterstützung der DNS-basierten Dienstsuche. Das behandeln wir in Kapitel 5.
1 Die Hosted Zone ID identifiziert die Zone eindeutig gegenüber AWS. Der Domänenname der Zone allein reicht nicht immer aus, denn AWS hat möglicherweise Public Hosted Zones und Private Hosted Zones mit demselben Domänennamen.
Get CoreDNS lernen now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
