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

---

2012-11-02

---

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

options single-request-reopen

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

なぜか？

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

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

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

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

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

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

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

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

1. DNSキャッシュサーバに A RR の Queryを投げる
2. DNSキャッシュサーバに AAAA RR の Queryを投げる
3. たとえば AAAA RR の Reply を受け取る
4. Firewall が通信が終わったと判断して、セッションを close する
5. 残りの A RR の Reply が Firewall で drop される。
6. A RR の結果を受け取れなかったので、今度は別々に Queryを投げる
7. A RR の Query を投げる。
8. A RR の Reply が返るまで待つ。
9. A RR の Reply を受け取る。
10. 改めて AAAA RR の Queryを投げる
11. 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のバージョンの言及を削除しました。

---

---