DNS のデボルブ動作に関して

Windows 7 および Windows Server 2008 R2 のデボルブ動作が以前の考え方から変更になりました。

また更新プログラム

Post-installation behavior on client computers after you install the DNS update
http://support.microsoft.com/kb/957579/en-us

を以前のOSに適用することによって、Windows 7 や Windows Server 2008 R2 と同様の動作を行うことになります。

DNSのラウンドロビン

DNSのラウンドロビンは枯れた技術で様々な企業で使用されています。

具体的にはDNSの登録する1つのホスト名に対して複数のIPアドレスを登録しておきます。クライアントからの要求に対して順番に先頭のIPを変更して異なるサーバーのIPアドレスを返すことにより負荷分散を行わせるものになります。

ホスト名としてWebserverが以下のように登録してある場合は

Webserver.test.net A 192.168.0.100
Webserver.test.net A 192.168.0.10
Webserver.test.net A 192.168.0.11
Webserver.test.net A 192.168.0.15
Webserver.test.net A 192.168.0.20

クライアント側にこれらのリストが返され、先頭の 192.168.0.100 が使用されます

そして別の端末がWebserverの名前解決を行うと

Webserver.test.net A 192.168.0.10
Webserver.test.net A 192.168.0.11
Webserver.test.net A 192.168.0.15
Webserver.test.net A 192.168.0.20
Webserver.test.net A 192.168.0.100

クライアント側にこれらのリストが返され、先頭の 192.168.0.10が使用されます

このような動作により負荷分散を行います

本日、同僚が研修でテストしていたら思ったような動作にならないと言ってきました。そして調べてみるとWindows Server 2008 と Vista ではラウンドロビンがうまく動かないことがわかりました

どのような動作になるかというと DNSキャッシュの内容が以下のエントリで入ったとします

Webserver.test.net A 192.168.0.100
Webserver.test.net A 192.168.0.10
Webserver.test.net A 192.168.0.11
Webserver.test.net A 192.168.0.15
Webserver.test.net A 192.168.0.20

このようなリストが返されると、一番小さいアドレス（longest match）が選択される仕様になっているようです

2009/11/09 追記
2009/11/18 追記

私の理解が少々間違っていましたので訂正します

実際にはまず自分のIPアドレスを確認します。たとえば、自分のIPアドレスが192.168.0.1だとすると、自分のIPとラウンドロビンのIPを比較します。

