web-dev-qa-db-ja.com

Webサイトはホスト名の末尾にドットをどのように処理する必要がありますか？

私はこの質問を読みます RLの末尾にドット。を付ける方法、たとえばwww.bla.de.? とFQDNがDNSのルートラベルの末尾.を含む必要があることを理解します木：

example.com.の代わりにexample.com

ただし、 このブログ記事 で指摘されているように問題があります：

ユーザーが誤って末尾にドットを含むドメイン名を入力したり、「ウェルウィザー」から受け取ったリンクをたどって、末尾にドットを含むドメイン名にアクセスできるという事実を考慮しない場合結果、予期しない結果につながる可能性があります。

1）WebサイトがHTTPSを使用している場合、最後にドットが付いたドメイン名に移動すると、ブラウザーは信頼できない接続に関する警告を表示します。

2）Cookieは通常、末尾にドットのないドメイン名に設定されるため、認証が壊れる場合があります。この場合、ユーザーはログインできない理由に非常に驚かされます。最後にドットを含むドメイン名のCookieを設定すると、このCookieはドットなしのドメイン名に渡されないことに注意してください最後に、逆も同様です。

3）ページ上のJavaScriptが壊れている可能性があります。

4）Webサイトページのキャッシュに問題がある可能性があります（たとえば、ドメイン名に無効なドメイン名が最後にドットがある場合、https://www.cloudflare.com/はページキャッシュをクリアしません）。

5）Webサーバー設定の条件で、末尾にドットのない特定のドメイン名（Nginxの$ http_Host、Apacheの％{HTTP_Host}）に依存している場合、予期しないリダイレクト、基本的なさまざまな状況に直面する可能性があります-承認の問題など.

6）末尾にドットが付いたドメイン名のリクエストを受け入れるようにWebサーバーが構成されていない場合、末尾にドットが付いたドメイン名を誤って入力したユーザーには、不正なリクエスト-無効なホスト名などが表示されます。

7）ドメイン名の末尾にドットが付いたWebページへのリンクを誤ってまたは意図的に誰かが投稿すると、検索エンジンがリソースに重複したコンテンツを見つける可能性があります。

また、http://webmasters.stackexchange.com./が400 Bad Requestを実行することも理解しています。しかし、適切なドメイン名には最後に.が含まれている必要があるため、末尾にドットのないホスト名に対して400エラーまたは301リダイレクトを発行すべきではありませんか？一貫した一貫した方法でこの問題に対処する適切な方法は何ですか？

domainsurl
15
user47113

質問に部分的に答えるには、htaccessの標準フォワーダールールに追加します。基本的なHTTPの意味では、URIの前の期間を探して、使用する複製防止転送メカニズムに作用します。一般的な「アドオンドメイン」サブユーティリティルートを含む例を次に示します。

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]

これにより、次のすべてが正規のHTTP wwwドメインに転送されます。

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

すべての転送先：

ただし、これには注意点があります-元のブログの引用に記載されているように、SSLは正しく転送されず、ブラウザの警告または400の不正なリクエストエラーが発生しますほとんどのサーバーインスタンス（HSTSのesp）。これは、TLD期間後のユースケースで「ホスト」SSLを認識するためです。 htaccessなどの前に来るので、ホストSSL警告に対処する回避策がわかりません。

3
dhaupin

https://core.trac.wordpress.org/ticket/35248#comment:9 での私のコメント：

最初のリンク（ https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGAによるテキストへの返信/web-fully-qualified-domain-name.html ）：

もともと、RFC 1738（§3.1）で定義されているように、（Common Internet Scheme）URLの「ホスト」部分は常に明確な完全修飾ドメイン名であり、完全修飾ドメイン名と非完全ドメイン名を区別する従来のメカニズムでした。修飾ドメイン名は適用されませんでした。 example.comかどうか。またはexample.comの場合、ホストは同じであることが意図されていました。

-彼は正しくないと思います。rfc1738によると、「example.com」はURLでまったく許可されていないと思います。2番目のテキストで引用されています。

