URLの後にドットを付けるとログイン情報が削除されるのはなぜですか？

Question

考慮してください：

スーパーユーザーのURLの後にドットを付けると、https://superuser.com.、ログインしていないように見えました。なぜこれが起こっているのですか？ドットはURLで何を表していますか？

Austin Hemmelgarn · Accepted Answer

ドメイン名の最後にドットを追加すると、通常の完全修飾ドメイン名ではなく、完全完全修飾ドメイン名になり、ほとんどのブラウザは、絶対ドメイン名を同等の通常ドメイン名とは異なるドメインとして扱います（Iわからないなぜ彼らはこれをします）。

背景のビット：

ドメインネームシステムは、ファイルシステムやX.500/LDAPディレクトリのように、厳密に階層構造になっています。ただし、ファイルシステムやX.500とは異なり、階層は左から右ではなく右から左にリストされます。したがって、ドメイン名の右端のコンポーネントは階層の最上位です。ドメイン名の右端にドットを付けると、絶対的になります。つまり、DNS階層の最上位に明示的にルートが置かれます。本質的には、X.500ルックアップで共通名の代わりに完全な識別名を使用すること、またはPOSIXパスの先頭に/を置くことと同じです。

絶対FQDNを使用すると、クライアントシステムがそのドメインのDNSレコードを検索する方法にいくつかの特定の影響があります。

これにより、一部のリゾルバーはローカルに定義されたエントリーをスキップします（たとえば、一部のリゾルバーは、UNIXのようなシステムでは/etc/hostsを無視します）。
.localドメインと一緒に使用すると、一部のシステムでは、従来のDNSではなくmDNSを使用して名前を解決しようとします。
これにより、名前を検索するときに、すべてのリゾルバーが構成済みの検索ドメインまたはローカルDNSドメインを無視します。

その最後の部分は重要な部分であり、絶対FQDNの概念が存在する理由です。ほとんどのシステムは、いわゆる検索ドメインで構成できます。特定のドメインを解決しようとすると、設定された検索ドメインの下を最初に探し、設定された検索ドメインで名前が見つからない場合のみ階層の最上位から解決します（つまり、foo.exampleをシステムで検索ドメインとして設定し、ブラウザでbar.exampleにアクセスしようとすると、（通常、以下を参照）最初にbar.example.foo.exampleにアクセスしようとしましたが、アクセスできなかった場合のみt bar.exampleを直接試してみてください）。すべてではありませんが、最近のほとんどのリゾルバーは、既知のトップレベルドメイン名（.com、.netなど）で終わるドメインを解決するときに検索ドメインを無視するため、通常ほとんどの場合必要ありませんユーザーは絶対FQDNを使用するため、ほとんどの人はそれらについて知りません。

Bob · Answer

これは、2つの理由により、example.comとexample.com.が（ときどき！）異なるホストと見なされるためです。

特定のネットワーク構成に応じて、実際には異なる意味を持つ可能性があるためです。
構文を定義するインターネット標準RFCは、それらをどのように解釈するかに応じてそう言うからです。

ブラウザーがそれらを異なるホストと見なす場合、ブラウザーはそれらの間でセッション状態（Cookieなど）を共有しないため、一方の「ホスト」は他方がログインしていることを認識しません。

これの一部は、実装によっては、2つが実際に同じ名前に解決されることをブラウザが知らない可能性があることです。特に、DNS解決をリモートリゾルバーに渡し、拡張されたレコード全体ではなく、IPアドレスのみが返されることを期待している場合は特にそうです。

概要

2つのホストは、実際には異なる場合があります。
規格がそれらをどのように見ているかは時々不明瞭です。多くのアプリケーション標準は状況を明示的に扱っていないようです。
ドメイン名の正規化と比較を説明するもののうち、通常は名前を個別の「ラベル」に分割します。
次に、元のDNS RFCが述べているように、ドメイン名の絶対形式が追加のnullラベルを持つと考えるかどうかにかかっています。
理想的な世界では、これらすべての比較は絶対ドメイン名のみを使用して行われ、相対名は元のルックアップを超えて使用されません。または、ブラウザはすべての名前を絶対的なものとして取り、相対検索を許可しないこともできます。しかし、これは現在のところそうではなく、他の問題を引き起こす可能性があります。
- ブラウザが（OSリゾルバを使用するのではなく）DNSルックアップ自体を実行して最終的な絶対ドメイン名を把握することは違法ではないかもしれませんが、これは私が見つけたどの標準でも必要ありません。

実用的な違い

オースティンが述べたように、異なる意味の部分は、DNSルックアップが検索でどのように機能するかによる結果で十分です。あなたの典型的な非根付いたラベル、例えばexample.comを指定すると、通常のDNSリゾルバーは、最初にシステムで定義されているすべての検索を試行します。企業環境では、これは会社のドメインである場合があります。 mycompany.example.を検索サフィックスとして定義している場合、example.comの検索では、最初にexample.com.mycompany.example.が試行されます。これは、完全修飾（「完全」）ドメイン全体を入力せずに内部サーバーを検索する場合に便利です。

しかし、実際に公開したい場合はどうでしょうexample.com？末尾の.をexample.com.の形式で使用して、絶対（「完全」）名を入力したことをリゾルバに通知し、検索の十分な相対検索を行わないようにすることができます。

インターネット標準が状況をどう見るか

これらがどのように標準化されているかを探す必要がある場所がいくつかありますが、残念ながら水は少し濁っています。私は通常、最初に最も関連性の高い標準を探してそこから戻るのが好きですが、これは非常に散在しているため、下から開始する方が簡単かもしれません。

ドメイン名

インターネット標準 RFC1034 はドメイン名をセクション3.1 で説明し、ドメイン名の「優先名構文」をセクション3.5 で指定します。セクション3.1の注：

