Wie sollten Websites mit Hostnamen mit nachgestellten Punkten umgehen?

Ich habe diese Frage gelesen. Wie können URLs einen Punkt haben? am Ende zB www.bla.de.? und stellen Sie fest, dass der FQDN ein Trailing .für das Root-Label des DNS-Baums enthalten sollte:

example.com. Anstatt von example.com

Es gibt jedoch Probleme, auf die in diesem Blog-Artikel hingewiesen wird :

Wenn Sie nicht berücksichtigen, dass der Benutzer den Domain-Namen versehentlich mit einem Punkt am Ende eingeben kann, oder einem Link folgen, der von einem "Well-Wisher" empfangen wurde, und Ihren Domain-Namen mit dem Punkt am Ende als erhalten Ergebnis kann es zu unerwarteten Konsequenzen führen:

1) Wenn die Website HTTPS verwendet, zeigt der Browser beim Navigieren zum Domainnamen mit dem Punkt am Ende die Warnung bei nicht vertrauenswürdiger Verbindung an.

2) Die Authentifizierung kann unterbrochen werden, da Cookies normalerweise für den Domainnamen ohne Punkt am Ende gesetzt werden. Der Benutzer wird in diesem Fall ziemlich überrascht sein, warum er sich nicht anmelden kann. Es ist bemerkenswert, dass, wenn Sie ein Cookie für einen Domainnamen mit einem Punkt am Ende setzen, dieses Cookie nicht ohne den Punkt an den Domainnamen übergeben wird am Ende und umgekehrt.

3) JavaScript auf der Seite ist möglicherweise defekt.

4) Möglicherweise treten Probleme beim Zwischenspeichern von Websiteseiten auf (z. B. wird der https://www.cloudflare.com/Seitencache nicht gelöscht, wenn der Domainname am Ende einen Punkt enthält, der ihn als ungültigen Domainnamen ansieht).

5) Wenn Sie sich unter Bedingungen in der Webserverkonfiguration auf den bestimmten Domainnamen ($ http_host in Nginx,% {HTTP_HOST} in Apache) ohne den Punkt am Ende verlassen, können Sie auf eine Vielzahl unerwarteter Situationen stoßen: unerwartete Weiterleitungen, grundlegend -Autorisierungsprobleme usw.

6) Wenn der Webserver nicht so konfiguriert ist, dass Anforderungen für den Domänennamen mit dem nachstehenden Punkt akzeptiert werden, wird für jeden Benutzer, der versehentlich einen Domänennamen mit dem nachstehenden Punkt eingegeben hat, Folgendes angezeigt: Ungültige Anforderung - Ungültiger Hostname.

7) Es ist möglich, dass Suchmaschinen feststellen, dass Ihre Ressource einen doppelten Inhalt hat, wenn jemand versehentlich oder absichtlich Links auf Ihre Webseiten mit einem Punkt am Ende des Domainnamens postet.

Mir ist auch klar, dass http://webmasters.stackexchange.com./das a 400 Bad Request. Aber da der eigentliche Domainname .am Ende ein enthalten sollte , sollten wir dann nicht einen 400Fehler ausgeben oder 301für Hostnamen ohne nachgestellten Punkt umleiten? Wie kann dieses Problem kohärent und konsequent angegangen werden?

Um Ihre Frage teilweise zu beantworten, können Sie sie zu den kanonischen Weiterleitungsregeln von htaccess hinzufügen. Grundsätzlich wird nach einem Zeitraum vor dem URI gesucht und in den von Ihnen verwendeten Antiduplikat-Weiterleitungsmechanismus eingearbeitet. Hier ist ein Beispiel, das eine übliche "Addon-Domain" -Unter-Util-Route enthält:

RewriteCond %{HTTP_HOST} ^domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^domain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain\.com\.$
RewriteRule ^(.*)$ "http\:\/\/www\.domain\.com\/$1" [R=301,L]

Dies würde Folgendes an eine kanonische HTTP-WWW-Domain weiterleiten:

• domain.hostdomain.com
• domain.hostdomain.com.
• www.domain.hostdomain.com
• www.domain.hostdomain.com.
• domain.com
• domain.com.
• www.domain.com.

Alle freuen uns auf:

• http://www.domain.com

