21
DNS: Was tuen wenn die Unternehmenswebsite und die Domain gleich heißen?
Hallo Zusammen,
ich musste heute mal wieder Bekanntschaft mit dem schönen Thema "gewachsene Struktur" machen. Folgendes:
Webseite des Unternehmes: Unternehmensname.de
Domain: Unternehmensname.de
Ja, ich weiß, so soll man es eigentlich nicht machen (hat man aber vor 12 Jahren, lange bevor ich hier angefangen bin aus irgendwelchen Gründen gemacht). Jetzt stehe ich vor dem Problem, das der DNS Server (Windows Server 2012 R2) einfach nur diese DNS Anfrage ins Netz weiterleiten soll, es aber nicht tut, weil er die Adresse ja richtig auflöst. An einen A-Eintrag habe ich auch schon gedacht, nur scheint beim Provider an sich auch noch mal eine Weiterleitung stattzufinden - anstatt der Website bekomme ich eine Generische "Under Construction" Website.
Die Infrastruktur besteht aus zwei nicht geclusterten Firewalls (.54 und .69 ,wird in zwei Monaten ausgewechselt), die bisher als Webproxy gearbeitet haben (via SOCKS über 8080). Problem hierbei: Die neue PLM Software, die ich gerade einführe, benötigt den Port 8080. Also ich die Ports 80, 443,22 und ein paar andere, für die Software benötigte Ports geöffnet und auf den Clients die Proxy Regulung für eine der Firewalls (die .69) deaktiviert, sowie die default-Route modifiziert, das Clients, die nach draußen wollen und keine Proxyeintragung haben, eben jene Firewall ansteuern. Funktioniert soweit auch alles, bis auf die Tatsache, das die eigene Unternehmenswebsite, die bei einem Provider gehostet ist, nicht von den Clients erreicht werden kann, die über .69 gehen.
Wenn ich wie gewohnt über den Webproxy der Firewall wie 8080 gehe, funktioniert die Namensauflösung und die Website wird mir angezeigt. Die Zuteilung welcher Client über welche Firewall geht, erfolgt mittels GPO.
Hat jemand schon mit sowas Erfahung gemacht?
ich musste heute mal wieder Bekanntschaft mit dem schönen Thema "gewachsene Struktur" machen. Folgendes:
Webseite des Unternehmes: Unternehmensname.de
Domain: Unternehmensname.de
Ja, ich weiß, so soll man es eigentlich nicht machen (hat man aber vor 12 Jahren, lange bevor ich hier angefangen bin aus irgendwelchen Gründen gemacht). Jetzt stehe ich vor dem Problem, das der DNS Server (Windows Server 2012 R2) einfach nur diese DNS Anfrage ins Netz weiterleiten soll, es aber nicht tut, weil er die Adresse ja richtig auflöst. An einen A-Eintrag habe ich auch schon gedacht, nur scheint beim Provider an sich auch noch mal eine Weiterleitung stattzufinden - anstatt der Website bekomme ich eine Generische "Under Construction" Website.
Die Infrastruktur besteht aus zwei nicht geclusterten Firewalls (.54 und .69 ,wird in zwei Monaten ausgewechselt), die bisher als Webproxy gearbeitet haben (via SOCKS über 8080). Problem hierbei: Die neue PLM Software, die ich gerade einführe, benötigt den Port 8080. Also ich die Ports 80, 443,22 und ein paar andere, für die Software benötigte Ports geöffnet und auf den Clients die Proxy Regulung für eine der Firewalls (die .69) deaktiviert, sowie die default-Route modifiziert, das Clients, die nach draußen wollen und keine Proxyeintragung haben, eben jene Firewall ansteuern. Funktioniert soweit auch alles, bis auf die Tatsache, das die eigene Unternehmenswebsite, die bei einem Provider gehostet ist, nicht von den Clients erreicht werden kann, die über .69 gehen.
Wenn ich wie gewohnt über den Webproxy der Firewall wie 8080 gehe, funktioniert die Namensauflösung und die Website wird mir angezeigt. Die Zuteilung welcher Client über welche Firewall geht, erfolgt mittels GPO.
Hat jemand schon mit sowas Erfahung gemacht?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 481959
Url: https://administrator.de/forum/dns-was-tuen-wenn-die-unternehmenswebsite-und-die-domain-gleich-heissen-481959.html
Ausgedruckt am: 03.04.2025 um 07:04 Uhr
21 Kommentare
Neuester Kommentar
Moin,
Frage: Die Website unter "www.domain.de" erreichbar machen ist keine Lösung? Weil, wenn deine AD-Domäne domain.de ist, solltest du an dem Record (der auf deine DCs zeigen sollte) nicht herumspielen.
lg,
Slainte
Frage: Die Website unter "www.domain.de" erreichbar machen ist keine Lösung? Weil, wenn deine AD-Domäne domain.de ist, solltest du an dem Record (der auf deine DCs zeigen sollte) nicht herumspielen.
lg,
Slainte
hi,
da deine Clients die Domäne zwingend unter den internen DC-IPs auflösen können müssen, gibt's eigentlich nur eine Variante die gangbar ist:
Installiere auf allen DCs unter Port 80 auf dem Sitenamen unternehmensname.de eine HTTP-Weiterleitung auf www.unternehmensname.de
Damit tun die Browser was sie sollen und der ganze andere Kram wie LDAP, DC usw funktioniert weiterhin.
Da man aber auf einem DC eigentlich nix haben will ausser einem DC: Die User dazu erziehen www. vor die Website zu stellen
da deine Clients die Domäne zwingend unter den internen DC-IPs auflösen können müssen, gibt's eigentlich nur eine Variante die gangbar ist:
Installiere auf allen DCs unter Port 80 auf dem Sitenamen unternehmensname.de eine HTTP-Weiterleitung auf www.unternehmensname.de
Damit tun die Browser was sie sollen und der ganze andere Kram wie LDAP, DC usw funktioniert weiterhin.
Da man aber auf einem DC eigentlich nix haben will ausser einem DC: Die User dazu erziehen www. vor die Website zu stellen
Das ist ja gerade mein Problem: Die Records zeigen auf die DCs meiner domain.de. Die Website heißt aber auch Domain.de. Die DNS-Server machen also nichts falsch, weil sie die Anfrage ihrer Meinung ja richtig auflösen (und das tuen sie ja). Vielleicht ein CNAME?
Zitat von @SeaStorm:
da deine Clients die Domäne zwingend unter den internen DC-IPs auflösen können müssen, gibt's eigentlich nur eine Variante die gangbar ist:
Installiere auf allen DCs unter Port 80 auf dem Sitenamen unternehmensname.de eine HTTP-Weiterleitung auf www.unternehmensname.de
Eine Weiterleitung sollte da nicht funktionieren. Wenn, dann müssten die DC als Reverse-Proxys für diese Website arbeiten.da deine Clients die Domäne zwingend unter den internen DC-IPs auflösen können müssen, gibt's eigentlich nur eine Variante die gangbar ist:
Installiere auf allen DCs unter Port 80 auf dem Sitenamen unternehmensname.de eine HTTP-Weiterleitung auf www.unternehmensname.de
Hi,
Dir könnte wohlmöglich ein Proxy-Server helfen.
Die Clients dürfen dann nur über diesen Proxy ins Internet. Der Proxy ist von der AD-Domain unabhängig, kennt bloß das Internet, arbeitet also nur mit dem externen DNS.
E.
Dir könnte wohlmöglich ein Proxy-Server helfen.
Die Clients dürfen dann nur über diesen Proxy ins Internet. Der Proxy ist von der AD-Domain unabhängig, kennt bloß das Internet, arbeitet also nur mit dem externen DNS.
E.
warum? Client frägt Seite von unternehmen.de an und bekommt einen Redirect auf www.unternehmen.de . Dieses löst auf die externe IP auf und alle sind glücklich.
Reverse wäre nur nötig wenn man unter "unternehmen.de" den Content haben will.
Reverse wäre nur nötig wenn man unter "unternehmen.de" den Content haben will.
So lief es ja bis jetzt: Die Firewalls arbeiteten als Webproxy. Der Webproxy benutzt aber den Port 8080, den die PLM Software benötigt.
OK, ja, wenn "www". Aber dann braucht er auch intern einen Record für "www".
Zitat von @exirex:
So lief es ja bis jetzt: Die Firewalls arbeiteten als Webproxy. Der Webproxy benutzt aber den Port 8080, den die PLM Software benötigt.
Ja und?So lief es ja bis jetzt: Die Firewalls arbeiteten als Webproxy. Der Webproxy benutzt aber den Port 8080, den die PLM Software benötigt.
den die PLM Software benötigt.
Wofür? Um den Proxy anzusprechen? Wenn nein - wo ist dann das Problem?
Ja und der muss auf die externe IP auflösen.
Das ist die "Lösung", die wir auch seit einem Jahr im Einsatz haben.
Ein Dienst innerhalb der Software benötigt den Port 8080. Gehe ich über den Webproxy (der ebenfalls die 8080 benutzt), scheitert die Verbindung weil eben jener Dienst nicht ins Netz kommt. Insgesamt benötigt diese Software neben 80 und 443 elf weitere Ports.
Wegen der externen IP: Das sollte sie laut nslookup im Web sein: http://80.70.176.42/. Steuert man die an, erhält man eine generische Website.
Frage: Ist das hier ok, wenn ich etwas unternehmensspezifisches (Website und co.) poste?
Wegen der externen IP: Das sollte sie laut nslookup im Web sein: http://80.70.176.42/. Steuert man die an, erhält man eine generische Website.
Frage: Ist das hier ok, wenn ich etwas unternehmensspezifisches (Website und co.) poste?
Zitat von @exirex:
Wegen der externen IP: Das sollte sie laut nslookup im Web sein: http://80.70.176.42/. Steuert man die an, erhält man eine generische Website.
der Webserver da drauf liefert halt nur DEINEN Content aus, wenn der Browser auch die Webseite anfrägt. Bei der IP ... halt nicht. Ist normal und gehört auch so.Wegen der externen IP: Das sollte sie laut nslookup im Web sein: http://80.70.176.42/. Steuert man die an, erhält man eine generische Website.
Zitat von @exirex:
Frage: Ist das hier ok, wenn ich etwas unternehmensspezifisches (Website und co.) poste?
Frage: Ist das hier ok, wenn ich etwas unternehmensspezifisches (Website und co.) poste?
Das muss du wissen. Es ist ein öffntlich einsehbares Forum, überlegt die selbst was andere mit der Information anfangen können.
Zitat von @exirex:
Ein Dienst innerhalb der Software benötigt den Port 8080. Gehe ich über den Webproxy (der ebenfalls die 8080 benutzt), scheitert die Verbindung weil eben jener Dienst nicht ins Netz kommt. Insgesamt benötigt diese Software neben 80 und 443 elf weitere Ports.
Proxy und Router trennen.Ein Dienst innerhalb der Software benötigt den Port 8080. Gehe ich über den Webproxy (der ebenfalls die 8080 benutzt), scheitert die Verbindung weil eben jener Dienst nicht ins Netz kommt. Insgesamt benötigt diese Software neben 80 und 443 elf weitere Ports.
So es läuft jetzt, danke noch einmal an alle Beteiligten. Lösung war ein simpler A Eintrag, der einfach nur "www" heißt (siehe Screenshot)
Jo, das stand seit einer Stunde als erster Post im Thread. :P
Hab den Wald vor lauter Bäumen nicht gesehen :P
In der Überschrift vermutlich auch nicht !!
https://www.duden.de/rechtschreibung/tun_handeln_erledigen
Das Forum bietet eine Funktion um Bilder einzubetten wenn man ganz einfach mal die FAQs liest und aufs kleine Kamera Symbol links an der Eingabemaske klickt. Solch große Tomaten auf selbigen kann man eigentlich gar nicht haben...
(Kann man übrigens auch noch nachträglich korrigieren...
)
https://www.duden.de/rechtschreibung/tun_handeln_erledigen
siehe Screenshot
Auch das muss hier nicht sein mit externen Bilderlinks und Zwangswerbung bzw. Beschnüffelung. Das Forum bietet eine Funktion um Bilder einzubetten wenn man ganz einfach mal die FAQs liest und aufs kleine Kamera Symbol links an der Eingabemaske klickt. Solch große Tomaten auf selbigen kann man eigentlich gar nicht haben...
(Kann man übrigens auch noch nachträglich korrigieren...
)
ich habe bei einem Kunden das gleiche Problem. ein A-Record www auf die externe Webseiten IP funktioniert nicht.
wenn ich im Browser https://www.kunde-xxx.at eingebe, ändert der Browser (Edge / Firefox) es auf https://kunde-xxx.at und es kommt 404
DNS Server Cache schon gelöscht. nslookup löst richtig auf die Ext Ip auf
wenn ich im Browser https://www.kunde-xxx.at eingebe, ändert der Browser (Edge / Firefox) es auf https://kunde-xxx.at und es kommt 404
DNS Server Cache schon gelöscht. nslookup löst richtig auf die Ext Ip auf
Da gräbt ja jemand Leichen aus 
Der Browser macht das nicht. Der Server hinter www.kunde-xx.at macht einen Redirect auf kunde-xx.at
Der Browser macht das nicht. Der Server hinter www.kunde-xx.at macht einen Redirect auf kunde-xx.at
