Active Directoryの名前付けに関するよくある質問 - 版の履歴

Meisina04: /* DNSのしくみ */

2019-02-26T03:56:50Z

DNSのしくみ

← 古い版		2019年2月26日 (火) 12:56時点における版
11行目:		11行目:
	== DNSのしくみ ==		== DNSのしくみ ==

	DNSは、IPアドレス（Aレコード）や他の多くのレコードタイプのような名前をコンピュータ消費のための他のタイプのデータに変換するために使用されるシステムです。よく使われるアナロジーは、電話帳のアナロジーです。 DNSサーバーは、コンピュータ名をIP（または他の種類のデータ）にすばやく変換するために使用できる種類のコンピュータ電話帳として機能します。しかし、この電話帳は巨大なサイズ（約40億のIPv4アドレスしかありません）であり、絶えず変化しているため、DNSはどの電話帳またはネームサーバーがど		DNSは、IPアドレス（Aレコード）やその他のさまざまなレコードタイプなど、コンピュータで使用するために名前を他のタイプのデータに変換するために使用されるシステムです。よく使われる例えは電話帳のそれです。 DNSサーバーは、コンピューター名をIP（またはその他の種類のデータ）に素早く変換するために使用できる一種のコンピューター電話帳として機能します。しかし、この電話帳は巨大なサイズで（〜40億のIPv4アドレスだけで）、DNSは階層システムを使用してどの電話帳（ネームサーバー）がどのアドレスセットを担当するかを決定します。
	~~のアドレスセットを担当するかを決定するために階層システムを使用します。~~

	ドメイン名が解決されるたびに、Webブラウザや他のソースからDNS問い合わせが行われます。 Windowsの実際の名前解決はやや複雑な話題ですが、一般的にはWindows PCがそのローカル名を確認した後、そのホストファイルを確認してからDNS要求を出します（名前がキャッシュにない限り）。 DNSネームサーバーは、再		ドメイン名が解決されるたびに、Webブラウザや他のソースからDNS問い合わせが行われます。 Windowsの実際の名前解決はやや複雑な話題ですが、一般的にはWindows PCがそのローカル名を確認した後、そのホストファイルを確認してからDNS要求を出します（名前がキャッシュにない限り）。 DNSネームサーバーは、再

Meisina04: /* 無効なTLDの使用 */

2018-03-23T03:08:11Z

無効なTLDの使用

← 古い版		2018年3月23日 (金) 12:08時点における版
160行目:		160行目:

	* .local TLDはいくつかのzeroconfシステム、特にAppleのBonjourサービスで使用されています。一緒に使用すると正しく動作しません。		* .local TLDはいくつかのzeroconfシステム、特にAppleのBonjourサービスで使用されています。一緒に使用すると正しく動作しません。
	* .localや.~~internalなどの無効なTLDは、まもなく主要な証明書プロバイダのいずれかからSSL証明書を取~~		* .localや.internalなどの無効なTLDは、まもなく主要な証明書プロバイダのいずれかからSSL証明書を取得できなくなります。 CA/Browser Forumは、2015年11月1日以降、これらの無効なドメインに対して証明書を発行しないことを決定しました。実際、この日付以降に有効期限が切れた証明書は購入できません。これには、その他の有効な証明書内で使用される主体別名（SAN）が含まれます（これはMicrosoft Exchangeの非常に一般的な構成です）。内部の証明機関にはこのような制限はありませんが、このオプションを使用することは常に有効です。
	~~得できなくなります。~~ CA/Browser Forumは、2015年11月1日以降、これらの無効なドメインに対して証明書を発行しないことを決定しました。実際、この日付以降に有効期限が切れた証明書は購入できません。これには、その他の有効な証明書内で使用される主体別名（SAN）が含まれます（これはMicrosoft ~~Exchangeの~~
	~~非常に一般的な構成です）。内部の証明機関にはこのような制限はありませんが、このオプションを使用することは常に有効です。~~
	* 現在使用している無効なTLDが将来有効なTLDになる可能性があります。 .localはICANNによって予約されていますが、TLDシステムは現在、サポートする汎用TLD（gTLD）を22から数千の新しい名前に拡張する予定です。この傾向は引き続き続く可能性が高い。		* 現在使用している無効なTLDが将来有効なTLDになる可能性があります。 .localはICANNによって予約されていますが、TLDシステムは現在、サポートする汎用TLD（gTLD）を22から数千の新しい名前に拡張する予定です。この傾向は引き続き続く可能性が高い。

	同じ理由で、.internalと.lanを含む他の無効なTLDを持つ名前は避けるべきです。		同じ理由で、.internalと.lanを含む他の無効なTLDを持つ名前は避けるべきです。


	== 外部ドメイン名の使用 ==		== 外部ドメイン名の使用 ==