3.1。一般的なインターネットスキームの構文
 //<user>:<password>@<Host>:<port>/<url-path>
 Host 
の完全修飾ドメイン名ネットワークホスト

rfc 1738は1994年であり、ホストフィールドは1997年にhttp 1.1でのみ表示されたため、「example.com」はその時点でhttpヘッダーで使用できませんでした（ウィキペディアで確認できます）。

そのため、実際には、URLにはfqdnのみが許可されたままでした。私は、これがrfc 1738のエラーだったと思います。なぜなら、そのような方法で「相対ドメイン」機能が役に立たないようにした（作ろうとした）からです。ブラウザやサーバーがサポートしていれば、理論的には、ローカルスクリプトサイトの「a」タグhrefまたは相対ドメインを使用する大企業内の静的htmlドキュメントで使用できます。しかし、RFC 1738がそれらを禁止したとしても、人々はそれに従わなかった：彼らは相対的な形式で、すなわち末尾のドットなしでトップレベルドメインを使い続けたので、とにかくrfc 1738によるこの禁止は大きな実用的な問題ではなく、人々は代替手段を持っていた相対ドメインへ：「localhost」のようなローカルのトップレベルドメインを作成しました（また、末尾のドットなしで使用および使用します）。

彼は言う：

残念ながら、実際にはWebブラウザーは常にその仕様に違反しており、ホスト名をIPアドレスのセットにマッピングするときに、DNSクライアントライブラリの名前修飾手順で「ホスト」部分を渡しました。 （たとえば、BIND DNSクライアントライブラリを使用したものは、RES_DNSRCHオプションを設定したままにし、最後のドットが欠落している場合は追加しません。）

-末尾のドットのないホストはエラーとして破棄されるべきであり、絶対ドメイン（fqdn）のみがdnsに渡されるべきだと彼は言ったと思います。 「localhost」などのカスタムローカルトップレベルドメインを使用しているため、おそらくブラウザはすべてのドメインをDNSに渡したと思います。とにかく、1998年に公開されたrfc 2396では、URLの末尾にドットなしのトップレベルドメインの使用が許可されました。

著者（Jonathan de Boyne Pollard）は、rfc 2396を引用し、確立された人間の行動、つまり事実上の標準に従って変更されたことについて後悔し、ブラウザがrfc 1738に従えばよいと言い、すべての人にfqdnのみを使用することを推奨します。 rfc 1738によって命令されたすべての場所。

-しかし、人々がrfc 1738に従うとどうなりますか？ 「 http://example.com/test.html 」および「 http：// localhost/test。 html "すべてを" http://example.com./test.html "および" -に書き換える必要がありました http://localhost./test.html "。ブラウザは、ドットのないホストをエラーとしてマークするか、クリックしたときにホストを完全/絶対形式にリダイレクトする必要があります。 「localhost」などのローカルトップレベルドメインを設定したすべてのユーザーは、「localhost」などのドメインのリクエストのみを受け入れるようにサーバーを設定する必要があります。 、または[localhost]の[すべてのURL]を受け入れてリダイレクトし、[localhost。]の[対応するURL]にリダイレクトします。 「localhost」などのテキストは、ブラウザのアドレスバーに入力する場合にのみ有用ですが、それはあまり役に立たない使用方法であり、ブラウザは入力時にドメインを検索するため、相対ドメイン機能は必要ありません。 htmlソースでそれらを使用すると、そのようなリンクが機能しなくなるか、「localhost」のすべてのリンクをクリックするとユーザーが「localhost」に移動するため、役に立たなくなります。 （そのようなリンクで）クリックするたびに余分なリダイレクトが発生します。したがって、rfc 1738は、計画された「相対ドメイン」機能をまったく役に立たないものにします。一部の企業がその機能を使用し、ローカルサイトで相対ドメインを使用し、相対ドメインのURLがブラウザーによって絶対形式にリダイレクトされなかったため、サイトが正常に機能し、rfc 1736に従う場合、サーバーを構成しますfqdnのみを受け入れるには、そのようなURLをすべてfqdnで書き換えるか、そのようなURLをクリックするたびに余分なリダイレクトを処理する必要があります。その会社が「team101.Microsoft.com」ではなく「team101」のような短いドメインを持つことを好んだ場合。アドレスバーとHTMLソースでは、「team101」などのカスタム内部トップレベルドメインの使用を開始する必要があります。すなわち、「localhost」のような「team101.Microsoft.com」のようなサブドメインの代わりに（rfc 1738に従うことを決定する前に、単に「team101」として使用できます）。

