UDPを使うDNSで応答パケットを偽装してDNSキャッシュにウソデータを送り込む、いわゆるキャッシュポイズニング対策で、DNSサーバが権威サーバに問い合わせる際の送信元ポート番号をランダム化するというのがある。
で、自宅のDNSサーバをルートに問い合わせるようにしたときにどうなるのかを確かめてみた。
まずはプロバイダのDNSサーバをforwarderに設定したときの応答
> dig -x dig +short porttest.dns-oarc.net TXT porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "210.130.xxx.xxx is GREAT: 26 queries in 2.8 seconds from 26 ports with std dev 20098"
std dev 20098 で GREAT判定。(210.130.xxx.xxxはおそらくプロバイダのDNSサーバアドレス)
次に、forwarderを設定しない場合
> dig -x dig +short porttest.dns-oarc.net TXT porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "125.30.y.yy is GOOD: 26 queries in 3.1 seconds from 26 ports with std dev 1156"
std dev 1156 で GOOD と今ひとつな感じ。(125.30.y.yy はPPPoEで自宅に振られたアドレス)
BIND自体は最新のものを使っていてちゃんと source port randomization されているはずなので、少し考えてみた。
もしかしてもしかすると、NATが悪さしてるか？と思い、RTX810のNAT descripterをいじってみた。打ったコマンドはこれ。
nat descriptor masquerade unconvertible port 1000 if-possible
1000はPPPoE(IPv4)用のNAT descriptor の番号。
IP マスカレードで変換しないポート番号の範囲を設定する。 if-possible が指定されている時には、処理しようとするポート番号が他の通信で使われていない場合には値を変換せずそのまま利用する。
とのことなので、ポート番号に関してはNATでほぼ透過的になるはず。で、試してみた。
> dig -x dig +short porttest.dns-oarc.net TXT porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "125.30.y.yy is GREAT: 26 queries in 3.4 seconds from 26 ports with std dev 4859"
std dev 4859 で GREAT判定。少し良くなったけど、プロバイダのDNSサーバには遠く及ばない感じ。
NATが関係していることはわかったけど、forwarderを指定すればすべてうまくいくことも分かったので、named.confにはforwarderを書いておくことにする。