私たちのオフィスには、純粋に内部DNSが設定されたローカルエリアネットワークがあり、すべてのクライアントでwhatever.lan
。 VMware環境もあり、仮想マシンのみのネットワークでは、仮想マシンにwhatever.vm
。
現在、仮想マシンのこのネットワークにはローカルエリアネットワークから到達できませんが、これらの仮想マシンを移行するための本番ネットワークをセットアップしています。willは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を推奨します。
IANAは 両方のRFCを認識 のように見えますが、(現在)付録Gにリストされている名前を組み込んでいません。
言い換えれば、それを行うべきではありません。ただし、とにかくそれを行う場合は、上記の名前のいずれかを使用してください。
すでに述べたように、プライベートネットワークには未登録のTLDを使用しないでください。特にICANNでは、ほとんどすべての人が新しいTLDを登録できるようになりました。次に、実際のドメイン名を使用する必要があります。
反対に、 RFC 1918 は明確です。
そのようなアドレスへの間接参照は企業内に含まれるべきです。このような参照の顕著な例は、DNSリソースレコードおよび内部プライベートアドレスを参照するその他の情報です。
したがって、ネームサーバーでもビューを使用して、プライベートレコードがインターネット上で送信されないようにする必要があります。
ホストの物理的な名前と仮想的な名前の違いは考慮しない傾向があります。実際、ホスト構成(ソフトウェア)を物理層から抽象化することにしました。
そこで、ハードウェアアイテムを購入し、その上にホストアイテムを作成します(ドキュメントにそれを示すために単純な関係を使用します)。
目的は、ホストが存在する場合、DNSが決定要因にならないようにすることです。たとえば、マシンをあるスペースから次のスペースに移動させるためです。たとえば、低パフォーマンスのWebアプリケーションは、高価なCPUサイクルを消費する必要がなく、仮想化します。 、そしてそれはその命名スキームを保持し、すべてが機能し続けます。