「RFC3484」では、DNSが同一サーバ名に対し複数のIPアドレスを持つ場合に「自分のアドレスに近いアドレスを優先的に選択する」ことを定めており[1]、Windows Vistaなどマイクロソフト製OSの一部や、最近のLinuxなどではこのルールに従いDNSラウンドロビンがデフォルトで無効にされている
http://ja.wikipedia.org/wiki/DNSラウンドロビン


Windows Vista and Windows Server 2008 have a new TCPIP stack that supports IPV4 and IPv6 natively. This new stack follows RFC 3484 “Default Address Selection for Internet Protocol version 6” for IPV6 and for IPV4 when possible. This RFC attempts to select the closest IP address rather than using DNS round robin’s random selection.
http://support.microsoft.com/kb/968920


世の中のxpがvista以降に切り替わったら、ほぼラウンドロビンはされないということだろうか。

http://www.ietf.org/rfc/rfc3484.txt

RFC3484をちらっと見てみると、Aレコードを複数設定することの意味がなくなったというわけではなさそう。DNS問い合わせの観点で見ると、名前を問い合わせて複数の結果を取得した場合に、アプリケーションに返すIPアドレスのリストの並び替えの方法について、RFC3484の内容が適用されるようだ。アプリケーションは並び替えられたIPアドレスを順にアクセスして、駄目だったら別のIPアドレスを使用する(ことが求められている)ということはそのままのようなので、耐障害性の点ではこれからも意味があるということだろう。
これまでは受け取ったIPアドレスのリストを特に並び替えはせずにアプリケーションに渡していたので、DNSサーバが応答する複数のIPアドレスの順番を変えて応答していたのが、そのままアクセス先のIPアドレスの優先順位が適用されていた、ということだと理解している。

並び替えの優先順位はアクセス元のIPアドレスによって決定されるので、アクセス元が適当に分散していれば、アクセス先も適当に分散されることになるのだろう。DNSラウンドロビンという手法自体が、負荷状況を考慮しない単純なラウンドロビンであることが一つの弱点ではあったが、その弱点がより顕著になったと見るべきか、適切かもしれない経路が優先される分、改善されたと見るべきかはよくわからない。いずれにしろ負荷状況に応じた分散にはならないという性質に変わりはない。ただし、TTLを短く設定しても、同じアクセス元は(IPアドレスが変わらない限り)同じIPアドレスにアクセスすることになりそうだ。

NATによって、アクセス元がプライベートIPアドレスを使用している場合に、アクセス先がどのように決定されるのかは理解できていない。現在のインターネット接続環境の状況から想像すると、インターネットからのアクセスではこのケースが最も多そうなので、このときの動作がどうなるかは把握しておきたいところだ。仮にそのままアクセス元を192.xxxとか172.xxxとかで決定されると、全然分散されず特定のIPアドレスに偏りそうだ。もしプライベートIPアドレスの場合には、並び替えを行わないというのなら、ほぼこれまで通りの効果が期待できるし、そうでないというなら、DNSラウンドロビンの負荷分散機能はほぼ失われたように思う。


では、いわゆるDNSラウンドロビンではない方法で、DNSによる負荷分散をどうすれば良いかを考えると、DNSサーバが複数のIPアドレスをリストにして返すのではなく、リクエストを受けるたびに単独のIPアドレスを動的に応答するようになっていれば良い。ただし、単独のIPアドレスしか返さないと、アクセス元の方でIPアドレスのリストを順にアクセスしてくれるようなことがなくなるので、確実に生きているIPアドレスを応答する必要がある。そのためには、DNSサーバはそれぞれのIPアドレスのヘルスチェックを行い、死活を把握していなければならないし、TTLを非常に短くして大量の照会にも耐えなければならない。

というわけで、ISPの可用性を高めたり、ISP回線の負荷を分散する類の製品はそういうことをやるようだね。
bindとかDNSサーバレベルでは実装されていないのだろうか。DNSレコードの動的更新の機能を用いて他ソフトウェアから実現することも可能なようにも思えるが、動的更新をそんなに激しく(短くしたTTLよりもさらに短い頻度で)実施して良いものなのかも私には判断できない。

もうちょっと調べて、よく考えてみないと、なんともいえないな。