Meisina04: /* 私は内部的および外部的にホスト名を解決するために異なる名前を使用する必要があります */

2018-03-23T03:06:57Z

私は内部的および外部的にホスト名を解決するために異なる名前を使用する必要があります

← 古い版		2018年3月23日 (金) 12:06時点における版
145行目:		145行目:
	しかし、状況によっては、この複雑な問題を構成に追加することはお勧めできません。たとえば、ユーザーが設定するメール設定を配布する場合、外部的および内部的に別のメールスキームを使用しなければならないという複雑さが増しすぎる可能性があります。モバイルデバイスでは、このスキームは実行可能ではないかもしれません。ありがたいことに、この問題の解決策がいくつかあります：		しかし、状況によっては、この複雑な問題を構成に追加することはお勧めできません。たとえば、ユーザーが設定するメール設定を配布する場合、外部的および内部的に別のメールスキームを使用しなければならないという複雑さが増しすぎる可能性があります。モバイルデバイスでは、このスキームは実行可能ではないかもしれません。ありがたいことに、この問題の解決策がいくつかあります：

	* 外部名のトラフィックをネットワークにルーティングして戻すことを許可します。		* '''外部名のトラフィックをネットワークにルーティングして戻すことを許可します。'''
			: 通常、この設定には余分な設定は必要ありません。外部IPアドレスのトラフィックバウンドは、最終的な宛先がネットワーク内に戻っても、他のインターネットバウンドトラフィックと同じように扱うことができます。

	通常、この設定には余分な設定は必要ありません。外部IPアドレスのトラフィックバウンドは、最終的な宛先がネットワーク内に戻っても、他のインターネットバウンドトラフィックと同じように扱うことができます。		* '''名前を解決するだけのDNSゾーンを作成します。'''
			: ゾーン内の単一のホストだけを解決し、残りのホストは外部サーバーによって正常に解決されるようにAD DNSで行うことができます。 "host.domain.tld"という名前のDNSゾーンを作成します（例： "mail.example.com"）。ゾーン内では、レコードの名前を空白のままにして、単一のAレコードまたはCNAMEレコードを作成します（おそらくCNAMEが優先されます）。ダイアログが示すように、この名前は親ドメイン（この場合は "host.domain.tld"）を解決するために使用されます。

	* 名前を解決するだけのDNSゾーンを作成します。		: これは、あなたが望むものとまったく同じです。 "host.domain.tld"はDNSサーバーによって指定されると解決され、 "domain.tld"下の他のホストへの要求は外部的に解決されます。 "host.domain.tld"と "domain.tld"は異なるゾーン。親レコードとしてCNAMEを使用する場合は、これを内部ドメイン名のレコードに戻すことができます。

	ゾーン内の単一のホストだけを解決し、残りのホストは外部サーバーによって正常に解決されるようにAD DNSで行うことができます。 "host.domain.tld"という名前のDNSゾーンを作成します（例： "mail.example.com"）。ゾーン内では、レコードの名前を空白のままにして、単一のAレコードまた
	はCNAMEレコードを作成します（おそらくCNAMEが優先されます）。ダイアログが示すように、この名前は親ドメイン（この場合は "host.domain.tld"）を解決するために使用されます。

	これは、あなたが望むものとまったく同じです。 "host.domain.tld"~~はDNSサーバーによって指~~
	~~定されると解決され、~~ "domain.tld"下の他のホストへの要求は外部的に解決されます。 "host.domain.tld"と "domain.tld"~~は異なるゾーン。親レコードとしてCNAMEを使用する場~~
	~~合は、これを内部ドメイン名のレコードに戻すことができます。~~

	== 無効なTLDの使用 ==		== 無効なTLDの使用 ==

Meisina04: /* ドメイン名のスタイルは長いです */

2018-03-23T03:02:56Z

ドメイン名のスタイルは長いです

