プライベートネットワークのトップレベルドメイン/ドメインサフィックス？

私たちのオフィスには、純粋に内部DNSがセットアップされたローカルエリアネットワークがあり、その上にすべてのクライアントがという名前が付けられていwhatever.lanます。VMware環境もあり、仮想マシンのみのネットワークでは、仮想マシンに名前を付けますwhatever.vm。

現在、仮想マシンのこのネットワークは、私たちのローカルエリアネットワークから到達可能ではないですが、私たちは、これらの仮想マシンに、移行する生産ネットワークを設定しているだろう LANから到達可能であるが。その結果、我々は、我々が設定しているこの新しいネットワーク上のゲストに適用ドメインサフィックス/ TLDのための規則に落ち着くしようとしているが、我々は良いものを考え出すことができない、という与えられた.vm、.localと.lan私たちの環境にはすべて既存の意味合いがあります。

それでは、この状況でのベストプラクティスは何ですか？純粋に内部ネットワークに安全に使用できるTLDまたはドメイン名のリストはありますか？

発明されたTLDを使用しないでください。ICANNがそれを委任した場合、あなたは大きな問題に直面するでしょう。同じダミーTLDを使用する別の組織とマージする場合も同じです。そのため、グローバルに一意のドメイン名が優先されます。

標準であるRFC 2606では、例、ドキュメント、テスト用に名前を予約していますが、一般的な使用には適していません。また、正当な理由のために、ダミーのもの。

それを購入iamthebest.orgして、デバイスに名前を付けます。

インターネットで名前を使用したくない内部マシンには、会社の登録済みドメインのサブドメインを使用します。（もちろん、内部DNSサーバーでそれらの名前のみをホストします。）以下に、架空のExample Corporationの例をいくつか示します。

インターネットに 直接接続するサーバー：
www.example.com
mail.example.com
dns1.example.com

内部マシン：
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

私は「corp」を使用して、このサブドメインが内部企業ネットワーク上のマシンを記述したことを示しましたが、「internal」：client1.internal.example.comなど、ここで必要なものを使用できます。

DNSゾーンとサブドメインは、ネットワークの番号付けスキームに合わせる必要がないことも忘れないでください。たとえば、私の会社には37の場所があり、それぞれに独自のサブネットがありますが、すべての場所は同じ（内部）ドメイン名を使用します。逆に、1つまたは少数のサブネットのみを使用できますが、多くのピア内部ドメインまたはサブドメインのレベルは、マシンの整理に役立ちます。

内部サブドメインを使用するもう1つの利点があります。検索サフィックスとFQDNではなくホスト名のみを巧みに使用すると、開発、QA、および本番の両方で機能する構成ファイルを構築できます。

たとえば、構成ファイルでは常に「database = dbserv1」を使用します。

開発サーバーで、検索サフィックスを「dev.example.com」に設定します=>使用するデータベースサーバー：dbserv1.dev.example.com

QAサーバーで、検索サフィックスを「qa.example.com」に設定します=>使用するデータベースサーバー：dbserv1.qa.example.com

実稼働サーバーで、検索サフィックスを「example.com」に設定します=>使用するデータベースサーバー：dbserv1.example.com

そうすれば、すべての環境で同じ設定を使用できます。

この質問に対する以前の回答が書かれてから、ガイダンスを多少変更するRFCがいくつかありました。 RFC 6761は、プライベートネットワークに特定のガイダンスを提供することなく、特別な用途のドメイン名について説明しています。 RFC 6762は、未登録のTLDを使用しないことを引き続き推奨していますが、いずれにしても実行される場合があることも認めています。一般的に使用される.localはマルチキャストDNS（RFCのメイントピック）と競合するため、付録G.プライベートDNS名前空間は次のTLDを推奨しています。

• イントラネット
• 内部
• 民間
• corp
• ホーム
• lan

IANAは両方のRFCを認識しているように見えますが、（現在）付録Gにリストされている名前は組み込まれていません。

言い換えれば、あなたはそれをすべきではありません。しかし、とにかくそれを行うことにした場合は、上記の名前のいずれかを使用してください。

既に述べたように、プライベートネットワークには未登録のTLDを使用しないでください。特に今では、ICANNはほとんどすべての人が新しいTLDを登録できるようになっています。次に、実際のドメイン名を使用する必要があります

一方、RFC 1918は明確です。

このようなアドレスへの間接的な参照は、企業内に含める必要があります。このような参照の顕著な例は、DNSリソースレコードおよび内部プライベートアドレスを参照するその他の情報です。したがって、ネームサーバーはビューを使用して、プライベートレコードがインターネット上で送信されないようにする必要があります。

私たちは、物理的なものとホストの仮想的な名前の違いを考慮しない傾向があります-実際、物理層からホスト構成（ソフトウェア）を抽象化することにしました。

そのため、ハードウェアアイテムを購入し、その上にホストアイテムを作成します（そして、単純な関係を使用してドキュメントに示します）。

目的は、ホストが存在する場合、DNSが決定要因にならないことです-マシンをあるスペースから次のスペースに移動するため-たとえば、低パフォーマンスのwebappは高価なCPUサイクルを消費する必要がありません-仮想化する、およびその命名スキームを保持し、すべてが引き続き機能します。

これがあなたに役立つかどうかはわかりませんが、AWSアカウント内の内部DNSについて.awsは、TLDとして使用します。

使用しないでフラットにする必要があるTLDがいくつかあることは知っていますが、それ以外は厳密すぎるとは思いません。

私はそれが認証ソースとしてActive Directoryを使用して、MS / Windowsサーバであれば、それは次のようになりつまり、彼らはTLDとして認証ソースを使用することになり、いくつかの大企業、で働いていた.ad、といくつかの他は次のようになり.ldap、彼らがwerenなぜ（ 「同じソースを使用しているだけですか？または同じディレクトリサービスから複製しているサーバーですか？わかりません、そこに着いたときはそうでした）

幸運を