Ich richte derzeit einen DNS-Server für mein Heimlabor ein. Ich habe eine Zonendatei erstellt, die der Domäne des Labors entspricht, sagen wir home.lab, und der Server weiß nun, dass er der autoritative Server für diese Zone ist, und kann nun auf Anfragen zu antworten device.home.lab.
Jetzt möchte ich diesen DNS-Server auf meinen anderen Geräten verwenden, damit er die Autorität in der home.labZone ist, aber ich brauche sie auch, damit sie weiterhin globale Internetdomänen auflösen können. Es scheint, dass es keine Möglichkeit gibt, die Endhosts so einzurichten, dass sie ihn nur für Suchvorgänge und einen anderen Server für andere Zwecke verwenden home.lab. Bisher sehe ich einige Lösungen:
- diesen Server so einrichten, dass er auch andere Zonen rekursiv auflöst (was funktionieren würde, wie beschriebenin dieser Frage)
- Wenn der Server nach einer anderen Zone als der eigenen gefragt wird, antwortet er mit einem Verweis auf die Stammserver. Von dort aus fragen die Clients dann rekursiv selbst die Hierarchie ab.
- Richten Sie einen weiteren DNS-Server ein, der auf Anfrage
home.labdie Antwort des autoritativen DNS-Servers weiterleitet, andernfalls die zwischengespeicherte Antwort
Die erste Option scheint schlecht, da der autoritative Server dann auch die Doppelfunktion eines rekursiven Resolvers für die übrigen Domänen übernimmt. Die zweite ist ineffizient, da die Clients dann für jede neue Domäne die Hierarchie manuell auflösen müssen, was ziemlich langsam sein kann.
Daher scheint die dritte Option bisher die beste zu sein. Wie würde ich dies in BIND9 einrichten und/oder sollte ich eine alternative Lösung in Betracht ziehen?
Antwort1
Die erste Option scheint schlecht zu sein, da der autoritative Server dann auch eine Doppelfunktion als rekursiver Resolver für die übrigen Domänen hat.
Für den Einsatz in einem kleinen LAN bzw. im Heimlabor ist das kein wirkliches Problem.
(Dies wird auch häufig in Active Directory-Umgebungen durchgeführt, in denen der Administrator alle Clients anweist, direkt einen AD DC zu verwenden, der die AD DNS-Zone hostet, anstatt einen dedizierten Resolver – das istunnötig,aber nicht unbedingt schlecht.)
Es mag einige Randfälle geben (z. B. das DNSSEC AD-Flag), aber ich glaube, sie resultieren ausnichtvom Hinzufügen von Resolver-Funktionen zu einem autoritativen Server, sondern vom Gegenteil – indem die Maschinen einen autoritativen Server verwenden, als wäre er ein Resolver, was Siebereitstun.
Die zweite Methode ist ineffizient, da die Clients dann für jede neue Domäne die Hierarchie manuell auflösen müssen, was ziemlich langsam sein kann.
Es würde auch nicht funktionieren, da die meisten Kunden nurStummelResolver – sie folgen Empfehlungen nicht.
Ein vollständiger Resolver hingegen wirdZwischenspeicherVerweise. Der öffentliche DNS-Resolver, den Sie verwenden (sei es der des ISPs oder von Google oder ein anderer), muss die Hierarchie für jede neue Domain ebenfalls auflösen – er speichert sicherlich keine vollständige Kopie aller DNS-Einträge der Welt –, ist aber dennoch nicht langsam, da zumindest die erste Ebene (TLDs) normalerweise im Speicher zwischengespeichert wird und es für eine typische Domain ohnehin nicht so viele Hierarchieebenen gibt.
Daher scheint die dritte Option bisher die beste zu sein. Wie würde ich dies in BIND9 einrichten und/oder sollte ich eine alternative Lösung in Betracht ziehen?
Erstellen Sie in BIND9 eine type static-stubZone, die auf den Homelab-Authentifizierungsserver verweist. (Sie ähnelt einer type forwardZone, aber „static-stub“ erwartet, direkt auf einen autoritativen Server zu verweisen, während „forward“ erwartet, an einen anderen Resolver zu ketten. Ich bin mir über die genauen Unterschiede nicht im Klaren.)
Für alle anderen Domänen können Sie Upstream-Server angeben, wie forwarders{}in der globalen BIND-Konfiguration. Dies ist nicht erforderlich – BIND9 selbst ist in der Lage, Verweise von Root-DNS-Servern aus zu verfolgen (und tut dies standardmäßig, solange die Pseudozone „Root Hints“ konfiguriert ist), was wirklichist nichtlangsam (könnte aber sicherlich langsamer sein als die Weiterleitung von Anfragen an einen Upstream-Server mit einem eigenen riesigen Cache).
Eine häufige Alternative ist Unbound (das sich mehr auf die Verwendung als Resolver konzentriert und nur minimale autoritative Serverfunktionen bietet). Die Konfiguration von Unbound ist ähnlich, außer dass der Zonentyp stub„static-stub“ ist. Um Unbound-Weiterleitungsabfragen durchzuführen, konfigurieren Sie es "."als Zone vom Typ „forward“.
Bedenken Sie, dass die Erfindung benutzerdefinierter TLDs nicht gut mit der DNSSEC-Validierung funktioniert, da die Root-Zone NSEC-Einträge hat, die die Nichtexistenz beweisen. lab.Daher müssen Sie Ihre Domain möglicherweise explizit von der Validierung ausschließen, sowohl im LAN-Resolver als auch manchmal in den Hosts selbst. Nur die home.arpa.Domain ist für diese Art der Nutzung reserviert (mit absichtlich unsignierten NS-Einträgen).
(Alternativ könnten SieaktivierenDNSSEC, signieren Sie Ihre interne Zone und geben Sie einen benutzerdefinierten „Vertrauensanker“ für alle validierenden Resolver an. Obwohl DNSSEC in einem Heimlabor nicht wirklich erforderlich ist, besteht der Vorteil hier darin, dass das Hinzufügen eines Vertrauensankers möglicherweise einfacher ist als das Hinzufügen einer Ausnahme, insbesondere in BIND.)