← 古い版		2018年3月23日 (金) 12:02時点における版
118行目:		118行目:
	==== ドメイン名のスタイルは長いです ====		==== ドメイン名のスタイルは長いです ====

	接尾辞の追加は、好きなだけ短くすることができます（「広告」または「ds」を使用することは非常に一般的です）。ただし、DNSサフィックスとDNSサフィックスの検索リストを設定することで、ドメイン名の入力を完全に避けることができます。これらの変数が設定されると、クライアントは "server"のよ		接尾辞の追加は、好きなだけ短くすることができます（「ad」または「ds」を使用することは非常に一般的です）。ただし、DNSサフィックスとDNSサフィックスの検索リストを設定することで、ドメイン名の入力を完全に避けることができます。これらの変数が設定されると、クライアントは "server"のよ
	うな単一ラベルのドメイン名を "server.dnssuffix.tld"として解決しようとします。これは証		うな単一ラベルのドメイン名を "server.dnssuffix.tld"として解決しようとします。これは証
	明書でも有効です。必要に応じて、 <nowiki>"https://server.samdom.example.com/"</nowiki>の代わりに <nowiki>"https：//server/"</nowiki>に適した証明書を内部サーバーに発行できます。また、ある時点でDNS検索サフィックスのDNS検索サフィックスの使用を避ける必要がある場合は、最終的な '.'を含めることを覚えているFQDNを指定することでそれを行うことができます。ルートゾーンの場合		明書でも有効です。必要に応じて、 <nowiki>"https://server.samdom.example.com/"</nowiki>の代わりに <nowiki>"https：//server/"</nowiki>に適した証明書を内部サーバーに発行できます。また、ある時点でDNS検索サフィックスのDNS検索サフィックスの使用を避ける必要がある場合は、最終的な '.'を含めることを覚えているFQDNを指定することでそれを行うことができます。ルートゾーンの場合


	==== これは私の外部ドメインで正しく機能しません ====		==== これは私の外部ドメインで正しく機能しません ====

Meisina04: /* 自分が所有するドメインのサブドメイン */

2018-03-23T03:02:26Z

自分が所有するドメインのサブドメイン

← 古い版		2018年3月23日 (金) 12:02時点における版
98行目:		98行目:
	の名前のスタイルは、私たちが望ましいドメイン名で示した上記のすべての基準を満たしています。最も重要なのは、		の名前のスタイルは、私たちが望ましいドメイン名で示した上記のすべての基準を満たしています。最も重要なのは、

	* ~~それは世界的にユニークです。ネット上のドメイン登録（およびおそらくそのDNSエントリ）を制御する~~		* それは世界的にユニークです。ネット上のドメイン登録（およびおそらくそのDNSエントリ）を制御するので、内部的に使用するドメインが外部的に何かに解決されないようにすることができます。
	~~ので、内部的に使用するドメインが外部的に何かに解決されないようにすることができます。~~
	* サードパーティSSL証明書を取得するための有効なドメイン名になります。		* サードパーティSSL証明書を取得するための有効なドメイン名になります。

Meisina04: /* 私のドメイン名はどうすればいいですか？ */

2018-03-23T03:01:53Z

私のドメイン名はどうすればいいですか？

← 古い版		2018年3月23日 (金) 12:01時点における版
87行目:		87行目:

	* ドメイン名は、グローバルに一意である必要があります。これにより、コンピュータがDNS解決に使用するように構成されている場合でも、名前が正しく解決されるか、ドメイン（NXDOMAIN）が返されなくなります。ドメイン名の競合は決してあってはなりません！		* ドメイン名は、グローバルに一意である必要があります。これにより、コンピュータがDNS解決に使用するように構成されている場合でも、名前が正しく解決されるか、ドメイン（NXDOMAIN）が返されなくなります。ドメイン名の競合は決してあってはなりません！
	* ドメインは組織に関連している必要があります。 ~~ドメイン名は理想的にはあなたの組織に関連している~~		* ドメインは組織に関連している必要があります。ドメイン名は理想的にはあなたの組織に関連している必要があります。覚えるのも簡単です。
	~~必要があります。覚えるのも簡単です。~~		* ドメインはあなたのコントロール下にあるべきです。管理しているドメイン名（登録されている所有者）は、悪意のある使用を防ぐのに役立ちます。ドメイン名の登録は、いずれの企業にとっても安価で望ましいものです。
	* ドメインはあなたのコントロール下にあるべきです。 ~~管理しているドメイン名（登録されている所有者~~		* あなたが望むならば、あなたはそれのためにサードパーティのSSL証明書を得ることができるように、ドメイン名はまだ有効なドメイン名であるべきです。
	~~）は、悪意のある使用を防ぐのに役立ちます。ドメイン名の登録は、いずれの企業にとっても安価で望ま~~
	~~しいものです。~~
	* ~~あなたが望むならば、あなたはそれのためにサードパーティのSSL証明書を得ることができるように、ド~~
	~~メイン名はまだ有効なドメイン名であるべきです。~~

	これらの基準を念頭に置いて、いくつかのオプションを見てみましょう。		これらの基準を念頭に置いて、いくつかのオプションを見てみましょう。