Dies hat jedoch eine Einschränkung : Wie im ursprünglichen Blog-Zitat angegeben, wird SSL nicht korrekt weitergeleitet und zeigt in den meisten Server-Instanzen eine Browser-Warnung oder einen 400-Bit-Anforderungsfehler an (insbesondere bei HSTS). Dies liegt daran, dass das SSL des "Hosts" in einem Anwendungsfall nach der TLD-Periode angezeigt wird. Ich bin mir nicht sicher, wie ich die Host-SSL-Warnung umgehen soll, da sie vor htaccess und anderen Problemen auftritt.

Ich stelle mir den abschließenden Punkt gerne als die "echte" Wurzel des Internets vor und denke, dass er in Virginia, USA, lebt. Wenn Sie den Punkt weglassen, wird immer eine Wurzel impliziert. Für normale Benutzer ist es die gleiche Wurzel, und über diese Situation werde ich heute sprechen.

Auf meine perverse Art finde ich den abschließenden Punkt eigentlich recht praktisch. Wenn ich die Website einer anderen Person auschecke und neu anfangen möchte, ohne Zwischenspeicherung, ohne Cookies usw., und ich zu faul bin, diese auszuspülen, verwende ich entweder einen anderen Browser oder ich füge den Punkt hinzu. Wenn die Site mich nicht weiterleitet, sind die URLs für alle Seiten der Site und andere Ressourcen frisch und nicht zwischengespeichert.

Als Webmaster möchte ich, dass alle Personen und Roboter, die eine Seite anzeigen, diese mit derselben URL und daher mit demselben Hostnamen anzeigen. Wenn der Hostname nicht der Name ist, den sie verwenden sollen, leite ich ihn sofort um, damit sie die richtige URL in ihrem Browser sehen. Für meine PHP-basierten Sites behandle ich das Problem in PHP und nicht in der Datei .htaccess oder web.config, da es portabler ist und leichter auf Entwicklungs- und Staging-Servern getestet werden kann. Ich bearbeite meine Datenbankverbindungen gleichzeitig, da sie sich auch zwischen Entwicklungs- / Staging- / Produktionsservern unterscheiden.

Hier ist eine vereinfachte Version meines typischen Codes. Beachten Sie die kanonischen Weiterleitungen gegen Ende.

    $Host = $_SERVER['HTTP_HOST'];
    switch ( $Host ) {
        case 'exampleweb.local':                    // my local dev machine
                $MysqliParams = array(
                        'host'      =>  'localhost',
                        'username'  =>  'root',
                        'passwd'    =>  'snoopy',
                        'dbname'    =>  'exampledb');
                break;
        case 'www.exampleweb.com':                  // the "live" site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_db');
                $GoogleAccount = 'UA-13243546-01;   // only enable for live site
                break;
        case 'exampleweb.mystagingsite.net':        // the client preview site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_staging');
                break;
        case 'exampleweb.com':                  // canonical redirects 
        case 'exampleweb.com.':
        case 'www.exampleweb.com.':
                header('HTTP/1.1 301 Moved Permanently');
                header("Location: http://www.exampleweb.com");
                exit;
        default:
                die("invalid hostname $Host");
    }   

Mein Kommentar unter https://core.trac.wordpress.org/ticket/35248#comment:9 :

meine Antwort auf den Text durch den ersten Link ( https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html ):

Ursprünglich, wie in RFC 1738 (§ 3.1) definiert, war der "Host" -Teil einer (Common Internet Scheme) -URL immer und eindeutig ein vollqualifizierter Domänenname und der herkömmliche Mechanismus zur Unterscheidung von vollqualifizierten Domänennamen von nicht vollqualifizierten Domänennamen. Qualifizierte Domainnamen wurden nicht berücksichtigt. Ob es example.com war. oder example.com, der Host sollte derselbe sein.

- Ich denke, er hat nicht Recht. Ich denke, "example.com" war in URLs gemäß RFC 1738 überhaupt nicht erlaubt. Es wird im zweiten Text zitiert und ich zitiere es:

3.1. Common Internet Scheme Syntax
        // <Benutzer>: <Kennwort> @ <Host>: <Port> / <URL-Pfad>
    Wirt
        Der vollständig qualifizierte Domänenname eines Netzwerkhosts

