Consider:
スーパーユーザーURLの後にドットを入れると、https://superuser.com.のようにログインしていないかのように振舞ってしまいました。なぜこのようなことが起こるのでしょうか？URLのドットは何を象徴しているのでしょうか？
188 Riley Carney 2019-08-05
ドメイン名の末尾にドットを追加すると、通常の完全修飾ドメイン名ではなく絶対的な完全修飾ドメイン名になり、ほとんどのブラウザは絶対的なドメイン名を同等の通常のドメイン名とは別のドメインとして扱います（なぜこのような扱いをするのかはよくわかりませんが）
背景を少し
ドメイン名システムはファイルシステムや 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 に行こうとし、それが見つからなかった場合にのみ bar.example に直接行こうとします) 。最近のリゾルバのほとんど(すべてではないが)は、既知のトップレベルドメイン名(.com, .netなど)で終わるドメインを解決する際に検索ドメインを無視するので、ほとんどのユーザーが絶対FQDNを使用する必要がなく、したがってほとんどの人はそれを知らない
192 Austin Hemmelgarn 2019-08-05
これは、example.comとexample.com.が(ときどき！)別のホストとみなされるのは、2つの理由があるからです
- なぜなら、それらは実際には、特定のネットワーク構成に応じて異なる意味を持つことができるからです
- なぜなら、構文を定義しているインターネット標準RFCがそう言っているからです
ブラウザがそれらを別のホストとみなした場合、セッションの状態（クッキーなど）はそれらの間で共有されないので、一方の「ホスト」は他方の「ホスト」がログインしていることを知らないでしょう
これの一部は、ブラウザの実装によっては、この二つが実際に同じ名前に解決されていることを知らないかもしれないということです。特に、DNS の解決をリモートリゾルバに渡して、IP アドレスだけを返すことを期待している場合は特にそうです (拡張レコード全体ではなく)
Summary
- 2人のホストは現実世界では実は違っていたりします
- 標準がどのように捉えているのかが不明瞭なことがあります。多くのアプリケーション標準では、明示的に対応していないようです
- ドメイン名の正規化と比較を記述しているもののうち、通常は個々の “ラベル “に分かれている
- そうすると、オリジナルのDNS RFCが述べているように、ドメイン名の絶対形にヌルラベルが追加されていると考えるかどうかにかかっています
- 理想的な世界では、これらの比較はすべて絶対的なドメイン名のみを使用して行われ、相対的な名前は元のルックアップを超えて使用されません。あるいは、ブラウザがすべての名前を絶対的なものとみなし、相対的な検索を許可しないようにすることもできます。しかし、これは現在のところそうではないようで、別の問題が発生する可能性があります
- ブラウザが(OSリゾルバを使用するのではなく)DNSルックアップを実行し、最終的な絶対ドメイン名を把握することは違法ではないかもしれませんが、私が見つけたどの標準規格でもこれは要求されていません
Practical differences
異なる意味の部分は、Austinが指摘したように、DNSの検索結果が検索語句でどのように動作するかの結果である。典型的な非ルートラベル、例えばexample.comは、典型的なDNSリゾルバが最初にシステムで定義されている検索語句を試すことになります。企業環境では、これは会社のドメインである可能性があります。例えば、mycompany.example.を検索サフィックスとして定義している場合、example.comを検索する際には、まずexample.com.mycompany.example.を試します。これは、完全修飾された（「完全な」）ドメイン全体を入力しなくても内部サーバーを検索したい場合に便利です
しかし、実際にパブリックな example.com が必要な場合はどうでしょうか？example.com. の形で . の後に続く . を使うことで、絶対的な (「完全な」) 名前を入力したことをリゾルバに伝え、検索結果に対して相対検索を行わないようにすることができます
インターネット標準はどのように見ているのか
これらがどのように標準化されているかを調べる必要がある場所がいくつかあり、残念ながら水域は少し濁っています。私は通常、最初に最も関連性の高い規格を探して、そこから戻るのが好きなのですが、これだけ散らばっているのですから、最初から始めた方が簡単かもしれません
Domain names
インターネット標準 RFC1034 にドメイン名についての記述があり、第3.1節 にドメイン名の「好ましい名前の構文」についての記述があります。第3.1節の注釈
各ノードはラベルを持ち、長さは0～63オクテットです。兄弟ノードは同じラベルを持つことはできませんが、兄弟ではないノードには同じラベルを使用することができます。1つのラベルが予約されており、それはルートに使用されるヌル（つまり長さゼロ）ラベルです
[…]
ユーザがドメイン名を入力する必要がある場合、各ラベルの長さは省略され、ラベルはドット(“.”)で区切られる。完全なドメイン名はルートラベルで終わるので、これはドットで終わる印刷されたフォームにつながります。このプロパティを使って区別しています
完全なドメイン名を表す文字列 (「絶対」と呼ばれることが多い)。例えば、”poneria.ISI.EDU.” のようになります
不完全なドメイン名の開始ラベルを表す文字列で、ローカルのソフトウェアがローカルドメインの知識を使って完成させる必要があります (しばしば “相対 “と呼ばれます)。例えば、ISI.EDUドメインで使われている “poneria”
相対名は、よく知られたオリジンに対する相対名か、検索リストとして使用されるドメインのリストに対する相対名のいずれかである。相対名は主にユーザインタフェースに表示されますが、その解釈は実装によって異なり、マスターファイルでは単一のオリジンドメイン名への相対名となります。最も一般的な解釈では、ルートの”. “を単一の起源または検索リストのメンバーのいずれかとして使用するので、マルチラベルの相対名は、入力を節約するために末尾のドットが省略されている場合が多いです
URIs
そこから、ドメイン名がどのようにURIで使われているか、インターネット標準RFC3986に行くことができます。セクション3では、URIの構文を見ています。私たちが興味を持っている部分は権限で、ホスト(その後にオプションの:ポートが続く)を含んでいます。これはsection 3.2.2.2でさらに定義されており、特に登録された名前について述べています
DNSでの検索を目的とした登録名は、[RFC1034]のセクション3.5および [RFC1123]のセクション2.1で定義されている構文を使用する。このような名前は、”. “で区切られた一連のドメインラベルで構成され、 各ドメインラベルは英数字で始まり、最後に「-」文字を含む場合もある。DNSにおける完全修飾ドメイン名の右端のドメインラベルの後には、単一の”. “が続くことがあり、 完全なドメイン名といくつかのローカルドメインを区別する必要がある場合には、そうすべきである
ここで、検索の満足度と、”ローカルドメイン “が “完全なドメイン “とは異なる結果にマッチする可能性に話が戻ってきます。概念的には、RFC1034によれば、example.com.はexample.com.<root>と同等であり、<root>は特別なヌルラベルであることを覚えておいてください
セクション6には正規化についての議論がありますが、ホストについては何もありません
HTTP/1.1を定義しているProposed Standard RFC 7230は、セクション2.7のURI定義については、ほぼRFC3986に従っていることを指摘しています
TLS
ここで混乱してしまうのです
情報提供 RFC2818 は、HTTP over TLS (HTTPS) について記述しています。RFC2459 (Proposed Standard RFC5280 に置き換えられました) のルールに従うことを除けば、ホストのマッチングについては何も明示的には書かれていません。これは RFC1034 (DNS を定義したもの) を参照していますが、絶対アドレスや末尾のドットについては何も明示していません
提案された規格 RFC6125 は、TLS の使用法をより現代的に解釈したものです。これはドメイン名のマッチングについてより多くのことを語っていますが、最後のドットについてはまたしても明示的には言及していません。すべてのラベルがマッチしなければならないと言っています – これはRFC1034にさかのぼりますが、もしヌルラベルをルートを表すものと考えるならば、example.comとexample.com.は異なるラベルを持っています(後者は3つ、example、com、<root>)
Mozilla bug 134402 で、解釈の違いについていくつかの議論が行われています
Cookies
TLS から少し離れて、Proposed Standard RFC6265 のクッキーを見てみましょう。そこでは、section 5.1.2 と section 5.1.3 がホスト名の正規化とマッチングについて述べています。ここでも、私たちはホスト名を個々のラベルに分割して正規化(これは本質的にUnicodeドメイン名をASCII/punycode小文字に変換します)を実行します。また、ルートを表すヌルラベルをこの正規化ステップで保存されていると考えるかどうかにもかかっています。もしそうならば、それらは異なるラベルを持っていて、クッキーの目的のためには異なるホストです
56 Bob 2019-08-06
モクバイさんの説明はまさにその通りで、問題はブラウザがこれが同じドメインであることを認識していないためにクッキーを送信していないことにあります
しかし、状況はさらに悪い: 末尾のドットはドメインを完全修飾 (unambiguous) したものとしてマークするだけで、これはDNSでは非常にうまく機能します
Fiddler から superuser.com. (ドット付き) のダイアログを取得したこともあります
いくつかの経験的なテストで、これらの2つのリクエストで送信されたヘッダを以下に示します
https://superuser.com（機密情報はクロスアウト）
https://superuser.com.（ドット付きで、機密情報はクロスアウトする必要はありません）
結論。問題は、DNS標準ではかなり可能なことですが、ブラウザが完全修飾ドメイン名の末尾のドットを無視していないことです
更なる指摘。この罠に陥ったのはブラウザ開発者だけではありません。私はNoScriptアドオンをインストールしてすべてのJavaScriptを停止させていますが、superuser.com (ドットなし)は通過を許可しています。しかし、NoScript はまだ superuser.com. (ドット付き) を未知のウェブサイトとしてブロックしています。テストすれば、他の多くの製品でも同じような挙動が見られることは間違いありません
Google ChromeやFirefox、MicrosoftのFiddlerなど、Web標準の多くの進歩を担ったWebドメインの主要アクターの開発者たちが、この可能性に注目していないのは不思議なことだ
20 harrymc 2019-08-05
