PTR Record wird nicht erstellt
Mahlzeit,
ich habe hier einen Server2012R2 DC bei dem die Clients keinen Eintrag in der Reverse Zone erstellen.
DHCP macht eine Sophos UTM. Die verteilt dort aber den Windows DNS. Der eigene DNS der Sophos wird nicht verwendet.
Nun habe ich hier eine Reverse lookup Zone mit 192.168. passt. Dort registrieren sich auch alle Clients die am gleichen Standort sind problemlos. Vorwärts wie rückwärts.
Meine beiden Aussenstandorte jedoch nicht. Und zwar gibts für die unterhalb von 192.168. noch Sub-Zonen mit .50 und .40. Die sind aber "grau" und leer.
Als DHCP läuft vor Ort jeweils eine Sophos RED. Ich habe auch eine Netzwerk GPO gebaut, die den Clients sagt, sie sollen einen PTR Record registrieren. Keine Änderung.
Wie ist hier eigentlich die richtige Vorgehensweise? Soll ich mal die Sub Zonen löschen (sind ja eh leer) und parallel zur 192.168.er die 192.168.50 und 40 anlegen? Ein Nslookup auf die IP von Clients am Standort findet die Clients nicht. Forward klappt aber. Oder sollte ich mal als DNS die Sophos nehmen? Ein Forwarding ist eingerichtet, aber so richtig traue ich mich nicht im produktiv Betrieb
LG
Ex0r
ich habe hier einen Server2012R2 DC bei dem die Clients keinen Eintrag in der Reverse Zone erstellen.
DHCP macht eine Sophos UTM. Die verteilt dort aber den Windows DNS. Der eigene DNS der Sophos wird nicht verwendet.
Nun habe ich hier eine Reverse lookup Zone mit 192.168. passt. Dort registrieren sich auch alle Clients die am gleichen Standort sind problemlos. Vorwärts wie rückwärts.
Meine beiden Aussenstandorte jedoch nicht. Und zwar gibts für die unterhalb von 192.168. noch Sub-Zonen mit .50 und .40. Die sind aber "grau" und leer.
Als DHCP läuft vor Ort jeweils eine Sophos RED. Ich habe auch eine Netzwerk GPO gebaut, die den Clients sagt, sie sollen einen PTR Record registrieren. Keine Änderung.
Wie ist hier eigentlich die richtige Vorgehensweise? Soll ich mal die Sub Zonen löschen (sind ja eh leer) und parallel zur 192.168.er die 192.168.50 und 40 anlegen? Ein Nslookup auf die IP von Clients am Standort findet die Clients nicht. Forward klappt aber. Oder sollte ich mal als DNS die Sophos nehmen? Ein Forwarding ist eingerichtet, aber so richtig traue ich mich nicht im produktiv Betrieb
LG
Ex0r
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665074
Url: https://administrator.de/forum/ptr-record-wird-nicht-erstellt-665074.html
Ausgedruckt am: 25.12.2024 um 14:12 Uhr
29 Kommentare
Neuester Kommentar
Hi,
also "Sub-Zonen" gibt es nicht.
Wenn Du ne Zone für "192.168." hast, dann landen dort ggf. alle PTR für DNS Clients aus Netzen mit "192.168." am Anfang.
Wenn man in dieser Zone dann graue "Unterordner" sieht, dann sind das Delegierungen auf andere Zonen. Du müsstest demnach Zonen haben, die da lauten "50.168.192.in-addr.arpa" und "40.168.192.in-addr.arpa". Auf welchen DNS-Servern diese Zonen sind (sein sollen) siehts Du an den IP-Adressen, welche in den Delegierungen angegeben sind.
In diesen Zonen siehst Du die ggf. zugehörigen PTR-Records, nicht in den grauen "Unterordnern" der Zone "168.192.in-addr.arpa".
E.
also "Sub-Zonen" gibt es nicht.
Wenn Du ne Zone für "192.168." hast, dann landen dort ggf. alle PTR für DNS Clients aus Netzen mit "192.168." am Anfang.
Wenn man in dieser Zone dann graue "Unterordner" sieht, dann sind das Delegierungen auf andere Zonen. Du müsstest demnach Zonen haben, die da lauten "50.168.192.in-addr.arpa" und "40.168.192.in-addr.arpa". Auf welchen DNS-Servern diese Zonen sind (sein sollen) siehts Du an den IP-Adressen, welche in den Delegierungen angegeben sind.
In diesen Zonen siehst Du die ggf. zugehörigen PTR-Records, nicht in den grauen "Unterordnern" der Zone "168.192.in-addr.arpa".
E.
ahh! Das machts klarer. Danke. Bei den Delegierungen steht nur unser primärer DC sind. Ich lösch die einfach mal und schaue was passiert. Die 50er und 40er müssten ja dann in 168.192.in-addr.arpa landen. Korrekt?
Hast Du diese Zonen nun oder nicht? ("40.168.192.in-addr.arpa", "50.168.192.in-addr.arpa")Nur, wenn Du diese nicht hast, dann die Delegierungen löschen. Oder diese Zonen eben erstellen.
Nein! Meinen Text lesen! Was ist daran nicht zu verstehen?
Zumal der DNS-Dienst diese Delegierungen automatisch wieder erstellen sollte, wenn er selbst auch diese beiden Zonen bereitstellt.
Zumal der DNS-Dienst diese Delegierungen automatisch wieder erstellen sollte, wenn er selbst auch diese beiden Zonen bereitstellt.
Also halten wir fest:
Du hast auf diesem DNS-Server jetzt 3 Zonen:
- 40.168.192.in-addr.arpa
- 50.168.192.in-addr.arpa
- 168.192.in-addr.arpa
Und in der Zone "168.192.in-addr.arpa" hast Du je eine Delegierung für "40" und "50" mit Ziel auf diesen DNS selbst?
Und trotzdem erstellen die Clients die PTR nicht?
Sind für diese Zonen dynamische Updates erlaubt? Wenn ja, mit welcher Einstellung?
Du hast auf diesem DNS-Server jetzt 3 Zonen:
- 40.168.192.in-addr.arpa
- 50.168.192.in-addr.arpa
- 168.192.in-addr.arpa
Und in der Zone "168.192.in-addr.arpa" hast Du je eine Delegierung für "40" und "50" mit Ziel auf diesen DNS selbst?
Und trotzdem erstellen die Clients die PTR nicht?
Sind für diese Zonen dynamische Updates erlaubt? Wenn ja, mit welcher Einstellung?
Dynamische Updates stehen auf "nur Sichere".
Dan könne sich auch nur Domain Member dort eintragen. Nicht z.B. Drucker und sowas, welche nicht am AD angemeldet sind.Soll bei der Delegierung für 40 & 50 jeweils nur der localhost DC mit FQDN eingetragen sein? Dann ja.
Auf dem sekundären DC ist der Haupt DC eingetragen.
Dann sind diese Zonen also AD-integriert und werden auf beide DC repliziert? Falls ja, dann kann bei den Delegierungen auch auf beide DC/DNS verwiesen werden.Auf dem sekundären DC ist der Haupt DC eingetragen.
Welchen DNS-Server bekommen denn die Clients aus den 40'- und 50'-Netzen zugewiesen?
Zitat von @Ex0r2k16:
Die kriegen als primären den 192.168.0.2 und sekundär 192.168.0.7. Historisch so gewachsen.
Und das sind diese beiden DC/DNS? Sorry, dass ich heute nicht so hell sehen kann.Die kriegen als primären den 192.168.0.2 und sekundär 192.168.0.7. Historisch so gewachsen.
Hallo,
der Rechner trägt seine IP ein. Der DHCP-Server trägt die reverse IP ein und das kann deine Firewall halt nicht.
Du kannst das Verhalten via GPO dahingehend anpassen, dass der Rechner beides einträgt.
https://www.altmetaller.de/quickie-reverse-dns-eintraege-mit-separaten-s ...
Gruß,
Jörg
der Rechner trägt seine IP ein. Der DHCP-Server trägt die reverse IP ein und das kann deine Firewall halt nicht.
Du kannst das Verhalten via GPO dahingehend anpassen, dass der Rechner beides einträgt.
https://www.altmetaller.de/quickie-reverse-dns-eintraege-mit-separaten-s ...
Gruß,
Jörg
Hallo,
...dann solltest Du eruieren, warum die GPO nicht greift
Ich gehe mal davon aus, dass die Rechner in einer Domäne sind. Ansonsten würde ich mal schauen, ob es da irgendwo Zugriffsrechte o.Ä. gibt und die Rechner deshalb nichts "abseits der Norm" ins DNS schreiben können / dürfen.
Gruß,
Jörg
Zitat von @Ex0r2k16:
Siehe meinen Eingangspost:
Siehe meinen Eingangspost:
Ich habe auch eine Netzwerk GPO gebaut, die den Clients sagt, sie sollen einen PTR Record registrieren. Keine Änderung.
...dann solltest Du eruieren, warum die GPO nicht greift
Ich gehe mal davon aus, dass die Rechner in einer Domäne sind. Ansonsten würde ich mal schauen, ob es da irgendwo Zugriffsrechte o.Ä. gibt und die Rechner deshalb nichts "abseits der Norm" ins DNS schreiben können / dürfen.
Gruß,
Jörg
Wenn Du einen Client hast, der die GPO angewendet hat, dass er auch seinen PTR aktualisieren soll. Dann führe auf diesem Client ein
ipconfig /registerdns
aus und schaue unmittelbar danach ins Debug-Log des DNS-Servers, welchen der Client als 1. DNS Server eingetragen hat, ob dort ein Update-Kommando angekommen ist, und wenn ja, wie dieses beantwortet wurde.
ipconfig /registerdns
aus und schaue unmittelbar danach ins Debug-Log des DNS-Servers, welchen der Client als 1. DNS Server eingetragen hat, ob dort ein Update-Kommando angekommen ist, und wenn ja, wie dieses beantwortet wurde.
Hallo,
ich gehe vom Standardfall aus, bei der ein DC mir DNS / DHCP ohne weitere tiefgreifende Konfiguration aufgesetzt wird und ein Rechner die Domain joint.
Gruß,
Jörg
ich gehe vom Standardfall aus, bei der ein DC mir DNS / DHCP ohne weitere tiefgreifende Konfiguration aufgesetzt wird und ein Rechner die Domain joint.
Gruß,
Jörg
Hallo,
das war eine Antwort auf emeriks Einwand mit dem „kann“
Gruß,
Jörg
das war eine Antwort auf emeriks Einwand mit dem „kann“
Gruß,
Jörg