NameServer Weiterleitung testen
Hallo
Meine TLD "petergyger.net" hat seit mehreren Jahren eine Weiterleitung auf "https://petergyger.github.io"
Im Sept 2019 zu einem anderen NameServer Anbieter gewechselt. Weiterleitung funktioniert
Juni 202 zu einem anderen NameServer Anbieter gewechselt. Weiterleitung funktioniert nicht mehr.
Seit gestern Mittag im Mailverkehr mit dem Serverspezialisten der Firma.
Seine letzte Antwort war
Die RR:
Wie kann man die Umleitung testen? Um auszuschliessen, dass es nicht an GitHub liegt? Umbiegen auf example.com?
Nicht vergessen: Es hat bis Ende Mai 2020 seit Jahren funktioniert
Beste Grüsse
Peter
Meine TLD "petergyger.net" hat seit mehreren Jahren eine Weiterleitung auf "https://petergyger.github.io"
Im Sept 2019 zu einem anderen NameServer Anbieter gewechselt. Weiterleitung funktioniert
Juni 202 zu einem anderen NameServer Anbieter gewechselt. Weiterleitung funktioniert nicht mehr.
Seit gestern Mittag im Mailverkehr mit dem Serverspezialisten der Firma.
Seine letzte Antwort war
1
2
3
4
2
3
4
"Es gibt 2 Möglichkeiten die Weiterleitung zu den GitHub-Pages zu erstellen. Die eine ist keine Weiterleitung an sich, sondern die GitHub-Pages "hören" dann auf Ihre Domain. Dafür muss das Repo gemäss Link (https://help.github.com/en/github/working-with-github-pages/managing-a-custom-domain-for-your-github-pages-site#configuring-an-apex-domain) konfiguriert werden. Dies geschieht über DNS.
Die Andere Möglichkeit ist via HTTP-Redirect. Dafür zeigt der DNS-Eintrag auf einen Webserver, welcher in Ihrer Verwaltung steht. Dieser leitet dann den Besucher weiter. Die kann entweder in der Webserver-Config oder über die Website selbst (zB. über HTML-Header oder PHP) .
Zum jetzigen Standpunkt wäre es wohl am einfachsten, die Domain im Repo von Github zu hinterlegen, danach funktioniert der Aufruf.
"
Die RR:
Wie kann man die Umleitung testen? Um auszuschliessen, dass es nicht an GitHub liegt? Umbiegen auf example.com?
Nicht vergessen: Es hat bis Ende Mai 2020 seit Jahren funktioniert
Beste Grüsse
Peter
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 577733
Url: https://administrator.de/forum/nameserver-weiterleitung-testen-577733.html
Ausgedruckt am: 13.04.2025 um 09:04 Uhr
10 Kommentare
Neuester Kommentar

Github wertet den HTTP-Hostheader-Wert aus mit dem jemand auf die Seite navigiert, und der ist bei Nutzung eines CNAME bei dir nunmal "www.xxx.net", den kennt Github aber nicht (deswegen Fehlermeldung das es die Seite nicht gibt), also hinterlegst du den CNAME in deinem Repo
Managing a custom domain for your GitHub Pages site
Danach funktioniert auch die CNAME-Weiterleitung auf das Github Ziel wieder.
Willst du das nicht machen, dann wie der Techniker schon sagt ein HTTP-Redirect oder ein HTTP-Rewrite (z.B. über .htaccess) auf die Domain machen, dann steht auch der Host-Header wieder auf "xxx.github.io" und die Seite wird korrekt angezeigt .
Managing a custom domain for your GitHub Pages site
1. On GitHub, navigate to your site's repository.
2. Under your repository name, click Settings.
3. Under "Custom domain", type your custom domain, then click Save. This will create a commit that adds a CNAME file in the root of your publishing source.
Danach funktioniert auch die CNAME-Weiterleitung auf das Github Ziel wieder.
Willst du das nicht machen, dann wie der Techniker schon sagt ein HTTP-Redirect oder ein HTTP-Rewrite (z.B. über .htaccess) auf die Domain machen, dann steht auch der Host-Header wieder auf "xxx.github.io" und die Seite wird korrekt angezeigt .

