29
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665074
Url: https://administrator.de/contentid/665074
Ausgedruckt am: 24.11.2024 um 01:11 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.
Hi,
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?
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?
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.
ich habe die Delegierungen gelöscht und die Zonen erstellt. Passt das so ?
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.
Zitat von @emeriks:
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.
Ok verstanden. Er erstellt die aber augenscheinlich nicht. Jedenfalls hab ich ja jetzt die Zonen, aber neue Delegierungen seh ich nicht,
Dann erstelle diese Delegierungen doch neu.
und die Delegierung kommt in welche Zone? jeweils in 50 40 oder in die 192.168.?
/Update: Jetzt hat er Sie angelegt. Ich teste
/Update2: Nope. Nix
/Update: Jetzt hat er Sie angelegt. Ich teste
/Update2: Nope. Nix
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?
korrekt.
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.
Dynamische Updates stehen auf "nur Sichere".
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.
Dynamische Updates stehen auf "nur Sichere".
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 @emeriks:
jup genau. Ist ok so.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.
jup, werden repliziert. Ok verstanden.
Welchen DNS-Server bekommen denn die Clients aus den 40'- und 50'-Netzen zugewiesen?
Die kriegen als primären den 192.168.0.2 und sekundär 192.168.0.7. Historisch so gewachsen.
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.
jau. Keine Panik. Hab auch so Tage
Führe mal auf einem dieser Clients explizit aus:
Erscheint dann der Record auf einem der DC/DNS?
ipconfig /registerdnsZitat von @emeriks:
Führe mal auf einem dieser Clients explizit aus:
Erscheint dann der Record auf einem der DC/DNS?
Führe mal auf einem dieser Clients explizit aus:
> ipconfig /registerdns
> sorry schon probiert. Nope. Da kommt nix. Ich meine da ist zwar eine UTM dazwischen, aber der DNS Traffic läuft ja da durch. Von daher glaube ich nicht, dass die UTM dazwischen funkt. Dann hätten wir vermutlich ernstere Probleme. Aber ok. Ich checke nochmal die Firewall Logs.
Das Problem gibts übrigens schon seit Ewigkeiten. Habe aber jetzt erst ein wenig Zeit dafür.
Firewall sagt auch ok:
UDP
192.168.40.157 : 60992
→
192.168.0.2 : 53
/edit: Lege ich den Zeiger manuell in der Zone an, klappt die Auflösung sofort.
Man kann am DNS-Server ein Debug-Log aktivieren. Da sieht man dann, welche Anfragen von wo kommen und ob und wie diese beantwortet wurden. Da stehen dann auch Update-Anfragen drin, sofern diese da überhaupt ankommen.
Hier stand Mist. Ich durchsuche gerade die Logs nach dem Registerdns. Kann was dauern
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
Zitat von @117471:
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
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
Siehe meinen Eingangspost:
Ich habe auch eine Netzwerk GPO gebaut, die den Clients sagt, sie sollen einen PTR Record registrieren. Keine Änderung.
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
Siehe bild Wird angewendet. Ja alle Rechner sind in der Domäne.
Halten wir einfach mal feste, dass unser DHCP den PTR Record nicht erstellt - ok
Die GPO tut nicht das, was sie soll - nicht ok.
Ich gucke mal gleich nach den Zugriffsrechten der Zonen.
Wird angewendet. Ja alle Rechner sind in der Domäne.Halten wir einfach mal feste, dass unser DHCP den PTR Record nicht erstellt - ok
Die GPO tut nicht das, was sie soll - nicht ok.
Ich gucke mal gleich nach den Zugriffsrechten der Zonen.
Zitat von @117471:
Der DHCP-Server trägt die reverse IP ein
Er kann diese Aufgabe übernehmen, ja.Der DHCP-Server trägt die reverse IP ein
Die UTM machts aufjedenfall nicht & die GPO macht auch nichts. Geblockt wird auch nichts. Hmm.
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
Hier das Log:
26.03.2021 09:16:45 0FC8 PACKET 00000057AE7581C0 UDP Rcv 192.168.40.157 79ce Q [0001 D NOERROR] SOA (7)pc05117(4)meinedomain(2)de(0)
26.03.2021 09:16:45 0FC8 PACKET 00000057AE7581C0 UDP Snd 192.168.40.157 79ce R Q [8085 A DR NOERROR] SOA (7)pc05117(4)meinedomain(2)de(0)
26.03.2021 09:16:45 0FC8 PACKET 00000057ACB4A170 UDP Rcv 192.168.40.157 d91d U [0028 NOERROR] SOA (4)meinedomain(2)de(0)
26.03.2021 09:16:45 081C PACKET 00000057ACB4A170 UDP Snd 192.168.40.157 d91d R U [00a8 NOERROR] SOA (4)meinedomain(2)de(0)Zitat von @117471:
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
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
Hi Jörg,
nein. Der DC macht nur DNS/AD. Kein DHCP. DHCP macht die UTM
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