11000000 10101000 00000000 00000001 = 192.168.0.1 = Client IP to match.
11000000 10101000 00000000 01100100 = 192.168.0.100 = (24 + 1 = 25 bits matching the client IP)
11000000 10101000 00000000 00001010 = 192.168.0.10 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001011 = 192.168.0.11 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001101 = 192.168.0.15 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00010100 = 192.168.0.20 = (24 + 3 = 27 bits matching the client

ここでIPアドレスのマッチングを行います。第3オクテットまでは同じなので第4オクテットに着目します。

192.168.0.10
192.168.0.11
192.168.0.15

が28bit matchなので、この中の先頭のIPアドレスが選択されます。

ですのでこの場合は 192.168.0.10 が選択され続けることになります。

これはVistaよりIPv6がデフォルトで動作する仕様変更に伴い、RFC3484に従ったためにおこるものらしいです

ただし、実機確認してみると意外なことが判明！

この動作は同一セグメントでの動作で、異なるセグメントの場合はちゃんとラウンドロビンが動作しました。

Pingでのテストによると、もしマッチングビットが同じで通信が不可能な場合キャッシュに登録された順番にIPを試します。結果的に通信が確立されたIPがあった場合はそのIPに固定された通信を行います。

192.168.0.10（不可）
192.168.0.11（不可）
192.168.0.15 追記はここまで（2009/11/09）

この動作を以前と同様にするにはレジストリの変更が必要になります

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
DWORD = OverrideDefaultAddressSelection
Value data: = 1

ちなみに、Windows7 と Windows Server 2008 R2 ではこのレジストリがデフォルトで1になっています（キーは存在しません）。よって、クライアントにWindows7を使用している場合は特に問題はないということになりますね。

参考

DNS Round Robin and Destination IP address selection

いや～、知らなかったな～～～

DNSのフォワーダ 追記しました

以前投稿しました

DNSのフォワーダ

ですが、追記しました。情報の間違いがありましたので訂正いたします。

DNSのフォワーダ

DNS設定でフォワーダの構成を行う際の注意点があります。

ではそもそも、フォワーダの動作はどのようになるのか？

通常DNSの動作としては、クライアントから再帰クエリとしてDNSサーバーが受け取ります。そして、DNSサーバーは目的のホストが見つかるまで反復クエリを繰り返して、最終的に権限のある応答として目的のホストアドレスを受け取ります。そしてクライアントへの応答してアドレスを返答します。

フォワーダの設定を行うと、DNSがクライアントと同じ動作を行います。よって、クライアントから再帰クエリを受け取り、それを再度DNSサーバーに再帰クエリとして送信します。

これは外部DNSと内部DNSを分離して、内部DNSにフォワーダの設定をするシナリオによく使用されます。

では設定画面を確認します。

ここで着目してほしい場所があります。それは「フォワーダが利用可能な場合にルートヒントを使用する」というチェックボックスになります。では、ここで英語版の設定画面を見ます。

原文では「Use root hints if no forwarders are available」になっています。

ん！これは・・・本当なら「フォワーダが利用不能な場合にルートヒントを使用する」が正しい翻訳になるぞ

ということで、日本語の意味が全く逆になります。

では、このチェックの利用方法は？

そもそも、これはDNSの排他モードと非排他モードの設定になります。

• 排他モード
  フォワーダがDNSクエリを解決できない場合、フォワーダーを利用する側のDNSサーバーは元のDNSクエリの発行者にクエリの失敗を返します。その際、DNSサーバーは自分でDNSクエリを解決しようとはしません
• 非排他モード
  フォワーダがDNSクエリを解決できない場合、フォワーダを利用する側のDNSサーバーがDNSクエリを解決しようとします。

ということで、正しい翻訳を元に考えると「排他モード」はチェックオフで、「非排他モード」はチェックオンになります。

2009年2月4日追記

実機検証した結果、どうやらチェックオンが「排他モード」になりました。ということは英文が間違っているということになるようです。実際には、[Don’t use root hints if no forwarders are available]になり、[フォワーダが利用不能な場合でもルートヒントは使用しない]になりますね～

この結果を踏まえて現在マイクロソフトに問い合わせ中ですので詳細が分かり次第追記します。

2009年2月25日追記

マイクロソフトからの正式回答が来ました。

ここから～

– 動作について

「フォワーダが利用可能な場合にルートヒントを使用する」および、「Use root hints if no forwarders are available」 共にチェックの ON、OFF では下記の動作となります。

※ 結果として、Windows Server 2008 においても、Windows Server 2003 と同様の動作となります。

– チェックが有効 (ON) な場合

フォワーダのみでルートヒントは利用しない (排他モード)

– チェックが無効 (OFF) な場合

フォワーダに問い合わせて応答が無いとルートヒントに問い合わせる (非排他モード)

上記動作について、弊社上位部署に確認させていただきましたところ、今回の現象は、2 重の問題が関係していることが判明致しました。

1. 英語版の UI の表記が実際の動作とは、反対の動作になっている

2. 日本語版の UI の表記が英語版の UI を誤訳している

本件につきましては、上位部署に報告させていただいており、公開情報の作成を検討しております。

しかしながら、現時点では具体的な公開日については、明確となっておらず、公開日についてご案内することができません。

ここまで～

どうやらKB化されるようです。

まとめ

フォワーダの設定を行う場合は、一般的な環境では「フォワーダが利用可能な場合にルートヒントを使用する」チェックボックスをオフ「オン」にする「排他モード」にします。なぜ排他モードにするかというと、フォワーダによるDNSクエリが失敗した際に、フォワーダを利用する側のDNSサーバーが反復クエリを行い「再帰の処理」を実行したところで、結果はフォワーダと同様に失敗すると考えられるからになります。