IPv6 / 戯れ言

2012-11-02 Fri

■ RHEL6/CentOS6では、single-request-reopen を必須にしたい… [IPv6]

結論から言えば、とりあえず RHLE6/CentOS6 な人は /etc/resolv.conf に

options single-request-reopen

を書いておこうという話です(全部小文字ですよ、念のため）

なぜか？

RHEL5/CentOS5/Ubuntu 10.04なLinuxとかでは、FQDN の解決をするときに

DNSキャッシュサーバに AAAA RR の Queryを投げる
AAAA RR の Reply を受ける
DNSキャッシュサーバに A RR の Queryを投げる
A RR の Reply を受ける

という挙動でしたが、RHEL6/CentOS6 では

DNSキャッシュサーバに A RR の Queryを投げる
DNSキャッシュサーバに AAAA RR の Queryを投げる
A RR の Reply を受ける
AAAA RR の Reply を受ける

となります（3., 4.は入れ替わる可能性はあります）

＃すいません！厳密には、遊べる RHEL6 の環境を持ってなかったので未確認ですが、同じ挙動なはず

これは、過去の経緯とかを考えると、よりよい実装になったと言えそうなのですが、１つ問題があって、1., 2. で、Query を投げる側の source port番号が同一となっています(要は、socket を使い回している）

で、なにが困るかというと、世の中の Firewall で、この同一ポートからの Query を同一のセッションと見なすものがあるのです。
そうすると、なにが困るかというと、

DNSキャッシュサーバに A RR の Queryを投げる
DNSキャッシュサーバに AAAA RR の Queryを投げる
たとえば AAAA RR の Reply を受け取る
Firewall が通信が終わったと判断して、セッションを close する
残りの A RR の Reply が Firewall で drop される。
A RR の結果を受け取れなかったので、今度は別々に Queryを投げる
A RR の Query を投げる。
A RR の Reply が返るまで待つ。
A RR の Reply を受け取る。
改めて AAAA RR の Queryを投げる
AAAA RR の Reply を受け取る。

こんな感じになります。最終的には名前が解決されるので、めでたしめでたし、なんですが、実際 A RR の Query を再送(fallback)するまで、５秒程度の時間がかかります。

たかが 5秒、されど 5秒。

最近のサーバは、サーバ間連携で外部のAPIを叩くことも珍しくありません。API のコール毎に、DNS を引いていたとしたら、この遅延が蓄積され、エンドユーザで体感するレスポンスの遅延は、数十秒以上になることもあります。

このあたりは man resolv.conf に書いてあります。

     single-request-reopen (since glibc 2.9)
           The resolver uses the same socket for the A and AAAA requests. Some hard-
           ware mistakenly only sends back one reply. When that happens the client
           sytem will sit and wait for the second reply. Turning this option on
           changes this behavior so that if two requests from the same port are not
           handled correctly it will close the socket and open a new one before send-
           ing the second request.

ここまでわかってるなら、default で、socket を別々に作ってくれよと思うのですが、オプションでの回避となっているようです。

＃最近のUbuntuはどうなのか、確認する環境が手元になったので、わかりませんが、たしか最近は glibc 使ってなかったと思うので、問題は起こさないかも？？

かくして、せっかくIPv6のために改善された挙動が、IPv6に起因するあらたな問題を生み出してしまったようです。Firewall が問題だ！という話もありますし、実際 Firewall側の設定変更で、回避可能な問題ではあるんですが、MacOS X 10.8.2 とかでは、query の source port は、別々なので、問題を引き起こしません。

ともあれ、すべての人に問題が発生するわけではなく、環境依存ではありますが、「IPv6無効にしたら早くなった」ネタが、新たに誕生してしまったのが切ない…

追記：2012-11-05 画像追加。文章調整しました。glibcのバージョンの言及を削除しました。

カテゴリ：IPv6

■ RHEL6/CentOS6では、single-request-reopen を必須にしたい… [IPv6]

■ ハンズオンセミナー 2日目 [Linix][IPv6]

■ 鳥取環境大学でお話 [Linux][IPv6]

■ IPv4/IPv6 meter [IPv6]

■ Google over IPv6 [IPv6][Google]

■ にぽたん研究所にIPv6の話 [IPv6]

■ IPv6 での逆引き設定 [IPv6][DNS]

■ EDGE Co.Lab v6 [IPv6]

■ IPv6 CARE [IPv6]

■ IPv4枯渇時計 [Network][IPv6]

■ 日本で、6to4ルータが復活？ [IPv6]

■ Google IPv6 Statistics [IPv6]

■ ソフトバンク、IPv6、10Gbpsサービスのサービス提供に向けて顧客収容機器を置き換え [IPv6]

■ Ubiquity が話題らしい [Firefox][IPv6]

■ IPv4アドレス枯渇問題の真相に迫る [IPv6][Network]

■ IPv6 時代に備える辞書 [IPv6][よもやま]

■ IPv6接続 [IPv6]

■ ipv6.2ch.net建設予定地 [IPv6]

■ Shim6 [IPv6]

■ IPv6対応はアジア市場のため [IPv6]

■ 鳥取環境大学でお話　 [Linux][IPv6]