cNotes 検索 一覧 カテゴリ

IPv4/v6デュアルスタック環境での名前解決の不思議

Published: 2011/02/27

ほとんどの通信の基本となる名前解決ですが、IPv4/v6デュアルスタックな環境での動作はなかなか難しいことになります。

デュアルスタック環境での名前解決の挙動に関しては、AなのかAAAAなのかといった単純な話ではなく、次のことに注意する必要があります。

  • クエリーの順序

クライアントが名前解決する際にAを先に聞きに行くのか、AAAAを先に聞きに行くのか?また、機能実装にもいろいろあって、Aの応答があったら、それをそのまま使うのかAAAAの結果を待つか?など。

  • トランスポート

名前解決のためのトランスポートはIPv4なのかIPv6なのか?

IPv4のリゾルバとIPv6のリゾルバが設定されている場合、どちらのリゾルバが利用されるのか?


簡単ですが、クエリ順序とトランスポートの関係の代表的な例をまとめるとこのようになります。

WindowsXPはIPv6トランスポートでの名前解決をサポートしていないためIPv6通信を行いたい場合でもIPv4トランスポートでの名前解決が必要になります。

WindowsVista/7は、Aを優先、IPv6トランスポート優先で名前解決を行います。つまりIPv4のサイトを見たい場合でもまずIPv6トランスポートで名前解決をすることになります。

Apple系はAとAAAAをほぼ同時に送出してAAAAの応答があればそちらを使おうとするようです。

これからIPv6対応が進んでいくことを考えると、OS的に見ても、IPv6側のDNSを利用して名前解決を行ってIPv4通信もIPv6通信も行うというパターンが一番多いでしょうかね。

なんとなく、問題が発生しそうなアプリケーションがありそうですが、それ以外にもこの図のIPv4とIPv6のプロバイダが同じならいいですが、サービスの利用の仕方によっては異なる可能性もあるわけで、そうなるとIPv6側のプロバイダのDNSで名前解決をして、通信はIPv4側のプロバイダを経由して行うみたいな、複雑でちょっと気持ち悪いことになり、なにかトラブルがあったときはプロバイダ側もかなり切り分けに困ることになりそうです。名前解決トラブルはかなりの問題になりますから。


また、DNSを利用したさまざまなサービスコントロールやセキュリティ対策機能が用いられていますが、この挙動はそれらの機能にも大きな影響を与えてしまう気がします。

例えば、代表的なものとして

  • ユーザーが利用するリゾルバサーバーを元に最適経路をみつけるCDN
  • DNSBLやDNSポイズニングによるブロッキング

IPv4側でDNSBLやポイズニングによる対策などが行われていたとしても、IPv6サービスを追加で契約した場合、前述の挙動を考えると、基本的にIPv6側のDNSに聞きにいくことになり、そちら側にIPv4と同等の機能が対応していないと、まったくコントロールが効かないということになります。

IPv4とIPv6両方共同じプロバイダのサービスを利用してIPv4/IPv6どちらを経由しても同じDNS、同じ機能の提供を受けることができれば、ここで懸念するような問題は起こりにくいと思いますが、IPv4とIPv6が別々のプロバイダになる可能性もあるわけでその場合はこういったDNSを利用したサービスや機能は使い物にならない可能性があります。

DNSは名前解決だけのものだから、他の機能に使わないでと言われることもありますが、商用インターネットサービスにおけるセキュリティ対策のために、苦肉の策を10年以上かけて積み上げてきた結果という面もあるわけで、これらの機能、手法が使えなくなるのはかなり辛いことになるでしょう。

いろいろ案を考えないと。。。。。

ちなみに、今回の例は、最も単純な構成をベースにしていますが、例えばブロードバンドルータやHGWが間に入っている場合には、それらの装置に搭載されるDNSプロキシやDNSキャッシュの機能などにより、トランスポートの差分吸収や変換が行われる場合もあるため、前述の例とは異なる挙動を示す場合もあります。ユーザー環境の条件ごとにいろいろな組み合わせでいろいろ評価しないといけないでしょう。

装置も構成も無限にありますが。。。。。

[カテゴリ:IPv6観察日記]

by jyake