Meisina04: /* 無効なTLDの使用 */

2018-03-23T02:56:07Z

無効なTLDの使用

← 古い版		2018年3月23日 (金) 11:56時点における版
177行目:		177行目:

	同じ理由で、.internalと.lanを含む他の無効なTLDを持つ名前は避けるべきです。		同じ理由で、.internalと.lanを含む他の無効なTLDを持つ名前は避けるべきです。


			== 外部ドメイン名の使用 ==

			このシナリオでは、単に "example.com"のように、 "domain.tld"の形式で外部ドメ
			イン名を内部的に再利用するだけです。これは有効なオプションですが、DNSシステムに不要な複雑さを加
			える可能性もあります。前述のように、このようなシステムでは、ドメイン名の競合の可能性があります。通常、内部的に存在しない名前か、内部的に異なる外部で解決される名前の間にあります。これは、内部サーバーの外部サーバーにあるエントリを複製することで解決できますが、外部DNSエントリが多い場合や頻
			繁に変更する場合は実行できない場合があります。外部命名方式と競合しない内部命名方式を選択することができます。

			== 汎用ドメイン名の使用 ==

			合併や買収の対象となる組織では、「corp.local」などの汎用ドメイン名を使用することが有効な選択肢となる可能性があることが示唆されています。ドメイン名の変更と移行はしばしば困難でコストのかかる操作であるため、これには妥当性があるかもしれませんが、選択したドメイン名が他の管理者によって選択されないという保証はありません。これは、ドメイン合併をはるかに困難にするでしょう。さらに、カスタムUPNサフィックスとDNS検索サフィックスを使用して一般名をユーザーから隠すことができますが、一意性が保証された古いドメイン名も同じ方法で隠すことができます。

			== 別のドメイン名を使用する ==

			このシナリオでは、プライマリインターネットドメイン名とは異なる、未使用のドメイン名を使用します。たとえば、別のTLD（「example.com」とは対照的に「example.net」）または完全に異なるドメイン名を一
			緒に使用することができますが、それでもICANNには通常登録されています。このスキームのメリットは、
			内部的および外部的に同じ名前でいくつかのドメイン名（ "mail.domain.tld"など）を解決できることです。

			これは間違いありませんが、上記のような巧妙なDNSトリックを行うことで、他のスキームでも同じ効果が
			得られます。さらに、外部的に内部的に名前を解決するときは、不要なDNS命名の競合の可能性があるため
			、ドメイン全体でこれを行うことが望ましいかどうかは疑問です。このスキームはまた、わずかな量の機密情報（ドメイン名）をネットに漏洩させ、マイナーな追加コスト（ドメイン登録のコスト）を表しますが、わずかな利点しか提供しません。しかし、一部の組織にとっては有効なオプションかもしれません。そのようなスキームは、ISPや他のインターネットに焦点を当てた組織によって頻繁に使用されます。

Meisina04: /* ドメイン名のスタイルは長いです */

2018-03-23T02:54:47Z

ドメイン名のスタイルは長いです