und "example.com" konnten zu diesem Zeitpunkt nicht in http-Headern verwendet werden, da der RFC 1738 aus dem Jahr 1994 stammt und das Host-Feld 1997 nur mit http 1.1 angezeigt wurde (siehe Wikipedia).

In der Tat wurde nur fqdn in URLs zugelassen. Ich denke, dies war ein Fehler in RFC 1738, weil es auf diese Weise die Funktion "Relative Domains" nutzlos machte (zu machen versuchte). Wenn dies nicht verboten ist, können sie theoretisch in "a" -Tag-hrefs in lokalen Skript-Sites oder in statischen HTML-Dokumentationen in großen Unternehmen verwendet werden, die relative Domänen verwendeten, sofern Browser und Server dies unterstützen. Aber selbst wenn RFC 1738 dies nicht zuließ, hielten sich die Leute nicht daran: Sie verwendeten weiterhin Top-Level-Domains in relativer Form, dh ohne abschließenden Punkt. Daher war das Ablehnen von RFC 1738 ohnehin kein großes praktisches Problem, und die Leute hatten und benutzten eine Alternative Relative Domains: Sie haben nur lokale Top-Level-Domains wie "localhost" erstellt (und diese auch ohne abschließenden Punkt verwendet und verwendet).

dann sagt er:

Leider haben Webbrowser in der Praxis immer gegen diese Spezifikation verstoßen und den "Host" -Teil durch die Namensqualifizierungsverfahren ihrer DNS-Client-Bibliotheken geleitet, wenn der Hostname einer Reihe von IP-Adressen zugeordnet wurde. (Beispielsweise würden diejenigen, die die BIND-DNS-Clientbibliothek verwendet haben, die Option RES_DNSRCH belassen und den letzten nachgestellten Punkt nicht anhängen, wenn er fehlt.)

- Ich denke, er meinte, dass Hosts ohne abschließenden Punkt nur als Fehler abgeworfen werden sollten und nur absolute Domänen (fqdn) an dns übergeben werden sollten. Ich denke, wahrscheinlich haben Browser alle Domains an DNS übergeben, weil die Benutzer ihre benutzerdefinierten lokalen Top-Level-Domains wie "localhost" verwendet haben. Später in RFC 2396, veröffentlicht im Jahr 1998, wurde die Verwendung von Top-Level-Domains in URLs ohne nachgestellte Punkte erlaubt.

dann zitiert der autor (jonathan de boyne pollard) rfc 2396 und bedauert, dass sich dies aufgrund des etablierten menschlichen verhaltens geändert hat, dh de facto standarts alle Orte, wie es von RFC 1738 befohlen wurde.

- Aber was würde passieren, wenn die Leute RFC 1738 gehorchen würden? URLs wie "http://example.com/test.html "und"http: //localhost/test.html "alles musste neu geschrieben werden als"http://example.com./test.html "und"http://localhost./test.htmlmsgstr "" "Der Browser müsste entweder Hosts ohne Punkte als Fehler markieren oder umleiten, wenn er auf sie klickt, um eine vollständige oder absolute Form von Hosts zu erhalten. Alle Benutzer, die lokale Top - Level - Domains wie" localhost "konfiguriert haben, müssten ihre Server so konfigurieren, dass sie nur Anforderungen akzeptieren für Domains wie "localhost" oder akzeptieren und leiten Sie [alle URLs in] "localhost" zu [entsprechenden URLs in] "localhost" um. Text wie "localhost" würde nur dann nützlich bleiben, wenn er in die Adressleiste des Browsers eingegeben wird Dies wäre nur eine sehr nutzlose Nutzung, und die entsprechende Domain-Funktion wird dafür nicht benötigt, da Browser beim Tippen nach Domains suchen. Ihre Verwendung in HTML-Quellen würde nutzlos, da solche Links nicht funktionieren würden oder wenn Sie auf alle klicken würden Links mit "localhost" würden den Benutzer zu "localhost" verschieben."und es wäre nur eine zusätzliche Weiterleitung bei jedem Klick (auf solche Links). Daher würde RFC 1738 die geplante" relative Domain "-Funktion völlig unbrauchbar machen. Wenn ein Unternehmen diese Funktion verwendet und ihre relativen Domains in ihren lokalen Sites verwendet, und ihre URLs mit relativen Domänen wurden von Browsern nicht in die absolute Form umgeleitet, so dass ihre Websites normal funktionierten. Wenn sie auch RFC 1736 befolgten, würden sie ihre Server so konfigurieren, dass sie nur FQDN akzeptieren, und sie müssten entweder alle ihre solchen URLs mit neu schreiben fqdn oder arbeiten mit zusätzlicher Weiterleitung bei jedem Klick auf solche URLs. Wenn diese Unternehmen eine kurze Domain wie "team101" anstelle von "team101.microsoft.com" in ihren Adressleisten und HTML-Quellen hätten, müssten sie damit beginnen ihre benutzerdefinierten internen Top-Level-Domains wie "team101", dh wie "localhost. "anstelle von Subdomains wie" team101.microsoft.com. "