-

そして、rfc 1738で非常に強力にサポートされていた末尾のドットが、末尾のドットのない標準の後にのみ実際に現れることがわかりました！ 1987年にrfc 1034で登場し、2番目のリンクで引用されています。

完全なドメイン名はルートラベルで終わるため、ドットで終わる
 printedフォームになります。このプロパティを使用して、以下を区別します。
-完全なドメイン名を表す文字列
（「絶対」と呼ばれることが多い）。たとえば、「poneria.ISI.EDU。」
-
ドメイン名の開始ラベルを表す文字列で、不完全であり、
ローカルソフトウェアで補完する必要がありますローカルドメインの知識を使用します（多くの場合、「相対」と呼ばれる
）。たとえば、
 ISI.EDUドメインで使用される「poneria」。

rfc 1034（1987年）は、使用されたすべてのドメインを宣言しましたが、末尾のドットがなく、すべて相対ドメインになると宣言しました！しかし、彼らはまだ以前と同じように働いていたので、おそらくそれを知っている人はほとんどおらず、末尾にドットを付けずに「example.com」を使用するときに、一意の本物の「example.com」サイトを明確に要求していると考え続けていたでしょう。有名な実際のexample.comは、「localhost。」などのローカルドメインを作成する権限が与えられていなくても、サブドメイン管理者になりすまされる可能性があります。そのため、rfc 1034もあまりうまく設計されていませんでした。作成者は、{広く知られていないため、セキュリティ侵害を引き起こす}ことを期待していないようです。

たぶんrfc 1738（1994）は最終的に、絶対ドメインと相対ドメインの区別のアイデアを幅広い聴衆にもたらし、6年後にそのセキュリティ侵害を修正しようとしましたが、{ 、{しかし、それらはおそらく広く使われていなかったと思います。おそらくいくつかの大企業でのみです}}。それで、もし従うなら、RFC 1737の結果の[左]は何でしょうか？ -1）1987年に宣言された相対ドメインは最終的に役に立たなくなるため、絶対ドメインを表示するように設計された末尾のドットも、最終的に役に立たなくなり、「法的に」冗長になります。 （しかし、多年後に一般の人々が相対ドメインの可能性について知り始めたときに、URLで相対ドメインを再び許可することを計画していたかもしれません）。 2）およびrfc 1737が遵守された場合、セキュリティ違反も修正されます。 -しかし、rfc 1034でさえ大衆に達した場合、セキュリティ違反は発生せず、相対ドメインの使用は安全でないことが広く理解されていました！ -それで、それを修正する主なレシピは幅広い聴衆に届きました、そしてもう一つのrfcを公開することはそれをする多くの方法の1つにすぎませんでした。

私は今、おそらく相対的なドメイン機能があまりにも限定的な使用のためだったので、RFC 1034（1987年）後に広く知られていなかったと思います：一部の大企業またはプロバイダーのローカルネットワークでのみ、それは実用的な価値のない機能でした、ローカルネットワークは既にローカルドメインを作成できたため、その機能はそれ自体のためのものでした。実際、それはrfcの役に立たないテキストであり、誰も追加の利益を得ることなく知って使用する必要があります。しかし、人々はrfcを広く無視することで小さなセキュリティ違反を引き起こしましたが、ブラウザはそれを聞き始めました。