← 古い版		2018年3月23日 (金) 11:54時点における版
126行目:		126行目:
	うな単一ラベルのドメイン名を "server.dnssuffix.tld"として解決しようとします。これは証		うな単一ラベルのドメイン名を "server.dnssuffix.tld"として解決しようとします。これは証
	明書でも有効です。必要に応じて、 <nowiki>"https://server.samdom.example.com/"</nowiki>の代わりに <nowiki>"https：//server/"</nowiki>に適した証明書を内部サーバーに発行できます。また、ある時点でDNS検索サフィックスのDNS検索サフィックスの使用を避ける必要がある場合は、最終的な '.'を含めることを覚えているFQDNを指定することでそれを行うことができます。ルートゾーンの場合		明書でも有効です。必要に応じて、 <nowiki>"https://server.samdom.example.com/"</nowiki>の代わりに <nowiki>"https：//server/"</nowiki>に適した証明書を内部サーバーに発行できます。また、ある時点でDNS検索サフィックスのDNS検索サフィックスの使用を避ける必要がある場合は、最終的な '.'を含めることを覚えているFQDNを指定することでそれを行うことができます。ルートゾーンの場合


			==== これは私の外部ドメインで正しく機能しません ====

			この仮定は間違っています。 AD DNSサーバーは、この単一のサブドメインおよびその下の名前に対しての
			み権限を持ちます。他のドメイン名については責任を負いません。したがって、あなたのADドメイン名が &
			quot;samdom.example.com"で、 <nowiki>"www.example.com"</nowiki>という名前を解決す
			るよう依頼した場合、それは <nowiki>"www.example.com"</nowiki>の権威ではないことを認識
			し、そのドメインに対して権限を持つ外部サーバーへリクエストを転送します。

			==== 私のNetBIOS名が競合する可能性がある ====

			有効な懸念。しかし、samba-toolとWindows DC Promoウィザードで提案されている名前は、単なる提案に過
			ぎません。任意のNetBIOS名を選択できます。あなたのドメイン名を基にしたものを選ぶのも良い方法かも
			しれませんし、NetBIOSドメイン名の他の関連しているがユニークな名前を選ぶこともできます。

			==== 私は内部的および外部的にホスト名を解決するために異なる名前を使用する必要があります ====

			はい、このスキームでは、ネットワーク外のDNSサービスがネットワーク内の名前を解決できないため、ネ
			ットワーク内の同じコンピュータを解決してネットワーク外で解決する場合とは異なるDNS名が必要です。
			ほとんどの場合、これは良いことですが、コンピュータの内部および外部のアドレスは一般に根本的に異な
			り、異なるIPアドレスを持ちます。

			しかし、状況によっては、この複雑な問題を構成に追加することはお勧めできません。たとえば、ユーザーが設定するメール設定を配布する場合、外部的および内部的に別のメールスキームを使用しなければならないという複雑さが増しすぎる可能性があります。モバイルデバイスでは、このスキームは実行可能ではないかもしれません。ありがたいことに、この問題の解決策がいくつかあります：

			* 外部名のトラフィックをネットワークにルーティングして戻すことを許可します。

			通常、この設定には余分な設定は必要ありません。外部IPアドレスのトラフィックバウンドは、最終的な宛先がネットワーク内に戻っても、他のインターネットバウンドトラフィックと同じように扱うことができます。

			* 名前を解決するだけのDNSゾーンを作成します。

			ゾーン内の単一のホストだけを解決し、残りのホストは外部サーバーによって正常に解決されるようにAD DNSで行うことができます。 "host.domain.tld"という名前のDNSゾーンを作成します（例： "mail.example.com"）。ゾーン内では、レコードの名前を空白のままにして、単一のAレコードまた
			はCNAMEレコードを作成します（おそらくCNAMEが優先されます）。ダイアログが示すように、この名前は親ドメイン（この場合は "host.domain.tld"）を解決するために使用されます。

			これは、あなたが望むものとまったく同じです。 "host.domain.tld"はDNSサーバーによって指
			定されると解決され、 "domain.tld"下の他のホストへの要求は外部的に解決されます。 "host.domain.tld"と "domain.tld"は異なるゾーン。親レコードとしてCNAMEを使用する場
			合は、これを内部ドメイン名のレコードに戻すことができます。

			== 無効なTLDの使用 ==

			このシナリオでは、 "SAMDOM.local"のように "domain.invalid.tld"の形式でドメインの名前を付けます。 .localや.internalなどの無効なトップレベルドメイン（TLD）を使用するのは、非
			常に一般的な方法でした。実際、MicrosoftのSmall Business Serverのすべてのバージョンは、「domain.local」の形式でドメインを使用するように構成されていました。 .local TLDは正式にICANNによって予約されているので、外部DNSサーバがこのドメインを解決しないことも保証されます。しかし、このスタイルの
			名前にはいくつかの大きな問題があります。

			* .local TLDはいくつかのzeroconfシステム、特にAppleのBonjourサービスで使用されています。一緒に使用すると正しく動作しません。
			* .localや.internalなどの無効なTLDは、まもなく主要な証明書プロバイダのいずれかからSSL証明書を取
			得できなくなります。 CA/Browser Forumは、2015年11月1日以降、これらの無効なドメインに対して証明書を発行しないことを決定しました。実際、この日付以降に有効期限が切れた証明書は購入できません。これには、その他の有効な証明書内で使用される主体別名（SAN）が含まれます（これはMicrosoft Exchangeの
			非常に一般的な構成です）。内部の証明機関にはこのような制限はありませんが、このオプションを使用することは常に有効です。
			* 現在使用している無効なTLDが将来有効なTLDになる可能性があります。 .localはICANNによって予約されていますが、TLDシステムは現在、サポートする汎用TLD（gTLD）を22から数千の新しい名前に拡張する予定です。この傾向は引き続き続く可能性が高い。

			同じ理由で、.internalと.lanを含む他の無効なTLDを持つ名前は避けるべきです。