-

und ich habe herausgefunden, dass der abschließende Punkt, der von RFC 1738 so stark unterstützt wurde, wirklich erst nach dem Standard ohne abschließende Punkte erschien! Es erschien mit RFC 1034 im Jahr 1987, es ist im zweiten Link zitiert, und ich zitiere es:

Da ein vollständiger Domainname mit dem Root-Label endet, führt dies zu einem
gedruckte Form, die in einem Punkt endet. Wir verwenden diese Eigenschaft, um zu unterscheiden zwischen:
- eine Zeichenkette, die einen vollständigen Domainnamen darstellt
 (oft "absolut" genannt). Zum Beispiel "poneria.ISI.EDU".
- eine Zeichenkette, die die Anfangsbezeichnungen von a darstellt
 Domain-Name, der unvollständig ist und von ergänzt werden soll
 lokale Software mit Kenntnissen der lokalen Domäne (häufig
 genannt "relative"). Zum Beispiel "Poneria" in der
 ISI.EDU-Domain.

rfc 1034 (von 1987) hat gerade alle verwendeten Domains deklariert, anscheinend waren sie alle ohne nachgestellte Punkte, sie wurden alle zu relativen Domains! Aber sie arbeiteten immer noch wie zuvor, so dass wahrscheinlich nur wenige Leute davon wussten und weiterhin dachten, dass sie eindeutig eine echte "example.com" -Site anfordern, wenn sie "example.com" ohne nachgestellten Punkt verwenden. Dies ist in einigen Fällen zu einer zusätzlichen Sicherheitsverletzung geworden: Der berühmte echte example.com könnte von einem Subdomain-Administrator gefälscht werden, selbst wenn er nicht die Berechtigung hat, eine lokale Domain wie "localhost" zu erstellen. rfc 1034 wurde also auch nicht sehr gut entwickelt: anscheinend haben seine autoren nicht damit gerechnet, dass es vielleicht {nicht allgemein bekannt, so dass es sicherheitslücken gibt}!

wahrscheinlich versuchte rfc 1738 (1994) endlich, die Idee der Unterscheidung zwischen absoluten und relativen Domänen einem breiten Publikum nahe zu bringen und diese Sicherheitsverletzung nach 6 Jahren zu beheben, {aber indem die Sicherheitsverletzung behoben wurde, indem relative Domänen in URLs nicht zugelassen wurden, machten sie relative Domänen unbrauchbar , {aber ich denke, dass sie wahrscheinlich nicht weit verbreitet waren, wahrscheinlich nur in einigen großen Unternehmen}}. Also, was würde als Ergebnis von RFC 1737 übrig bleiben, wenn es befolgt würde? - 1) Relative Domains, die 1987 deklariert wurden, würden endgültig unbrauchbar werden, daher würde der abschließende Punkt, der die absolute Domain anzeigen soll, endgültig unbrauchbar und redundant werden, "legal", dh wie von der RFCS definiert! (Aber vielleicht haben sie geplant, relative Domains nach vielen Jahren wieder in URLs zuzulassen, wenn ein breites Publikum (allgemeine Öffentlichkeit) etwas über die Möglichkeit relativer Domains erfährt.) 2) und RFC 1737, Wenn es befolgt wurde, würde auch die Sicherheitsverletzung behoben. - Aber selbst RFC 1034 würde keine Sicherheitslücke schaffen, wenn es Massen erreichen würde und es wurde allgemein verstanden, dass die Verwendung einer relativen Domain nicht sicher ist! - Das Hauptrezept zur Behebung dieses Problems war es, ein breites Publikum zu erreichen, und die Veröffentlichung eines weiteren RFC war nur eine von vielen Möglichkeiten, dies zu erreichen.

