Active Directory (AD) ドメイン設計のベストプラクティスは、AD ドメイン名として登録されたドメイン名を使用することを推奨します。可能な代替手段としては、AD ドメイン名に非パブリック DNS サフィックス (ローカルまたはlanなど) を使用することや、ad ドメインを登録済みドメイン (corp.domain.comなど) のサブドメインにする方法があります。
ただし、常に選択することはありません。会社の登録されたドメインと同じ名前を持つ AD ドメインをサポートしている場合は、管理者が名前の変更を望んでいない場合があります。これは、2つの異なる DNS 名前空間が存在します。このシナリオでは、AD によって使用される内部ネームスペースと、同じ名前のパブリックドメインレジストラーによって使用される外部ネームスペースの2つのDNSDNSがあります。このシナリオでは、いくつかの固有の課題を提示することができます。この記事では、スプリット DNS 環境で発生するいくつかの一般的な問題と、それらを軽減するために実行できる操作について説明します。
以下のすべての例では、AD ドメインと登録されたドメインの両方にdomain.comという名前が付けられており、 www.domain.comという名前の会社の web サイトがあります。
問題 1: 外部ホスト型会社のウェブサイトが office
内部からアクセスできないこれは、スプリット DNS 環境で最も一般的な問題であり、会社のウェブサイト、またはその他の会社所有のインターネット接続リソースは、AD ドメインに参加しているマシンによって office 内部からは到達できません。ただし、オフィス外のマシンは web サイトには問題がありません。これが発生する理由は、内部ユーザーが会社のウェブサイトを参照しようとしたときの動作を調査することで表示できます。
この問題は、データベース内に特定のルックアップゾーンを持つ DNS サーバー (この例ではdomain.comゾーン) は、そのゾーン内のレコードのクエリをその他の場所に送信しないために発生します。特定のクエリーに一致するレコードがない場合、単に「not found」というレスポンスを返します。この例では、正しいレコードを持つ別の DNS サーバがあります。これは、ドメインレジストラーに属するパブリックdomain.comゾーンをホストしている DNS サーバであり、オフィス外のマシンがウェブサイトにアクセスできるという事実によって明らかになります。ただし、内部マシンからのクエリーはそのサーバーに到達しません。
この問題を解決するには、次のようにします。 DC 上のdomain.comゾーンにwwwという名前のホストレコードを作成し、その web サイトの IP アドレスを記録します。DNS サーバにクエリーを実行するマシンは、正しいレスポンスを受け取り、ウェブサイトを参照できるようになります。
問題 2: 内部でホストされるパブリック web サイト (office
内部からアクセスできない)これは、前述の問題1のバリエーションであると考えられます。この場合の違いは、web サイトが内部でホストされているということです。これは、社内ネットワーク上のファイアウォールの背後にあるか、DMZ 内にあります。内部および外部の両方のユーザーがアクセスできると想定されていますが、外部ユーザーは問題を報告しません。
問題の原因は問題1と似ていますが、この場合、内部ユーザーが web サイトの名前をパブリック IP アドレスに正しく解決できます。ただし、ファイアウォールの構成方法により、web サイトにアクセスできません。内部ネットワークのユーザーは、パブリックアドレスではなく、プライベートアドレスを使用してウェブサイトにアクセスする必要があります。
さらに、簡単な修正があります。この場合、DC 上のdomain.comゾーンにwwwという名前のホストレコードを作成します。このとき、WEB サイトのプライベート IP アドレスを記録します。内部マシンは、web サイトの名前をそのプライベートアドレスに解決しますが、外部マシンは web サイトのパブリックアドレスに対して名前の解決を続けます。
問題 3: 上記の変更が行われた後で、ウェブサイトのロードが不完全であるか、まだロードされない
これは、web サイトコードによってブラウザがwww.domain.comからdomain.comにリダイレクトされる場合、または内部リンクがサイトをwww.domain.comではなくdomain.comとして参照している場合に発生する可能性があります。サイトが内部または外部のどちらでホストされているかにかかわらず、内部マシンで同じ症状が見られます。
この場合の問題は、少し複雑です。マシンがdomain.comを IP アドレスに解決するためには、 domain.comゾーンに空のホストレコードが存在する必要があり DNS。このレコードの名前は、Windows DNS コンソールに、 (親フォルダと同じ)として表示されます。ただし、この場合、次のような問題があります。AD は、 domain.comゾーンの空白のホストレコードを使用して、 Domain.comドメインの DCs を表します。ドメインメンバーは、認証のために DC を検索するときにこれらのレコードを使用します。 domain.comゾーンに余分な空白のホストレコードがある場合は、遅延または認証の問題が発生する可能性があります。
この問題を解決するには、この問題を DNS だけで解決することはできません。Web サイトの IP アドレスを使用して空白のホストレコードを作成すると、内部ユーザーのウェブサイトアクセスの問題が間欠的に解決されます。これは、ドメイン内の DCs の IP アドレスを持つ他の空のホストレコードがすでに存在しているためです。これによりドメイン認証の問題が発生します。
この問題を解決する最も簡単な方法は、web サイトのコードを変更して、リダイレクトを削除するか、または内部リンクを修正して、すべてがdomain.comではなくwww.domain.comとしてサイトを参照できるようにすることです。コードの変更を行うことができない場合、この問題を解決する唯一の方法は、AD ドメインの名前を変更することです。これは、環境の規模や複雑さに応じて複雑なタスクになる可能性があります。