Pensez-y :
Quand je mets un point après l'URL du super utilisateur, https://superuser.com. il a agi comme si je n'étais pas connecté. Pourquoi cela se produit-il ? Que symbolise un point dans l'URL ?
Réponses
Trop de publicités?
L'ajout du point à la fin du nom de domaine en fait un nom de domaine absolu entièrement qualifié au lieu d'un nom de domaine ordinaire entièrement qualifié, et la plupart des navigateurs traitent les noms de domaine absolus comme étant un domaine différent du nom de domaine ordinaire équivalent (je ne suis pas sûr que por qué ils le font pourtant).
Un peu d'histoire :
Le système de noms de domaine est strictement hiérarchique, tout comme un système de fichiers ou un répertoire X.500/LDAP. Cependant, à la différence des systèmes de fichiers ou de X.500, la hiérarchie est présentée de droite à gauche et non de gauche à droite. Ainsi, le composant le plus à droite d'un nom de domaine est le sommet de la hiérarchie. Le fait de mettre un point à l'extrême droite d'un nom de domaine le rend absolu, ce qui signifie qu'il est explicitement enraciné au sommet de la hiérarchie DNS. En substance, c'est la même chose que d'utiliser un nom complet au lieu d'un nom commun dans une recherche X.500, ou de mettre un point à l'extrême droite d'un nom de domaine. / au début d'un chemin POSIX.
L'utilisation d'un FQDN absolu a quelques implications spécifiques sur la façon dont un système client cherchera l'enregistrement DNS pour ce domaine :
- Elle fait en sorte que certains résolveurs ignorent toute entrée définie localement (par exemple, elle fera en sorte que certains résolveurs ignorent
/etc/hostssur un système de type UNIX). - Lorsqu'il est utilisé avec le
.localil obligera certains systèmes à utiliser le mDNS au lieu du DNS traditionnel pour tenter de résoudre le nom. - Il fait en sorte que tous les résolveurs ignorent tout domaine de recherche configuré ou tout domaine DNS local lorsqu'ils recherchent le nom.
Cette dernière partie est la plus importante, et c'est la raison pour laquelle le concept de FQDN absolu existe. La plupart des systèmes peuvent être configurés avec ce que l'on appelle un domaine de recherche. Lorsqu'ils cherchent à résoudre un domaine donné, ils essaient d'abord de chercher dans tous les domaines de recherche configurés, et ne résolvent qu'à partir du sommet de la hiérarchie s'ils ne trouvent pas le nom dans l'un des domaines de recherche configurés (ainsi, si vous aviez foo.example configuré comme domaine de recherche sur votre système et que vous avez essayé d'accéder à bar.example dans un navigateur, il devrait (normalement, voir ci-dessous) essayer d'aller à bar.example.foo.example d'abord, et seulement s'il ne peut pas le trouver, il essaiera bar.example directement). De nos jours, la plupart des résolveurs, mais pas tous, ignorent le domaine de recherche lorsqu'ils résolvent un domaine qui se termine par un nom de domaine de premier niveau connu ( .com , .net ), il n'est donc généralement pas nécessaire pour la plupart des utilisateurs d'utiliser des FQDN absolus, et la plupart des gens ne les connaissent donc pas.
Bob
Points
58080
Cela s'explique par le fait que example.com y example.com. sont (parfois !) considérés comme des hôtes différents, pour deux raisons :
- Parce qu'ils peuvent en fait avoir des significations différentes, selon la configuration spécifique de votre réseau.
- Parce que les RFC de la norme Internet qui définissent la syntaxe le disent, selon la façon dont on les interprète.
Si le navigateur les considère comme des hôtes différents, il ne partagera pas l'état de la session (par exemple, les cookies) entre eux, de sorte qu'un "hôte" ne saura pas que l'autre vous a connecté.
Cela s'explique en partie par le fait que le navigateur peut ne pas savoir, en fonction de son implémentation, que les deux résolutions renvoient au même nom. En particulier s'il a transmis la résolution DNS à un résolveur distant et qu'il n'attend qu'une adresse IP en retour (plutôt que l'enregistrement complet).
Résumé
- Les deux hôtes peuvent en fait être différents, dans le monde réel.
- Il est parfois difficile de savoir comment les normes les considèrent. Il semble que de nombreuses normes d'application ne traitent pas explicitement de cette situation.
- Parmi celles qui décrivent la canonisation et la comparaison des noms de domaine, elles divisent généralement le nom en "étiquettes" individuelles.
- Tout dépend alors de la question de savoir si vous considérez que la forme absolue du nom de domaine possède un label nul supplémentaire, comme le stipule le RFC DNS original.
- Dans un monde idéal, toutes ces comparaisons se feraient en utilisant uniquement des noms de domaine absolus, et les noms relatifs ne seraient pas utilisés après la recherche initiale. Les navigateurs peuvent aussi considérer tous les noms comme absolus et interdire la recherche relative. Mais cela ne semble pas être le cas actuellement, et pourrait introduire d'autres problèmes.
- S'il n'est pas illégal pour un navigateur d'effectuer lui-même la recherche DNS (plutôt que d'utiliser les résolveurs du système d'exploitation) et donc de déterminer le nom de domaine absolu final, aucune norme que j'ai pu trouver ne l'exige.
Différences pratiques
La différence de signification est, comme Austin l'a noté, une conséquence de la façon dont les recherches DNS fonctionnent avec les suffixes de recherche. Votre étiquette typique non enracinée, par exemple example.com Dans ce cas, le résolveur DNS typique essaiera d'abord de rechercher les suffices définis sur votre système. Dans un environnement d'entreprise, il peut s'agir du domaine de l'entreprise, par exemple si vous disposez de mycompany.example. défini comme un suffixe de recherche, alors toute recherche de example.com va d'abord essayer example.com.mycompany.example. . C'est utile si vous voulez rechercher un serveur interne sans avoir à taper tout le domaine entièrement qualifié ("complet").
Mais que faire si vous voulez vraiment que le public example.com ? Vous pouvez utiliser la terminaison . sous la forme example.com. afin d'indiquer au résolveur que vous avez saisi un nom absolu ("complet") et qu'il ne doit pas essayer d'effectuer des recherches relatives en utilisant des suffixes de recherche.
Comment les normes Internet voient la situation
Il y a quelques endroits où nous devons examiner la manière dont ces éléments sont normalisés, et malheureusement les eaux peuvent être un peu boueuses. J'ai l'habitude de rechercher d'abord la norme la plus pertinente et de remonter à partir de là, mais comme il s'agit d'un sujet très dispersé, il est peut-être plus facile de commencer par le bas.
Noms de domaine
Norme Internet RFC1034 décrit les noms de domaine dans section 3.1 et spécifie la "syntaxe de nom préférée" pour les noms de domaine dans les documents suivants section 3.5 . Notez dans la section 3.1 :
Chaque nœud possède une étiquette, d'une longueur de zéro à 63 octets. Les nœuds de Brother ne peuvent pas avoir la même étiquette, bien que la même étiquette puisse être utilisée pour des nœuds qui ne sont pas frères. Une étiquette est réservée, il s'agit de l'étiquette nulle (c'est-à-dire de longueur zéro) utilisée pour la racine.
[...]
Lorsqu'un utilisateur doit taper un nom de domaine, la longueur de chaque étiquette est omise et les étiquettes sont séparées par des points ("."). Comme un nom de domaine complet nom de domaine complet se termine par l'étiquette racine, cela conduit à une forme imprimée qui se termine par un point. Nous utilisons cette propriété pour faire la distinction entre :
une chaîne de caractères qui représente un nom de domaine complet (souvent appelé "absolu"). Par exemple, "poneria.ISI.EDU".
une chaîne de caractères qui représente les étiquettes de départ d'une nom de domaine qui est incomplet, et qui doit être complété par logiciel local utilisant la connaissance du domaine local (souvent appelé "relatif"). Par exemple, "poneria" utilisé dans le domaine ISI.EDU.
Les noms relatifs sont pris soit par rapport à une origine bien connue, soit par rapport à une liste de domaines utilisée comme liste de recherche. Les noms relatifs apparaissent surtout à l'interface utilisateur, où leur interprétation varie de d'une implémentation à l'autre, et dans les fichiers maîtres, où ils sont relatifs à un nom de domaine d'origine unique. L'interprétation la plus courante utilise la racine "." comme origine unique ou comme l'un des membres de la liste de recherche. de la liste de recherche, de sorte qu'un nom relatif à plusieurs étiquettes est souvent un nom dans lequel le point de fin a été omis pour éviter la saisie.
URIs
À partir de là, nous pouvons voir comment les noms de domaine sont utilisés dans les URI, les normes Internet. RFC3986 . Sur section 3 nous voyons la syntaxe de l'URI. La partie qui nous intéresse est le autorité qui contient un hôte (suivi d'une option : port). Ceci est défini plus en détail dans section 3.2.2 en particulier la partie qui parle d'une nom enregistré :
Un nom enregistré destiné à être consulté dans le DNS utilise la syntaxe suivante définie dans la section 3.5 de [RFC1034] et la section 2.1 de [RFC1123]. Un tel nom consiste en une séquence d'étiquettes de domaine séparées par ".", chaque étiquette de domaine commençant et se terminant par un caractère alphanumérique et peut également contenir des caractères "-". L'étiquette de domaine la plus à droite d'un nom de domaine pleinement qualifié dans le DNS peut être suivi d'un seul ". suivi d'un simple "." et doit l'être s'il est nécessaire de faire la distinction entre le nom de domaine complet et certains lieux. le nom de domaine complet et un domaine local.
Cela nous ramène aux suffrages de recherche et à la possibilité qu'un "domaine local" donne un résultat différent du "domaine complet". Rappelez-vous que conceptuellement, selon la RFC1034, example.com. est équivalent à example.com.<root> où <root> est l'étiquette spéciale nulle.
Il y a une discussion sur la normalisation dans section 6 mais rien sur l'hôte, et encore moins sur les points de suspension.
Norme proposée RFC 7230 qui définit HTTP/1.1, indique qu'il suit largement la RFC3986 pour les définitions d'URI dans les documents suivants section 2.7 .
TLS
C'est là que les choses deviennent confuses.
Information RFC2818 décrit HTTP over TLS (HTTPS). Il ne dit rien d'explicite sur la correspondance des hôtes, à part le fait de suivre les règles de la RFC2459 (remplacée par la Proposed Standard RFC5280 ). Cela renvoie à la RFC1034 (celle qui a défini le DNS), mais ne dit rien d'explicite sur les adresses absolues ou les points de fin de ligne.
Norme proposée RFC6125 est une approche plus moderne de l'utilisation de TLS. Elle traite davantage de la correspondance des noms de domaine, mais n'aborde pas non plus explicitement les points de fin de ligne. Elle précise toutefois que vous êtes censé ne faire correspondre que les "noms de domaine pleinement qualifiés" (ce concept est étonnamment mal défini). Il précise que tous les étiquettes doit correspondre - ce qui remonte à la RFC1034, et si nous considérons que le null-label représente la racine, alors example.com y example.com. ont des étiquettes différentes (cette dernière a 3, example , com y <root> ).
Il y a une discussion dans Bogue Mozilla 134402 sur les différentes interprétations.
Cookies
En nous éloignant un peu de TLS, nous pouvons examiner les cookies dans la norme proposée. RFC6265 . Voilà, section 5.1.2 y section 5.1.3 parler de la canonisation et de la correspondance des noms d'hôtes. Ici encore, nous divisons le nom d'hôte en étiquettes individuelles pour effectuer la canonisation (qui convertit essentiellement les noms de domaine Unicode en minuscules ASCII/punycode). Et, encore une fois, cela dépend si vous considérez que l'étiquette nulle représentant la racine a été préservée par cette étape de canonisation. Si c'est le cas, alors ils ont des étiquettes différentes, et sont donc des hôtes différents pour les besoins des cookies.
harrymc
Points
394411
L'explication donnée par Mokubai est exactement correcte, et le problème est dans le navigateur n'identifie pas qu'il s'agit du même domaine et donc n'envoie pas les envoyer les cookies.
Mais la situation est encore pire : le point à la fin ne fait que marquer le domaine en tant que fully-qualified (sans ambiguïté), ce qui fonctionne très bien avec le DNS, puisque le message arrive finalement à la bonne adresse ( superuser.com ).
J'ai même obtenu de Fiddler ce dialogue pour superuser.com. (avec point) :
Avec quelques tests empiriques, voici les en-têtes envoyés avec ces deux requêtes.
https://superuser.com (informations sensibles barrées)
https://superuser.com. (avec point, aucune information sensible ne doit être barrée)
Conclusion : Le problème vient du fait que le navigateur n'ignore pas un point à la fin de un nom de domaine entièrement qualifié, comme le permet la norme DNS.
Remarque supplémentaire : Les développeurs du navigateur n'ont pas été les seuls à tomber dans ce piège. J'ai installé le module complémentaire NoScript pour arrêter tout JavaScript, mais superuser.com (sans point) est autorisé à passer. Mais NoScript bloque toujours superuser.com. (avec un point) comme étant un site web inconnu. Je ne doute pas que les tests trouveraient le même comportement dans de nombreux autres produits.
Il est étrange que les développeurs des principaux acteurs du domaine du Web, comme Google Chrome, Firefox et Fiddler de Microsoft, tous responsables de nombreuses avancées dans les standards du Web, n'aient pas prêté attention à cette possibilité.
