Active Directoryのドメイン名（FQDNのほう）に末尾.localはもうやめましょう、と言う話のご報告。
主にActive Directoryを利用する企業向けの話題ですね。
まだ、あんまり調べてないので、ぼんやりした話ですが。
秘密は、
mDNS(マルチキャストドメインネームサービス【multicast domain name service】）
にあり。
Windows 10 April 2018 Updateでの不具合に
■Windows 10 April 2018 Update である1803にアップグレードするとmDNSからみで問題が発生する
https://answers.microsoft.com/ja-jp/windows/forum/windows_10-networking/windows-10/98d1d75f-1810-4c0c-be51-dd7b7e288c43
投稿内の返信に気になる記述があって、簡単に端折ると、
末尾.localのドメインを使用していると、問題が発生するらしい。
Windows10の1803から使用されるmDNS（のシステム内で使用されている）.localとActive Directoryのドメイン名の.localで名前が衝突してしまうことが要因（じゃないか？）と記述されています。
コンフリクトですか。
※ちなみに、Apple製品のmDNSとはBonjourのことらしい、久々にこのBonjourの文字を見ました、FileMaker Serverを構築していた時に必死で勉強した板とき以来、久々に見かけましたよ。
ダメ押しとしてTechNetのドキュメントにそれらしき記述を発見しました。
TechNetのドキュメント記述
そのドキュメントとは、これです。
■Active Directory: Best Practices for Internal Domain and Network Names
ココから一部引用し、日本語にしてみます。
このページ内に
「Dummy DNS name vs official DNS name」という記述があります。
-------------------------------------------------------
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)
-------------------------------------------------------
過去に、たくさんの人々は、domain.local、domain.internalのdomain.local（およびdomain.internalhost）などのような内部ネットワークのためのダミーの、非公式なTLD(トップレベルのドメイン)を使うことに決めました。
-------------------------------------------------------
これに続いて、
-------------------------------------------------------
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 Jump (http://tools.ietf.org/html/rfc2606 Jump ) This RFC standard is very explicit on choosing domain names for private testing and documentation
-------------------------------------------------------
しかし、これは重大なトラブルにおいてあなたをつかまえることができます。
これらの名前がインターネットスタンダードによってサポートされていないので、これの上の最も重要なRFCは以下の通りです：
RFC2606ジャンプ(http://tools.ietf.org/html/rfc2606 ジャンプ)This RFCの標準は、私的なテストとドキュメンテーションにドメイン名を選ぶことに関して非常に明示的です。
-------------------------------------------------------
この二つの文を繋げると、
domain.local、domain.internalのdomain.local（およびdomain.internalhost）などの内部ネットワーク専用で使う（使っていた）非公式の非正規TLD（トップレベルドメイン）の利用は、「serious trouble.（深刻な問題）」だ
と読み取ることができます。
うーん、なんといまさらな。Windows NTドメイン（4.0時代）からActive Directory移行の際にセミナーで.localで構成するような話はMSのセミナーを含めてたくさんありました。
時は流れ、Active Directoryもデビューから20年近くとなりました。時代は変わったと申しますか、もう「.localでActive Directoryドメインを構築しちゃダメなんですよ」ってことです。既存の.localで構築されたActive Directoryドメインがあれば早めに自社公式のFQDN（例えば～.co.jpのような）と同じかそのサブドメインをActive Directoryに割り当てるって必要があるようです。
う、どうしよう…、.localのActive Directoryドメインあるよ…。
いわゆるベストプラクティスは…？
簡単に言えば、インターネット上で利用している（公式に取得した）組織のFQDN（ドメイン名）と同一のドメイン名をActive Directoryドメイン名のFQDNとする、もしくはそのドメイン名のサブドメインとして内部Active Directoryドメイン用のドメイン名とする、と言ったところです。
当方で言えば、このブログ<https://blog.treedown.net>にある「treedown.net」の部分ってことですね。
名付けるとしたら、さしずめ内部を表すInternalやらActive Directoryないしディレクトリサービスを表すdirectoryあたりを組み合わせて「intdir.treedown.net」てとこでしょうか。「intad.treedown.net」も候補かもです。Azure ADだとexternalあたりをうまく名付けに利用するってのがとりあえずの候補ですね。
そして、社内から.localで終わるドメイン環境を駆逐する、
.localで終わるADドメインのリソースはすべて新ドメインに移行する、
という対処が必要になるようです。
Office365のSSO（シングルサインオン）を利用しようと思ったら、.localドメインのActive DirectoryのユーザやコンピュータはSSOできない、きちんと公的に使えるドメイン名をActive Directoryでも利用するってことね、と見て取れます。※Office365の認証はバックでAzure ADで認証をしている（だったはず）
もうちょい、勉強しておこうと思いました。
