AD ドメイン最適解～.local は使ってはいけない～

概要
ADドメイン名とDNS名
DNS を内外共に同じにすること
.local 問題
参考情報

概要

※少し長い記事になりますが、ご辛抱を…。
.local 問題だけ見たい人は、[.local 問題] セッションへ。

Active Directory (AD) を新規で構築する際、既存の AD 環境をアップグレードする際、あるいは複数の AD の統合 (会社統合など) 場合、DNS の設定には要注意です。
DNS は、我々が普段利用するドメイン名 (google.com 等) を、PC が利用する IP アドレスに変換するための非常に重要な役割です。

新期で AD ドメインと内部 DNS を構築する頻度は会社設立くらいしかないことから、人生でもあまりないと思います。そのため、ベストプラクティスに則って作業することは非常に重要です。
そこで、Microsoft 社が公式でベストプラクティスを公開しているため、こちらにまとめます。

さて、AD を新規で構築する際には、パブリックドメインを登録し、内部 DNS 用にサブドメインを作成することを Microsoft は強く推奨しています。メリットは以下の通り。

ドメインの所有権
パブリック DNS 名を登録することで、ドメインの法的な所有権を確保し、将来的に会社名の保護などの法的問題を事前に防ぐことが可能です。
構造
corp.contoso.com、dmz.cotoso.com、extranet.cotoso.com など、内部用にサブドメインを作成することで、組織的かつ階層的に構造化でき、子会社設立などの際、非常に有用です。
セキュリティ観点
内部 DNS 名と外部 DNS 名を明確に区別することで、内部ネットワーク構造の外部への露出を最小限に抑え、セキュリティを強化できます。仮にわかりやすいドメイン名になると、外部からの攻撃も増えるため。
使いやすさ
登録されたパブリックドメインの下でサブドメインを使用することで、ドメイン参加などや FQDN アクセスなどを行う社員にもわかりやすいです。

DNS を正しく設定するためには、Microsoft の公式ガイドラインに正しく準拠しましょう。

文書化
サブドメインと関連する IP アドレス、DNS 構造のをドキュメント化すること。トラブルシューティングや将来の増築計画に役立つ。
アクセス制御
ダウンタイムやセキュリティ侵害につながる DNS レコードの不正な変更を防ぐため、アクセス制御を実施。
監視
定期的に DNS サーバーを監視し、セキュリティ上の脅威などの異常なふるまいを常に監視すること。
テスト
DNS 設定の変更を実施する前に、QA 環境などでテストをし、本番環境での設定変更した際の混乱を防ぐ。 (ぶっつけ本番禁止)

ADドメイン名とDNS名

AD のドメイン名と DNS 名は構築者にとっては簡単かもしれませんが、お互いが関連するものですので、よく分からなくなります。
そこで、AD ドメイン名と DNS 名の違いやそれらの関係性について記載します。

ADドメイン名とDNS名の違い

項目	AD ドメイン名	DNS 名
概要	Active Directory の中で、LDAP クエリなどの AD 機能として利用	ドメイン名を IP アドレスに変換するために使用される
識別子	組織の内部ネットワーク内の識別子	ネットワークレベルの識別子
管理できるもの	ユーザーアカウント、コンピュータ、ポリシーなどの管理	ドメイン名と IP アドレスの管理

ドメイン名と DNS の関係性

上記通り、ドメイン名と DNS は役割は異なりますが、AD ドメイン名と DNS 名はリンクしています。
AD ドメイン名は構築する際、DNS サーバーを共に作成し、ディレクトリサービスと DNS の間を統合します。
たとえば、”corp” という名前の AD ドメインは、”corp.contoso.com” のような DNS 名に対応したりと、組織内外の名前解決に対し、重要な役割を果たしています。

NetBIOS名

NetBIOS 名は、DNS が主流となる前の過去の産物です。
NetBIOS 名は基本的に AD ドメイン名の大文字バージョンで、DNS より前に使用されていた命名規則です。ログオン目的でユーザー名とともに使用されます。
例：CONTOSO\asitblog

DNS を内外共に同じにすること

DNS のゾーン内部と外部、同じにすることは、Microsoft は非推奨 (というか絶対やるな) としています。
まずデメリットですが、4つ。

ドメイン統合の際に外部共に再設計が必要
運用時、設定変更などが非常に困難
内外 DNS の権限がプロバイダーサービス社と競合し、設定変更などができなくなる
DNS の名前付けが困難

また、実際に以下の事例が起きたこともあります。

DNS の監視が自動化できず、手動工数が増え、非常に非効率的な運用体制となった
ネットワークエラーにより、お客様からのクレーム
DNS の競合が起き、設定不能 or ネットワークエラー
外部からのセキュリティ脆弱性攻撃により、会社自体が不機能

.local 問題

さて、かなり長々と書きましたが、DNS とドメイン名との関係性はご理解いただけたかと思います。
問題の .local をドメイン名として、利用する件です。

Bonjour の Multicast Domain Name Service (mDNS) は、”.local” サフィックスを使用して、ネットワーク上のデバイスを識別します。 (IETF によって RFC 6762 文書で定義)
IANA によって特殊用途ドメイン名として “.local” はリスト化されています。
その “.local” サフィックスを使用することで、Apple 製品などの一部デバイスで問題が発生する可能性があります。

組織で “.local” サフィックスを使っている場合は、Apple 製のデバイスでユニキャストの DNS 名が解決されなかったり、Active Directory ドメインにバインドされなかったりすることがあります。
Apple 製のデバイスで社内ネットワークの ‘.local’ ドメインを開けない場合 – Apple サポート (日本)

未登録のドメイン名を使用する際には、IANAによって予約されている特殊用途ドメイン名を避けることが重要です。
詳細は Special-Use Domain Names (iana.org) へ。

ちなみに .local を利用することは、Microsoft も非推奨です。

In the past, lots of people chose to use a dummy, unofficial TLD (top-level-domain) for their internal network, like domain.lan, domain**.local** of domain**.internal** (and also domain.internalhost)

But this can get you in serious trouble. Because these names are not supported by internet standards, the most important RFC on this is: RFC 2606 (http://tools.ietf.org/html/rfc2606) This RFC standard is very explicit on choosing domain names for private testing and documentation

過去には、多くの人が、domain.lan、domain.local、domain.internal（およびdomain.internalhost）のように、ダミーの非公式な TLD（トップレベル・ドメイン）を内部ネットワークに使用することを選択しました。

しかし、これは深刻なトラブルに巻き込まれる可能性があります。これらの名前はインターネット標準ではサポートされていないため、これに関する最も重要な RFC があります：RFC2606 (http://tools.ietf.org/html/rfc2606)
このRFC標準は、プライベートテスト用のドメイン名の選択について非常に明確に述べています。
Active Directory: Best Practices for Internal Domain and Network Names | Microsoft Learn