Zitat von @PeterGyger:
A: Ich werde in GitHub die Konfigurationsseite suchen und den Wert dort dokumentieren
Jepp, dort ändern und es läuftA: Ich werde in GitHub die Konfigurationsseite suchen und den Wert dort dokumentieren
B: Wie bereits geschrieben: Sept 2019 habe ich meinen Anbieter des Name Server gewechselt. Forwarding eingetragen. ALLES FUNKTIONIERT!
Jun 2020 anderen Name Server Anbieter. NICHTS FUNKTIONIERT!
Einfach den technischen Background verstehen bringt mehr. Gut möglich das Github das erst vor kurzem eingeführt hat.Jun 2020 anderen Name Server Anbieter. NICHTS FUNKTIONIERT!
Und jetzt soll ich meine GitHub Konfiguration prüfen??
Jepp 
GitHub ist eine kostenlose Lösung und da kann man natürlich keine Qualität erwarten.
Also sollte ich nicht überrascht sein.
Was soll das mit "Qualität" zu tun haben?? Sorry aber das ist Blödsinn, das ist gängige Praxis und sogar ein Sicherheitsgewinn, denn sonst könnte jeder über eigene DNS Manipulation deine Seite mit einer anderen URL ausliefern und so dem User vorgaukeln er wäre woanders!Also sollte ich nicht überrascht sein.

Ich hatte mehr als einen solche Überraschung.
Dienste ändern sich, das ist die Natur der Technik. Da hilft eben nur am Ball bleiben und ein Monitoring-System. Wenn man sich auf einen fremden Dienst verlässt hast du immer ein Problem.Leg deine Homepage auf deinen eigenen Server dann hast du solche Überraschungen nicht, bist aber auch selbst verantwortlich für jegliche Unwägbarkeiten.
Wenn der CName Eintrag einfach "weg" ist, nachdem ich den Name Server Anbieter gewechselt habe, dann ist das für mich ein Qualitätsproblem.
Das war meines Erachtens eher Zufall oder deine vorherige Weiterleitung war vorher schon über einen HTTP-Redirect oder Rewrite gelöst, du hast es nur nicht gemerkt.Wie testet man eine DNS Redirection?
Das ist kein Problem.Wie du schon sagst , erst mal über die gängigen DNS Tools (dig & Co.) das Ziel für den CNAME ermitteln, und dann mit dem Ergebnis z.B. mit CURL / WGET / Powershell usw. eine HTTP-Anfrage machen und den Status-Code in der HTTP-Response auswerten.
https://de.wikipedia.org/wiki/HTTP-Statuscode
Das ganze machen die gängigen Monitoring-Tools (Nagios & PRTG, Zabbix & Co.) right out of the box, das ist ein vollkommen harmloser HTTP-Check.

Kannst du, ist deine DNS-Zone. Im Grunde ist das keine echte "Redirection" sondern eine stink normale DNS-Abfrage die der Client hier macht. Ein "Redirect" im Wortlaut geschieht auf dem Server welcher die Seite ausliefert, also bspw. per MET-Tag / .htaccess rewrite usw..
Was die aufgerufene Seite dann mit dem fremden Host-Header (bei einem eingetragenen CNAME) macht entscheidet sie.
Bei HTTPS-Seiten wird dann allerdings ein Fehler angezeigt weil der Common-Name im Zertifikat der Zielseite nicht mit dem aufgerufenen Host übereinstimmt.
Was die aufgerufene Seite dann mit dem fremden Host-Header (bei einem eingetragenen CNAME) macht entscheidet sie.
Bei HTTPS-Seiten wird dann allerdings ein Fehler angezeigt weil der Common-Name im Zertifikat der Zielseite nicht mit dem aufgerufenen Host übereinstimmt.