Ich denke jetzt, dass wahrscheinlich die relative Domain-Funktion nach RFC 1034 (von 1987) nicht allgemein bekannt geworden ist, weil sie von zu begrenztem Nutzen war: nur in einigen großen Unternehmen oder lokalen Netzwerken von Anbietern, und es war eine Funktion ohne praktischen Wert. Da lokale Netzwerke bereits lokale Domains erstellen konnten, war diese Funktion nur für sich selbst bestimmt. Es handelte sich in der Tat um einen nutzlosen Text in RFC, den jeder kennen und verwenden sollte, ohne zusätzlichen Nutzen zu haben. Aber die Leute schufen die kleine Sicherheitslücke, indem sie den RFC weitgehend ignorierten, während die Browser begannen, ihm Folge zu leisten.

Ich habe gestern die Funktion für relative Domains überprüft, es funktioniert. (Es ist in Ordnung, weil RFC 2396 (von 1998) es wieder zuließ, nachdem RFC 1034 (von 1987) abgelehnt wurde, und später RFC 3986 (von 2005) es noch zulässt.) Ich fügte hinzu, DNS-Suffix in Windows 10 - Systemsteuerung - ... - Netzwerkgeräteigenschaften - IPv4-Eigenschaften - zusätzliche - DNS-Registerkarte. als ich "google.com" hinzufügte, öffnete ich "http: // mail / "in firefox hat googles server geöffnet, aber es war nicht so konfiguriert, dass es nur mit" mail "im http" host "-header funktioniert, also habe ich so etwas wie" 404 "-Seite.

-

meine Antwort auf den Text durch den zweiten Link ( http://www.dns-sd.org/trailingdotsindomainnames.html ):

er zitiert auch die Regel in RFC 1738 und sagt:

Leider schienen die Leute, die Webbrowser-Clients implementierten, nicht zu verstehen, was dies bedeutete. Wenn Sie auf eine Website zugreifen, geben die meisten Webbrowser im Feld "Host:" den Wert ein, den der Benutzer eingegeben hat, und nicht den, den der Computer tatsächlich verwendet hat, nachdem er die Suchliste des DNS-Benutzers angewendet hat, um einen vollständig qualifizierten Namen aus der Liste zu erstellen Teilname. Zum Beispiel kann der Benutzer auf drei verschiedene Arten auf den Host "www.example.com" verweisen. ... Wenn der Parameter "Host:" an den Webserver gesendet wird, gibt der Webbrowser-Client stattdessen ein, was der Benutzer eingegeben hat ("www.example.com", "www.example.com" oder "www") von dem, was der Client tatsächlich in DNS nachgeschlagen hat ("www.example.com" in allen drei Fällen). ...

- Dies ist nicht sehr wahr (richtig), da RFC 1738 in dieser Hinsicht sehr streng war und relative Domains in allen URLs unzulässig waren, selbst wenn sie in der Adressleiste des Browsers stehen und die URL selbst die [empfohlene] Methode ist Verweise auf Websites, auch wenn die Benutzer sie auf Papier schreiben, sodass es den Benutzern nicht gestattet war, auf diese Website auf diese drei Arten zu verweisen, laut RFC 1738, wenn diese Benutzer der Meinung wären, sie hätten URL verwendet!

Der Autor dieses Textes (Stuart Cheshire) wusste anscheinend nichts über RFC 2396, daher ist dieser Text veraltet.

-

und wie ist die situation heute? rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) ermöglicht den Verweis auf eine absolute Domain ohne abschließenden Punkt: "Auf die Domain-Bezeichnung ganz rechts eines vollqualifizierten Domainnamens im DNS kann möglicherweise eine einzige folgen". "" und dass es verwendet werden sollte, wenn "zwischen dem vollständigen Domainnamen und einer lokalen Domain unterschieden werden muss". Ich denke, dass es aufgrund von De-facto-Standards so gut wie nie notwendig ist, so dass WordPress den De-facto-Standard akzeptieren und von der Adresse mit dem abschließenden Punkt zur Adresse ohne diesen umleiten kann.