Meisina04: /* このことが重要な理由 */

2018-03-23T02:53:39Z

このことが重要な理由

← 古い版		2018年3月23日 (金) 11:53時点における版
72行目:		72行目:
	DNS名が競合するように、NetBIOS名も競合する可能性があります。ほとんどの場合、これは問題にならないでしょう。 Windowsは名前解決の最後の手段としてNetBIOSを照会し、ネットワーク内にWINSサーバーがな		DNS名が競合するように、NetBIOS名も競合する可能性があります。ほとんどの場合、これは問題にならないでしょう。 Windowsは名前解決の最後の手段としてNetBIOSを照会し、ネットワーク内にWINSサーバーがな
	ければ、NetBIOS名はレイヤー2（サブネット）を越えることはできません。ただし、Active Directoryは重複した名前のPCを使用できないようにしていますが、通常はコンピュータ名の最初の15桁が同一である場合にのみ発生します。そのような名前の衝突は避けるべきです。		ければ、NetBIOS名はレイヤー2（サブネット）を越えることはできません。ただし、Active Directoryは重複した名前のPCを使用できないようにしていますが、通常はコンピュータ名の最初の15桁が同一である場合にのみ発生します。そのような名前の衝突は避けるべきです。


			=== NetBIOSドメインの名前付け ===

			NetBIOSは、どんなドメイン名でも受け入れられる可能性が非常に低く、潜在的な名前の競合を避けるため
			にできることは少ないです。通常、NetBIOSドメインのドメイン名から最初の部分を選ぶことが推奨されて
			います（「ワークグループ」の別名です）。たとえば、ドメイン名が "samdom.example.com"の
			場合、NetBIOS名 "SAMDOM"を選択することができます。 NetBIOS名に何を使用しても、15文字以内で、句読点を含まない1単語だけであることを確認してください。これにはピリオド"."が含まれます。これは、Windows 10クライアントでは特に重要であるようですが、NetBIOSドメイン名にピリオド
			が含まれているとドメインに参加できないという報告があります。

			== 私のドメイン名はどうすればいいですか？ ==

			あなたのオプションを見る前に、私たちのドメイン名が持つべき望ましい機能を見てみましょう：

			* ドメイン名は、グローバルに一意である必要があります。これにより、コンピュータがDNS解決に使用するように構成されている場合でも、名前が正しく解決されるか、ドメイン（NXDOMAIN）が返されなくなります。ドメイン名の競合は決してあってはなりません！
			* ドメインは組織に関連している必要があります。ドメイン名は理想的にはあなたの組織に関連している
			必要があります。覚えるのも簡単です。
			* ドメインはあなたのコントロール下にあるべきです。管理しているドメイン名（登録されている所有者
			）は、悪意のある使用を防ぐのに役立ちます。ドメイン名の登録は、いずれの企業にとっても安価で望ま
			しいものです。
			* あなたが望むならば、あなたはそれのためにサードパーティのSSL証明書を得ることができるように、ド
			メイン名はまだ有効なドメイン名であるべきです。

			これらの基準を念頭に置いて、いくつかのオプションを見てみましょう。

			== 自分が所有するドメインのサブドメイン ==

			このシナリオでは、 "samdom.example.com"のように "subdomain.domainyouown.tld"という形でドメイン名を付けます。'''これは通常、選択できる最良のオプションです！'''また、マイクロソフトの現在のベストプラクティスと整合しています。サブドメイン名はあなたが望むものであればどんなものでも構いませんが、短くてシンプルにするのはおそらく良い考えです（例えば "ad"）。こ
			の名前のスタイルは、私たちが望ましいドメイン名で示した上記のすべての基準を満たしています。最も重要なのは、

			* それは世界的にユニークです。ネット上のドメイン登録（およびおそらくそのDNSエントリ）を制御する
			ので、内部的に使用するドメインが外部的に何かに解決されないようにすることができます。
			* サードパーティSSL証明書を取得するための有効なドメイン名になります。

			=== 重要な注意点 ===

			あなたのドメインに名前を付けるとき、Windowsとsamba-toolはまた、提案の古いNetBIOSドメイン名を生成します。デフォルトでは、これは一番左のドメイン名の最初の15文字です。したがって、ドメインの名前が「ad.example.com」の場合、デフォルトの候補は単に「AD」になります。そのようなNetBIOSドメイン名を
			選択することは、同じNetBIOS名を持つ他のドメインと競合する可能性が高いため、悪い考えです。これは
			、これらの2つのドメイン間で信頼関係を確立する必要があった場合に問題になります。代わりに、ドメイ
			ン名に基づいてカスタム名を選択します。たとえば、「ad.example.com」という名前のドメインの場合は「EXAMPLE」を選択します。

			=== よくある異論 ===

			==== 私のユーザーログインが私の電子メールと一致しない ====

			あなたは正しかった、@記号の後に続くユーザー名の接頭辞（UPNサフィックス）の部分はドメイン名にデフォルト設定されているので、このスキームではデフォルトで "subdomain.domain.tld"になりま
			す。ただし、UPNサフィックスは任意で構成可能です。ユーザーの電子メールを含め、好きなように設定す
			ることができます。複数のオプションを使用することもできます。

			==== ドメイン名のスタイルは長いです ====

			接尾辞の追加は、好きなだけ短くすることができます（「広告」または「ds」を使用することは非常に一般的です）。ただし、DNSサフィックスとDNSサフィックスの検索リストを設定することで、ドメイン名の入力を完全に避けることができます。これらの変数が設定されると、クライアントは "server"のよ
			うな単一ラベルのドメイン名を "server.dnssuffix.tld"として解決しようとします。これは証
			明書でも有効です。必要に応じて、 <nowiki>"https://server.samdom.example.com/"</nowiki>の代わりに <nowiki>"https：//server/"</nowiki>に適した証明書を内部サーバーに発行できます。また、ある時点でDNS検索サフィックスのDNS検索サフィックスの使用を避ける必要がある場合は、最終的な '.'を含めることを覚えているFQDNを指定することでそれを行うことができます。ルートゾーンの場合