昨日、相対ドメイン機能をチェックしましたが、機能します。 （それは大丈夫です、なぜならrfc 2396（1998年）はrfc 1034（1987年）が拒否された後に再び許可され、その後rfc 3986（2005年）はまだそれらを許可しているからです）。 Windows 10にDNSサフィックスを追加しました-コントロールパネル-...-ネットワークデバイスプロパティ-ipv4プロパティ-追加-DNSタブ。 「google.com」を追加し、Firefoxで「 http：// mail / 」を開くと、Googleのサーバーが開きましたが、「 http "Host"ヘッダーの "mail"なので、 "404"ページのようなものが表示されます。

-

2番目のリンクによるテキストへの返信（ http://www.dns-sd.org/trailingdotsindomainnames.html ）：

彼はまた、rfc 1738のルールを引用し、次のように述べています。

残念ながら、Webブラウザクライアントを実装している人々は、これが何を意味するのか理解していないようでした。 Webサイトにアクセスするとき、ほとんどのWebブラウザーが「ホスト：」フィールドに入力する値は、DNSユーザーの検索リストを適用してからの完全修飾名を構成した後、コンピューターが実際に使用したものではなく、ユーザーが入力したものです部分的な名前。たとえば、ユーザーがホスト「www.example.com」を参照できる3つの異なる方法を次に示します。 ... Webホストに「Host：」パラメーターを送信するとき、Webブラウザークライアントはユーザーが入力した内容（「www.example.com。」、「www.example.com」、または「www」）を代わりに入力しますクライアントが実際にDNSで検索した結果（3つすべてのケースで「www.example.com。」）。 ...

-これはあまり正確ではありません（正しい）。これは、rfc 1738がこの点で非常に厳格であり、ブラウザのアドレスバーにある場合でも、すべてのURLで相対ドメインを禁止し、URL自体が[推奨]サイトへの参照は、人々が紙に書いたとしても、ユーザーがURLを使用していると考えた場合、rfc 1738によって、その3つの方法でそのサイトを参照することは許可されませんでした！

このテキストの著者（Stuart Cheshire）はrfc 2396を知らなかったため、このテキストは古くなっています。

-

そして最近の状況はどうですか？ rfc 3986（ https://tools.ietf.org/html/rfc3986#page-21 ）末尾のドットなしで絶対ドメインを参照できます。 DNSの完全修飾ドメイン名のラベルの後には単一の「。」が続く場合があり、「完全なドメイン名とローカルドメインを区別する必要がある場合」に使用する必要があります。事実上の標準のため、それはほとんど必要ないので、wordpressは事実上の標準を受け入れて、末尾のドットのあるアドレスからアドレスのないアドレスにリダイレクトできます。

1
qdinar

私は、末尾のドットをインターネットの「本当の」ルートと考え、それがアメリカのバージニアに住んでいると考えています。ドットを省くと、何らかのルートが常に暗示されます。通常のユーザーにとっては、これは同じルートであり、それが今日説明する状況です。

私のひねくれたやり方で、私は実際に末尾のドットが非常に便利だと思います。他の人のウェブサイトをチェックアウトしているときに、キャッシュやCookieなどを使用せずにフレッシュに開始したい場合、それらをフラッシュするのが面倒な場合は、別のブラウザーを使用するか、ドットを追加します。サイトからリダイレクトされない場合は、サイトのすべてのページおよびその他のリソースのキャッシュされていないすべてのURLがあります。

ウェブマスターとして、ページを表示するすべての人とロボットが同じURLで、したがって同じホスト名でページを表示するようにします。ホスト名が使用したいものではない場合は、301リダイレクトをすぐに実行して、ブラウザで正しいURLが表示されるようにします。 PHPベースのサイトの場合、.htaccessまたはweb.configファイルではなく、PHPで問題を処理します。これは、移植性が高く、開発およびステージングサーバーでのテストが容易だからです。データベース接続も開発/ステージング/プロダクションサーバーによって異なるため、データベース接続を同時に処理します。

これが私の典型的なコードの簡略版です。最後の方への標準的なリダイレクトに注意してください。

    $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");
    }
1
Tom Robinson