Erfordert dynamisches DNS separate Subdomänen?

Erfordert dynamisches DNS separate Subdomänen?

Ich habe einen funktionierenden DHCP/DNS-Server (ISC Bind 9.6, DHCP 3.1.1), der unter Debian läuft und dem ich DynamicDNS-Funktionalität hinzufügen möchte. Ich habe eine ziemlich einfache Frage: Erfordert (oder empfiehlt) DynamicDNS separate Subdomänen? Ich habe einige Tutorials gesehen, in denen die Clients, die ihre IP-Adressen und andere Netzwerkinformationen über DHCP beziehen, auf einer anderen Subdomäne liegen als die Server, die statisch konfiguriert sind (sowohl in Bezug auf IP als auch DNS). Beispiel: Alle Clients liegen auf ws.example.org und die Server auf example.org.

Derzeit befinden sich alle unsere Server und Clients in derselben Domäne (example.org), sind aber auf verschiedene Zonendateien verteilt (da wir mehrere Subnetze haben). Die Clients sind mit DHCP konfiguriert und die Server statisch. Wenn ich DynamicDNS für die Clients einrichten möchte, sollte ich dann eine separate Subdomäne verwenden? Was ist hier die beste Vorgehensweise (und warum wäre es eine schlechte Idee, es anders zu machen)?

Danke.

Antwort1

Nein, es ist technisch nicht erforderlich, eine separate Zone für dynamische Updates zu haben.

Ich denke, der größte Faktor bei der Verwendung von Subdomains für dynamisches DNS hat mit den Sicherheitsrichtlinien für die Aktualisierung der Zone zu tun. Meiner Meinung nach sind die Berechtigungen, die Sie in Bind festlegen können, nicht sehr flexibel, obwohl neuere Versionen etwas besser sind. Mit allow-update(Bind 8.*) werden Berechtigungen auf Zonenebene und nicht pro Datensatz angewendet. Client A könnte also den Datensatz für Ihren kritischen Server aktualisieren, wenn er eine IP-Adresse verwendet hätte, die zum Durchführen von Aktualisierungen autorisiert ist.

Wenn Sie also über Ihre dynamische DNS-Konfiguration entscheiden, müssen Sie entscheiden, ob Sie es für eine gute Idee halten, Ihren Arbeitsstationen die Möglichkeit zu geben, Aktualisierungsdatensätze für einige kritische Dienste zu ändern. Oder möchten Sie kritische Dienste in eine Zone ohne dynamische Aktualisierungen und andere Maschinen in die dynamischeren Zonen trennen?

Antwort2

Dynamisches DNS funktioniert nichtbraucheneine separate Subdomäne, aber das ist die einfachste (und beste) Möglichkeit, es einzurichten.

Wenn Sie DynamicDNS-Updates auf eine Subdomäne (ws.example.org) und ein Subnetz (beide ohne Server) beschränken, ist es ziemlich einfach, die Beschränkungen so einzurichten, dass nichts Schlimmes passieren kann. Im schlimmsten Fall wird eine Arbeitsstation als eine andere Arbeitsstation identifiziert.

Wenn Sie DynamicDNS-Updates in derselben Hauptdomäne einrichten, in der sich auch die Server befinden, müssen Sie darauf achten, Einschränkungen einzurichten, damit sich Arbeitsstationen nicht dynamisch selbst aktualisieren können, um beispielsweise www.example.org zu sein. Ich habe mir das schon lange nicht mehr angesehen, aber Sie benötigen möglicherweise eine separate ACL für jeden Server (oder jedes andere Gerät, für das Sie den Namen schützen möchten). Ähnliche Probleme gibt es bei Subnetzen.

verwandte Informationen