30
DNS nur noch statische Einträge
Moin moin ihr Lieben!
Vorab: Ich habe sehr wenig Ahnung von Netzwerken und noch weniger Ahnung von Samba.
Erstmal die Situation:
Ich habe gerade bei einem Kunden die Firewall ausgetauscht. Die Firewall macht DHCP.
Der Kunde benutzt Samba für die AD. Dementsprechend läuft dort auch der DNS.
Seitdem ich die Firewall getauscht habe, funktioniert nun allerdings der DNS nicht mehr korrekt.
Genauer gesagt, hat der DNS lediglich die statischen Einträge noch drin, alles andere, was dynamisch ist, ist einfach weg und kommt auch nicht wieder.
Der AD Server hat jetzt mal als Beispiel die 192.168.1.50
Die Domäne ist auch mal als Beispiel samdom.sam
Der DHCP ist so eingerichtet:
Gateway: 192.168.1.1 (IP der FW)
Nameserver: 192.168.1.50
NETBIOS Server: 192.168.1.50
Domainname: samdom.sam
In den Logs der Firewall habe ich geschaut, es wird kein Port 53 geblockt, telnet mit der 53 auf den DNS ist ebenfalls möglich.
Ich habe die Vermutung, dass es am DHCP liegt, ich verstehe jedoch nicht so recht den Zusammenhand zwischen DHCP und DNS, bisher hat es "einfach" funktioniert, solange ich im Windows-Universum geblieben bin ^^
Braucht ihr noch mehr Infos?
Ich freue mich sehr über Denkanstöße!
Vorab: Ich habe sehr wenig Ahnung von Netzwerken und noch weniger Ahnung von Samba.
Erstmal die Situation:
Ich habe gerade bei einem Kunden die Firewall ausgetauscht. Die Firewall macht DHCP.
Der Kunde benutzt Samba für die AD. Dementsprechend läuft dort auch der DNS.
Seitdem ich die Firewall getauscht habe, funktioniert nun allerdings der DNS nicht mehr korrekt.
Genauer gesagt, hat der DNS lediglich die statischen Einträge noch drin, alles andere, was dynamisch ist, ist einfach weg und kommt auch nicht wieder.
Der AD Server hat jetzt mal als Beispiel die 192.168.1.50
Die Domäne ist auch mal als Beispiel samdom.sam
Der DHCP ist so eingerichtet:
Gateway: 192.168.1.1 (IP der FW)
Nameserver: 192.168.1.50
NETBIOS Server: 192.168.1.50
Domainname: samdom.sam
In den Logs der Firewall habe ich geschaut, es wird kein Port 53 geblockt, telnet mit der 53 auf den DNS ist ebenfalls möglich.
Ich habe die Vermutung, dass es am DHCP liegt, ich verstehe jedoch nicht so recht den Zusammenhand zwischen DHCP und DNS, bisher hat es "einfach" funktioniert, solange ich im Windows-Universum geblieben bin ^^
Braucht ihr noch mehr Infos?
Ich freue mich sehr über Denkanstöße!
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: 3756316993
Url: https://administrator.de/contentid/3756316993
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
30 Kommentare
Neuester Kommentar
Ach so, kleiner Zusatz:
Der DHCP funktioniert und gibt auch Adressen aus, aber irgendwie sprechen DHCP und DNS nicht miteinander.
Der DHCP funktioniert und gibt auch Adressen aus, aber irgendwie sprechen DHCP und DNS nicht miteinander.
Zitat von @Julisu:
Moin moin ihr Lieben!
Vorab: Ich habe sehr wenig Ahnung von Netzwerken und noch weniger Ahnung von Samba.
Moin moin ihr Lieben!
Vorab: Ich habe sehr wenig Ahnung von Netzwerken und noch weniger Ahnung von Samba.
Seitdem ich die Firewall getauscht habe, funktioniert nun allerdings der DNS nicht mehr korrekt.
Das lasse ich mal so stehen
Erstmal das wichtige: Ich denke, der DHCP lief auf der Firewall?
Wenn ja, bedarf es einiges mehr an Konfiguration, um DHCP-Einträge in einem AD dynamisch zu verwalten, die Firewall muss als Member aufgenommen werden etc.
Aber bitte vielleicht erstmal Hersteller und Modell der Firewall nennen
VG
bitnarrator
Mach mal an einem Client (bei dem DNS nicht funktioniert) eine Auswertung von:
und kontrolliere welcher DNS Server gezogen wurde.
z.B.
Ethernet-Adapter Ethernet 2:
Verbindungsspezifisches DNS-Suffix: samdom.sam
Beschreibung. . . . . . . . . . . : USB Ethernet
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Lease erhalten. . . . . . . . . . : Mittwoch, 24. August 2022 11:59:29
Lease läuft ab. . . . . . . . . . : Freitag, 26. August 2022 09:33:54
Standardgateway . . . . . . . . . : 192.168.1.1
DHCP-Server . . . . . . . . . . . : 192.168.1.1
DNS-Server . . . . . . . . . . . : 192.168.1.50
NetBIOS über TCP/IP . . . . . . . : Deaktiviert
Suchliste für verbindungsspezifische DNS-Suffixe:
samdom.sam
ipconfig /allund kontrolliere welcher DNS Server gezogen wurde.
z.B.
Ethernet-Adapter Ethernet 2:
Verbindungsspezifisches DNS-Suffix: samdom.sam
Beschreibung. . . . . . . . . . . : USB Ethernet
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Lease erhalten. . . . . . . . . . : Mittwoch, 24. August 2022 11:59:29
Lease läuft ab. . . . . . . . . . : Freitag, 26. August 2022 09:33:54
Standardgateway . . . . . . . . . : 192.168.1.1
DHCP-Server . . . . . . . . . . . : 192.168.1.1
DNS-Server . . . . . . . . . . . : 192.168.1.50
NetBIOS über TCP/IP . . . . . . . : Deaktiviert
Suchliste für verbindungsspezifische DNS-Suffixe:
samdom.sam
Hi bitnarrator,
genau, DHCP lief vorher auch auf einem alten IPCop. Der kann nicht mal der Domäne beitreten, soweit ich weiß ^^
Jetzt habe ich eine Securepoint RC100 installiert. Der Support von denen sagte mir, dass das nicht an der Firewall liegen kann.
LG
Julisu
genau, DHCP lief vorher auch auf einem alten IPCop. Der kann nicht mal der Domäne beitreten, soweit ich weiß ^^
Jetzt habe ich eine Securepoint RC100 installiert. Der Support von denen sagte mir, dass das nicht an der Firewall liegen kann.
LG
Julisu
Dann muss man wissen wie genau es voher konfiguriert war.
Was geht denn genau nicht?
Nicht das jetzt durch den neuen DHCP-Server statische Reservierungen weg sind, diese Geräte jetzt neue IPs haben und durch den alten DNS-Eintrag nicht mehr angesprochen werden.
Also, die Domäne heißt samdom.sam
Diesen verteilt der DHCP auch?
Können AD-Rechner oder andere Geräte nicht erreicht werden? (Windows-AD-Geräte melden sich normalerweise im AD-DNS an)
Fall 1:
Du kommst also mit deinem Laptop (oder einem Drucker etc.), der nicht in der Domäne ist, mit dem Hostname LAPTOP in das Netzwerk, und der DHCP verteilt den Domainnamen samdom.sam
-> Da der AD nichts von der Firewall weiß und die Firewall nichts vom AD, können auch keine DNS-Einträge geupdatet werden
Fall 2:
Du kommt mit deinem Laptop in das Netzwerk und dieser ist Domänenmitglied. Eigentlich sollte der Client dann seine neue IP dem DC melden.
Fall 3:
Der DHCP-Server hat voher einen eigenen DNS-Bereich gehabt, z.b. dhcp.samdom.sam, und im DC wurde eine Weiterleitung eingerichtet für diese Zone. Dann hat die Firewall sich um das DNS der dynamischen Clients komplett selber gekümmert
Welcher Fall geht denn genau nicht?
Was geht denn genau nicht?
Nicht das jetzt durch den neuen DHCP-Server statische Reservierungen weg sind, diese Geräte jetzt neue IPs haben und durch den alten DNS-Eintrag nicht mehr angesprochen werden.
Also, die Domäne heißt samdom.sam
Diesen verteilt der DHCP auch?
Können AD-Rechner oder andere Geräte nicht erreicht werden? (Windows-AD-Geräte melden sich normalerweise im AD-DNS an)
Fall 1:
Du kommst also mit deinem Laptop (oder einem Drucker etc.), der nicht in der Domäne ist, mit dem Hostname LAPTOP in das Netzwerk, und der DHCP verteilt den Domainnamen samdom.sam
-> Da der AD nichts von der Firewall weiß und die Firewall nichts vom AD, können auch keine DNS-Einträge geupdatet werden
Fall 2:
Du kommt mit deinem Laptop in das Netzwerk und dieser ist Domänenmitglied. Eigentlich sollte der Client dann seine neue IP dem DC melden.
Fall 3:
Der DHCP-Server hat voher einen eigenen DNS-Bereich gehabt, z.b. dhcp.samdom.sam, und im DC wurde eine Weiterleitung eingerichtet für diese Zone. Dann hat die Firewall sich um das DNS der dynamischen Clients komplett selber gekümmert
Welcher Fall geht denn genau nicht?
1
Ist die DNS Weiterleitung auf dem lokalen DNS Server an die lokale IP der neuen Firewall richtig eingestellt?
Generell hast du es ja soweit richtig gemacht. Die lokalen Clients bekommen über den DHCP Server alle die 192.168.1.50 was ja der lokale DNS Server ist um damit lokale Domain Namen auflösen zu können. Das ist mit ipconfig /all (Winblows) ja auch überprüfbar wie Kollege @NordicMike oben schon sagt und hat sich zum vorherigen Setup ja auch nicht geändert.
Was aber zwingend ist, ist die DNS Weiterleitung im Server für alle Hostnamen die der lokale DNS nicht auflösen kann. In der Regel sind das alle Internet Hostnamen.
Diese DNS Weiterleitung muss auf die lokale IP der Firewall 192.168.1.1 zeigen sofern die wie üblich als DNS Proxy zum Provider arbeitet.
Das nslookup Tool ist dein bester Freund das zu checken! nslookup www.administrator.de zeigt dir welchen DNS der Client verwendet und das Resultat.
Wenn du keinerlei Ahnung von der Materie hast fragt sich warum du dir sowas ans Bein bindest. An deine Autowartung würdest du doch auch keinen Gärtner lassen, oder? Such dir Hilfe von einem der weiss was er tut.
Generell hast du es ja soweit richtig gemacht. Die lokalen Clients bekommen über den DHCP Server alle die 192.168.1.50 was ja der lokale DNS Server ist um damit lokale Domain Namen auflösen zu können. Das ist mit ipconfig /all (Winblows) ja auch überprüfbar wie Kollege @NordicMike oben schon sagt und hat sich zum vorherigen Setup ja auch nicht geändert.
Was aber zwingend ist, ist die DNS Weiterleitung im Server für alle Hostnamen die der lokale DNS nicht auflösen kann. In der Regel sind das alle Internet Hostnamen.
Diese DNS Weiterleitung muss auf die lokale IP der Firewall 192.168.1.1 zeigen sofern die wie üblich als DNS Proxy zum Provider arbeitet.
Das nslookup Tool ist dein bester Freund das zu checken! nslookup www.administrator.de zeigt dir welchen DNS der Client verwendet und das Resultat.
Wenn du keinerlei Ahnung von der Materie hast fragt sich warum du dir sowas ans Bein bindest. An deine Autowartung würdest du doch auch keinen Gärtner lassen, oder? Such dir Hilfe von einem der weiss was er tut.
1
Ist jetzt auch die Frage, ob Internet-Hostnames oder DHCP-Hosts nicht funktionieren.
Ich bin wegen der Angabe DHCP davon ausgegangen, dass er interne Hosts meint.
Ich bin wegen der Angabe DHCP davon ausgegangen, dass er interne Hosts meint.
dass er interne Hosts meint.
Das hat er ja leider auch nicht klar beschrieben was das genaue Fehlerbild ist! Lediglich das er von all dem keine Ahnung hat. 
Zitat von @bitnarrator:
Dann muss man wissen wie genau es voher konfiguriert war.
Was geht denn genau nicht?
Also genauer geht es um interne Hosts. Im DNS sehe ich feste Zuordnungen, aber alle Geräte, die keine statische Zuordnung haben, sondern ihre IPs vom DHCP beziehen, werden im DNS nicht aufgeführt.Dann muss man wissen wie genau es voher konfiguriert war.
Was geht denn genau nicht?
Nicht das jetzt durch den neuen DHCP-Server statische Reservierungen weg sind, diese Geräte jetzt neue IPs haben und durch den alten DNS-Eintrag nicht mehr angesprochen werden.
Ich habe auf dem alten System mal nachgeschaut und dort waren keine festen IPs hinterlegt. Die festen IPs sind auf den Clients im Windows hinterlegt.
Also, die Domäne heißt samdom.sam
Diesen verteilt der DHCP auch?
Diesen verteilt der DHCP auch?
Genau
Können AD-Rechner oder andere Geräte nicht erreicht werden? (Windows-AD-Geräte melden sich normalerweise im AD-DNS an)
Richtig. Es sind alles AD-Rechner. Ein NSLOOKUP gibt ein unknown zurück.
Fall 1:
Du kommst also mit deinem Laptop (oder einem Drucker etc.), der nicht in der Domäne ist, mit dem Hostname LAPTOP in das Netzwerk, und der DHCP verteilt den Domainnamen samdom.sam
-> Da der AD nichts von der Firewall weiß und die Firewall nichts vom AD, können auch keine DNS-Einträge geupdatet werden
Du kommst also mit deinem Laptop (oder einem Drucker etc.), der nicht in der Domäne ist, mit dem Hostname LAPTOP in das Netzwerk, und der DHCP verteilt den Domainnamen samdom.sam
-> Da der AD nichts von der Firewall weiß und die Firewall nichts vom AD, können auch keine DNS-Einträge geupdatet werden
Es handelt sich hier um Geräte, die in der Domäne bereits vorhanden sind / waren
Fall 2:
Du kommt mit deinem Laptop in das Netzwerk und dieser ist Domänenmitglied. Eigentlich sollte der Client dann seine neue IP dem DC melden.
Du kommt mit deinem Laptop in das Netzwerk und dieser ist Domänenmitglied. Eigentlich sollte der Client dann seine neue IP dem DC melden.
So sollte es sein.
Fall 3:
Der DHCP-Server hat voher einen eigenen DNS-Bereich gehabt, z.b. dhcp.samdom.sam, und im DC wurde eine Weiterleitung eingerichtet für diese Zone. Dann hat die Firewall sich um das DNS der dynamischen Clients komplett selber gekümmert
Der DHCP-Server hat voher einen eigenen DNS-Bereich gehabt, z.b. dhcp.samdom.sam, und im DC wurde eine Weiterleitung eingerichtet für diese Zone. Dann hat die Firewall sich um das DNS der dynamischen Clients komplett selber gekümmert
Welcher Fall geht denn genau nicht?
Fall 2
Du musst dynamische Updates im ad DNS erlauben/konfigurieren.
Moin,
Wenn per DHCp IP-Adressen dynamisch vergeben werden un ddie Namen dann auch im DNS auftauchen sollen, muß natürlich der DHCP-Server dies einem DNS-Serve rauch mitteilen. d.h. man muß den so konfigurieren, daß er dynamische DNS-Updates macht. Dazu muß natürlich der DNS-Server auch so konfiguriert werden, daß er dynamische DNS-Updates akzeptiert. Wenn nun da meherere DNS-Server im Spiel sind, müssen die natürlch auch so eingestellt werdemn, daß der mit den dynamischen Updates auch gefragt wird, z.B. indem man auf den "forwarded".
Meine Kristallkugel sagt nun, daß Deine vorherige Firewall auch das geteway und damit auch der DNS-Server für Dein LAN war und der DHCP-Server da drauf automatisch den DNS aktualisiert hat.
Deine neue Firewall ist vermutlich so eingestellt, daß da entweder kein DNS mehr läuft und der einfach die DNS-Anfragen an die Providerserver weiterleitet oder daß der DHCp erst gesagt bekommen muß, daß er dynamische DNS-Updates machen muß.
lks
Wenn per DHCp IP-Adressen dynamisch vergeben werden un ddie Namen dann auch im DNS auftauchen sollen, muß natürlich der DHCP-Server dies einem DNS-Serve rauch mitteilen. d.h. man muß den so konfigurieren, daß er dynamische DNS-Updates macht. Dazu muß natürlich der DNS-Server auch so konfiguriert werden, daß er dynamische DNS-Updates akzeptiert. Wenn nun da meherere DNS-Server im Spiel sind, müssen die natürlch auch so eingestellt werdemn, daß der mit den dynamischen Updates auch gefragt wird, z.B. indem man auf den "forwarded".
Meine Kristallkugel sagt nun, daß Deine vorherige Firewall auch das geteway und damit auch der DNS-Server für Dein LAN war und der DHCP-Server da drauf automatisch den DNS aktualisiert hat.
Deine neue Firewall ist vermutlich so eingestellt, daß da entweder kein DNS mehr läuft und der einfach die DNS-Anfragen an die Providerserver weiterleitet oder daß der DHCp erst gesagt bekommen muß, daß er dynamische DNS-Updates machen muß.
lks
Kann mir jemand erklären, wie ich das mache? Aktuell wird der Samba eigene DNS benutzt. Ich finde keine Anleitung, um einen gesonderten DHCP mit dem DNS zu verheiraten
Wo bleibt eigentlich die Auswertung?
ipconfig /allZitat von @Julisu:
Kann mir jemand erklären, wie ich das mache? Aktuell wird der Samba eigene DNS benutzt. Ich finde keine Anleitung, um einen gesonderten DHCP mit dem DNS zu verheiraten
Kann mir jemand erklären, wie ich das mache? Aktuell wird der Samba eigene DNS benutzt. Ich finde keine Anleitung, um einen gesonderten DHCP mit dem DNS zu verheiraten
z.B. so:
https://www.admin-magazin.de/Online-Artikel/Automatische-DNS-Updates-per ...
lks
1Aktuell habe ich kein Windows System mit DHCP zur Verfügung.
Das muss ich später machen, weil sonst eine der VMs kurzzeitig nicht erreichbar wäre. Da der Kunde viel mit Datenbanken arbeiten, will ich hier ungern während des Betriebs etwas am Netzwerk umbauen.
Oh man....
Ich habe mir die alte FW nochmal angesehen.
Es ist in der Tat so, dass wirklich alles (auch jeder Client!!) fest zugeordnet wurde!
Das will ich natürlich nicht weiter so haben, deswegen bleibt meine Frage bestehen.
Ich habe mir die alte FW nochmal angesehen.
Es ist in der Tat so, dass wirklich alles (auch jeder Client!!) fest zugeordnet wurde!
Das will ich natürlich nicht weiter so haben, deswegen bleibt meine Frage bestehen.
deswegen bleibt meine Frage bestehen.
Hat Kollege @Lochkartenstanzer oben doch gerade schon beantwortet!
Leider scheitert die Anleitung daran, dass dort BIND9 genutzt wird, was aber beim Samba eigenen DNS nicht benutzt wird.
Gibt es irgendwo eine Anleitung explizit für Samba?
Ich hatte jetzt die Befürchtung, dass Samba vielleicht doch gar nicht den DNS machent.
Siehe SMB.conf:
dns forwarder = 192.168.50.1
Ist doch die Firewall der DNS?
Gibt es irgendwo eine Anleitung explizit für Samba?
Ich hatte jetzt die Befürchtung, dass Samba vielleicht doch gar nicht den DNS machent.
Siehe SMB.conf:
dns forwarder = 192.168.50.1
Ist doch die Firewall der DNS?
was spricht denn dagegen, den DHCP-Server mit auf den DC zu legen?
https://wiki.samba.org/index.php/Configure_DHCP_to_update_DNS_records
Oder Stefan Kania, 2. Auflage Kapitel 8.
Das Webinterface der Securepoint möchte man doch ohnehin nicht freiwillig nutzen
Viele Grüße, commodity
https://wiki.samba.org/index.php/Configure_DHCP_to_update_DNS_records
Oder Stefan Kania, 2. Auflage Kapitel 8.
Das Webinterface der Securepoint möchte man doch ohnehin nicht freiwillig nutzen
Viele Grüße, commodity
Poste mal deine SMb.conf
- Global parameters
netbios name = DEB9-AD-01
realm = SAMDOM.SAM
workgroup = SAMDOM
dns forwarder = 192.168.50.1
server role = active directory domain controller
- client min protocol = NT1
- client max protocol = SMB3
- server min protocol = NT1
[netlogon]
path = /var/lib/samba/sysvol/samdom.sam/scripts
read only = No
Ldap server require strong auth = no
[sysvol]
path = /var/lib/samba/sysvol
read only = No
Ldap server require strong auth = no
Zitat von @commodity:
was spricht denn dagegen, den DHCP-Server mit auf den DC zu legen?
https://wiki.samba.org/index.php/Configure_DHCP_to_update_DNS_records
Oder Stefan Kania, 2. Auflage Kapitel 8.
Das Webinterface der Securepoint möchte man doch ohnehin nicht freiwillig nutzen
Viele Grüße, commodity
was spricht denn dagegen, den DHCP-Server mit auf den DC zu legen?
https://wiki.samba.org/index.php/Configure_DHCP_to_update_DNS_records
Oder Stefan Kania, 2. Auflage Kapitel 8.
Das Webinterface der Securepoint möchte man doch ohnehin nicht freiwillig nutzen
Viele Grüße, commodity
Das wäre dann wohl die einfachste Lösung....
Ich glaube aber, dass ich an dieser Stelle nicht weiter mache.
Der Kunde bekommt ohnehin in den nächsten Wochen einen neuen Server, worauf dann auch Windows Server die Domäne, DNS und DHCP übernehmen.
Also jetzt noch so viel Zeit investieren wäre unnütz.
Dann lieber ein letztes mal Q&D und dann richtig!
Ich danke euch allen an dieser Stelle herzlich!
dns forwarder = 192.168.50.1
192.168.1.50 ?Hi,
ja das hatte ich bereits gemacht, leider hat das nicht geholfen
Jup, Zahlendreher. In der originalen Konfig ist es richtig herum
Zitat von @Julisu:
Leider scheitert die Anleitung daran, dass dort BIND9 genutzt wird, was aber beim Samba eigenen DNS nicht benutzt wird.
Gibt es irgendwo eine Anleitung explizit für Samba?
Ich hatte jetzt die Befürchtung, dass Samba vielleicht doch gar nicht den DNS machent.
Leider scheitert die Anleitung daran, dass dort BIND9 genutzt wird, was aber beim Samba eigenen DNS nicht benutzt wird.
Gibt es irgendwo eine Anleitung explizit für Samba?
Ich hatte jetzt die Befürchtung, dass Samba vielleicht doch gar nicht den DNS machent.
Samba macht i.d.R. keinen eigenen DNS, sondern nutzt den der konfiguriert ist.
Siehe SMB.conf:
dns forwarder = 192.168.50.1
Ist doch die Firewall der DNS?
dns forwarder = 192.168.50.1
Ist doch die Firewall der DNS?
Wenn das die İP-Adresse der Firewall ist, ist das der nächste Inder Kette.
lks
Kurzes Follow-Up:
Ich habe das Problem gefunden, warum die Auflösung vorher funktionierte und nun nicht mehr.
Der Kunde hat berichtet, dass er auf den zweiten teil der FQDN nicht mehr zugreifen kann
also:
vorher konnte der auf HOST.sam zugreifen, nun aber nicht mehr.
HOST.samdom.sam funktionierte allerdings.
Also habe ich im alten IPCop nochmal nachgeschaut und siehe da: der IPCop hatte manuell Hostnamen hinterlegt, mit einer einfachen "sam" Endung.
Ich habe nun einfach eine zweite DNS Zone auf dem DNS erstellt und nun funktioniert wieder alles.
Ich freue mich schon auf den neuen Server und eine endlich vernünftige AD, DNS, DHCP Umgebung für deren reines Windows-Netzwerk ^^
Schönes Wochenende an alle!
Ich habe das Problem gefunden, warum die Auflösung vorher funktionierte und nun nicht mehr.
Der Kunde hat berichtet, dass er auf den zweiten teil der FQDN nicht mehr zugreifen kann
also:
vorher konnte der auf HOST.sam zugreifen, nun aber nicht mehr.
HOST.samdom.sam funktionierte allerdings.
Also habe ich im alten IPCop nochmal nachgeschaut und siehe da: der IPCop hatte manuell Hostnamen hinterlegt, mit einer einfachen "sam" Endung.
Ich habe nun einfach eine zweite DNS Zone auf dem DNS erstellt und nun funktioniert wieder alles.
Ich freue mich schon auf den neuen Server und eine endlich vernünftige AD, DNS, DHCP Umgebung für deren reines Windows-Netzwerk ^^
Schönes Wochenende an alle!
prima, danke dito!
Viele Grüße, commodity
Viele Grüße, commodity
Vermutlich hast du den Clients keine Suchdomain in die DHCP Optionen mitgegeben.
1