Meisina04: /* DNS階層 */

2018-03-23T02:52:39Z

DNS階層

← 古い版		2018年3月23日 (金) 11:52時点における版
33行目:		33行目:

	各DNSサーバーは、ゾーンと呼ばれる階層の異なる部分に責任を持っています。ゾーンは"samdom.example.com"やその下のレベルの全ての名前、例えば<nowiki>"www.samdom.example.com"</nowiki>、<nowiki>"ftp.samdom.example.com"</nowiki>やあるいは"server.samdom.example.com"のようなDNS名からなります。DNSサーバーは、担当するように構成されたゾーンへのリクエストに対して、信頼できる、あるいは最終的な回答を提供します。プロセスの詳細については、[http://en.wikipedia.org/wiki/DNS#Address_resolution_mechanism WikipediaのDNSページ]を参照してください。		各DNSサーバーは、ゾーンと呼ばれる階層の異なる部分に責任を持っています。ゾーンは"samdom.example.com"やその下のレベルの全ての名前、例えば<nowiki>"www.samdom.example.com"</nowiki>、<nowiki>"ftp.samdom.example.com"</nowiki>やあるいは"server.samdom.example.com"のようなDNS名からなります。DNSサーバーは、担当するように構成されたゾーンへのリクエストに対して、信頼できる、あるいは最終的な回答を提供します。プロセスの詳細については、[http://en.wikipedia.org/wiki/DNS#Address_resolution_mechanism WikipediaのDNSページ]を参照してください。

			=== なぜこれが重要か ===

			Active Directoryドメイン用に選択したドメイン名も、AD DNSサーバーが正式なプライマリドメインになります。 Active Directory内のすべてのPCは、このドメイン内に名前を持っています。 Active Directoryが正常に動作するためには、その一部であるコンピュータがこれらの名前をすべて正しく解決する必要があります。つまり、ドメイン内に存在するすべてのPCのDNSサーバーとして機能する必要があります。 2つのDNSサーバーが同じ名前を2つの異なるアドレスに解決するDNSの競合が発生すると、問題が発生する可能性があります。 DNSの競合は、IPアドレスの競合と違ってネットワークのフローから妨げられませんが、しばしばトラフィックが意図しないアドレスに流れる問題が起きる可能性があり、要求した名前は解決されたようで、まったく解決されないのです。

			たとえば、ADドメイン名を「samdom.example.com」とした場合、AD DNSサーバーは当然、階層の「samdom.example.com」レベル以下のすべての要求に対して権限を持ちます。これは、 "workstation.samdom.example.com"や "server.samdom.example.com"などのドメイン内の名前、またはDNSサーバー内で設定されている他の名前に対するすべての要求に直接応答します。 www.samba.orgをリクエストした場合でも問題はありませんが、samba.orgドメインには権限がないことがわかり、その名前を担当しているサ
			ーバにリクエストを転送してから、あなたに答えを返します。

			しかし、www.samdom.example.comのような外部のウェブサイトを持っていれば、おそらく別の外部DNSサー
			バによって処理されるでしょうか？さて、あなたがその名前を要求すると、DNSサーバーは "samdom.example.com"ドメインを担当し、あなたのための応答を探します。それがない場合は、このドメインの最終的な権限であると考えられるので、他のサーバーに要求を転送することはありません。そして、それはあなたに「そのような名前は存在しません」、つまりNXDOMAINを返します。

			=== セキュリティへの影響 ===

			技術的には、ドメイン名ごとの名前付けという側面ではありませんが、DNSのセキュリティへの影響は考慮
			する上で非常に重要です。あなたのAD DNSサーバにはあなたのネットワーク内のすべてのPCのリストが含まれています。ほとんどのDNSサーバは誰もドメイン名の完全なリストを要求することはできません（ゾーン
			転送とも呼ばれます）このリストからの情報は、依然として内部情報の不必要な露出と潜在的なセキュリティリスクを表しています。さらに、ほとんどのAD DNSサーバーは再帰的であり、インターネット上で再帰的なDNSサーバーを実行することは、このドキュメントの範囲を超えて重要なセキュリティの影響をもたらし
			ます。

			同様に、内部ネットワークの外部にある内部名のDNS要求を送信しないでください。 DNSサーバーを信頼し
			ていても、DNSは暗号化されていないため、トラフィックを通過するすべてのルーターに傍受の可能性があ
			ります。これは重大なセキュリティリスクを表します。このトラフィックを制御する攻撃者は、自分が望む場所にPCのトラフィックを誘導する可能性があります。

			これらの理由から、セキュリティで保護されたAD DNSサーバーは、ネットワーク内の要求のみを受信し、別のDNSサーバーはネットワーク外部のDNS要求を処理する必要があります。さらに、すべてのワークステーションは、外部DNSサーバーではなく、DNS用にAD DNSサーバーだけを検索するように構成する必要があります。これは[https://en.wikipedia.org/wiki/Split-horizon_DNS スプリットホライズンDNS]と呼ばれます。

			== NetBIOS名 ==

			WindowsがDNSを利用する前に、別の命名システム、NetBIOS（技術的にはNetBIOS-NS）、Windowsインターネットネームサービス（WINS）に依存していました。 NetBIOSはディレクトリサービスとして機能することができる点でDNSと似ていますが、名前階層の規定がないため制限があり、名前は15文字に制限されています
			。しかし、NetBIOSは、レイヤ2ブロードキャストドメイン（同じサブネット内のすべてのPC）に対してピアツーピアの名前解決の手段を提供します。マイクロソフトはこれをWINSで拡張し、レイヤ3（ルーテッド）
			ネットワークを横切って名前解決を提供しました。DNSサービスのないネットワークで名前解決が動作して
			いる場合、おそらくNetBIOSによって処理されています。

			これらのシステムの時代は今のところ私たちの後ろに位置していますが、このレガシーシステムの痕跡は、Windows全体ではまだ残っています。たとえば、ネイバーとその子孫のようなWindowsネットワーキングのいくつかの側面は、依然としてこのサービスに依存しています。特に、すべてのADドメインには、従来のDNS
			名とともにNetBIOS名があります。また、ドメイン内のすべてのコンピュータにNetBIOS名が付いています（NetBIOS名サービスを無効にしても）。ほとんどの場合、これはデフォルトでPC名の最初の15文字になりま
			す。

			=== このことが重要な理由 ===

			DNS名が競合するように、NetBIOS名も競合する可能性があります。ほとんどの場合、これは問題にならないでしょう。 Windowsは名前解決の最後の手段としてNetBIOSを照会し、ネットワーク内にWINSサーバーがな
			ければ、NetBIOS名はレイヤー2（サブネット）を越えることはできません。ただし、Active Directoryは重複した名前のPCを使用できないようにしていますが、通常はコンピュータ名の最初の15桁が同一である場合にのみ発生します。そのような名前の衝突は避けるべきです。