各ノードにはラベルがあり、長さは0〜63オクテットです。兄弟でないノードには同じラベルを使用できますが、兄弟ノードには同じラベルがない場合があります。 1つのラベルが予約されています。これは、ルートに使用されるnull（つまり、長さがゼロ）のラベルです。

[...]

ユーザーがドメイン名を入力する必要がある場合、各ラベルの長さは省略され、ラベルはドット（ "。"）で区切られます。完全なドメイン名はルートラベルで終わるので、ドットで終わる印刷されたフォームになります。このプロパティを使用して、次のものを区別します。

完全なドメイン名（しばしば「絶対」と呼ばれる）を表す文字列。たとえば、「poneria.ISI.EDU」です。

不完全なドメイン名の開始ラベルを表す文字列。ローカルドメインの知識を使用してローカルソフトウェアで完成させる必要があります（「相対」と呼ばれることが多い）。たとえば、ISI.EDUドメインで使用されている「poneria」。

相対名は、よく知られたオリジンまたは検索リストとして使用されるドメインのリストを基準にして取得されます。相対名は主にユーザーインターフェースに表示されますが、その解釈は実装ごとに異なり、マスターファイルには単一のOriginドメイン名に関連しています。最も一般的な解釈では、ルート「。」を使用します。単一のOriginまたは検索リストのメンバーのいずれかとして、したがって、マルチラベルの相対名は、多くの場合、入力を節約するために末尾のドットが省略されている名前です。

URI

そこから、URI、インターネット標準 RFC3986 でのドメイン名の使用方法に進むことができます。セクションには、URI構文が表示されます。私たちが関心を持っている部分は、authorityで、Hostが含まれています（オプションの:ポートが後に続きます）。これはセクション3.2.2 、特に登録名について話す部分でさらに定義されています。

DNSでの検索を目的とした登録名は、[RFC1034]のセクション3.5および[RFC1123]のセクション2.1で定義された構文を使用します。このような名前は、「。」で区切られた一連のドメインラベルで構成され、各ドメインラベルは英数字で始まり、英数字文字で終わり、「-」文字も含まれる場合があります。 DNSの完全修飾ドメイン名の右端のドメインラベルの後には、単一の「。」が続く場合があります。完全なドメイン名と一部のローカルドメインを区別する必要がある場合に使用します。

これにより、検索が十分になり、「ローカルドメイン」が「完全なドメイン」とは異なる結果に一致する可能性が戻ります。 RFC1034によれば、概念的には、example.com.はexample.com.<root>と同等であり、<root>は特別なnullラベルであることを覚えておいてください。

セクション6 で正規化についての議論がありますが、ホストについては何もありません。

提案された標準 RFC 72 （HTTP/1.1を定義）は、それがセクション2.7 のURI定義に関してRFC3986にほぼ準拠していると述べています。

TLS

これが混乱を招くところです。

情報 RFC2818 は、HTTP over TLS（HTTPS）について説明します。 RFC2459（提案された標準 RFC528 に置き換えられました）のルールに従うことを除いて、ホストマッチングについては何も明示されていません。これは、RFC1034（DNSを定義したもの）を参照していますが、絶対アドレスや末尾のドットについては何も明示していません。

提案された標準 RFC6125 は、TLSの使用に関するより現代的な見方です。ドメイン名のマッチングについて詳しく説明しますが、ここでも末尾のドットについては明示的に触れていません。それはすべてのlabelsが一致する必要があることを示しています-これはRFC1034に戻り、null-labelがルートを表すと見なす場合、example.comとexample.com.には異なるラベルがあります（後者には3、example、comと<root>があります）。

Mozillaバグ134402 には、さまざまな解釈についての議論があります。

クッキー

TLSから少し離れると、提案された標準 RFC6265 でCookieを確認できます。そこで、セクション5.1.2 およびセクション5.1. は、ホスト名の正規化と照合について説明します。ここでも、ホスト名を個々のラベルに分割して正規化を実行します（これにより、基本的にUnicodeドメイン名がASCII/punycode小文字に変換されます）。また、ルートを表すnullラベルがこの正規化手順を通じて保持されたと見なすかどうかにも依存します。使用する場合、ラベルが異なるため、Cookieの目的で異なるホストになります。

harrymc · Answer

Mokubaiによる説明は正確であり、問題は、ブラウザーがこれが同じドメインであることを識別しないため、Cookieを送信しないことです。

しかし、状況はさらに悪化します。最後のドットはドメインを完全修飾（あいまいでない）としてマークするだけで、メッセージは最終的に正しいアドレス（superuser.com）。

私はFiddlerからこのダイアログをsuperuser.com.（ドットあり）：

いくつかの実証的なテストで、これらの2つの要求で送信されるヘッダーを次に示します。

https://superuser.com（機密情報に取り消し線が引かれています）

https://superuser.com.（ドット付きで、機密情報に線を引く必要はありません）

結論：問題は、ブラウザが完全修飾ドメイン名の末尾のドットを無視しないことにあります。これは、DNS標準ではかなり可能です。

補足：このトラップに陥ったのはブラウザ開発者だけではありませんでした。すべてのJavaScriptを停止するためにNoScriptアドオンをインストールしていますが、superuser.com（ドットなし）は許可されます。しかし、NoScriptはまだブロックしますsuperuser.com.（ドット付き）が不明なWebサイトである。テストが他の多くの製品で同じ動作を見つけることは間違いありません。

Google Chrome、Firefox、MicrosoftのFiddlerなど、Web標準の多くの進歩に責任を持つWebドメインの主要な関係者の開発者が、この可能性に注意を払っていないのは奇妙です。