IPv6/迷惑な運用とその回避

Describe IPv6 関連の迷惑な運用とその回避 here.

1. IPv6 関連の迷惑な運用とその回避

qmail.jp の DNS サーバーのログを見ていて、タイプ AAAA, A6 などの問合せが多いことに気づきました。問合せ全体の 3 分の 1 以上、ひょっとすると半分あったかもしれません。

三つの DNS NS レコードに対して、それぞれに AAAA, A6 の問合せがきています。 IPv6 は使っていませんので、これらの問合せには否定返答が返るだけです。実験的位置付けの A6 の問合せが多いというのは特に問題です。

1.1. どこから問合せがきているか

qmail.jp のセカンダリサーバがゾーンデータを取得するときに多く発生していました。また、ウェッブコンテンツの複製サービスサイトからの問合せも発生していました。これらが IPv6 を使いたくて問合わせているのではないことはすぐに分りました。

1.2. なぜ？

FreeBSD の default kernel には IPv6 が組みこまれています。
- (影響は理解していません。)
BIND 9 の default configure では IPv6 は autoselect になっていました。手元のマシンでは IPv6 が組込まれました。
BIND 8, 9 では recursion yes, fetch-glue yes だと、IPv6 アドレスも取得しようとすると聞きました。BIND 9 の次期バージョンでは A6 の問合せは default では行わないように変更されるとのことです。
ssh, rsync は default configure すると IPv6 を使うように設定されます。
AAAA, A6 レコードは存在しませんので、NODATA が返事となります。
- これは正しい実装のキャッシュサーバなら
  [wiki:rfc2308 RFC2308 negative caching] の TTL 時間キャッシュされます
[wiki:DjbDns:tinydns-data.html tinydns-data] が生成する negative caching TTL は default では 2560 秒です。
dnscache (djbdns) は negative caching TTL は最大 1 時間です。
Negative caching を RFC に忠実に実装できていない DNS サーバがあるようです。ある MS のドキュメントには Negative caching の TTL の default は 5 分だとありました。

1.3. qmail.jp ドメイン DNS コンテンツサーバでの対策

Negative caching TTL を大きく指定する。
- (tinydns-data を使って自動生成した) TTL は 2560 秒になっていました。 SOA レコードの negative caching TTL を 86400 秒に直します。 SOA レコード自身の TTL もおなじ値にする必要があります。
NS レコードを複数持っていることも影響しているので、 NS レコードをひとつにします。ただし、名前には複数の A レコードを定義します。

TTL を長くすると、設定を間違えたときに解消されるまでに時間がかかると心配する人がいます。 DNS の仕組み(分散データベース)から来るものです。キャッシュの効果とネットワークトラフィックの妥協の産物ですから、受入れるしかありません。自分のことしか考えない人はネットワークに接続しないで欲しいものです。