月: 2012年11月

かなり昔の続き。

DNS周りを整理していて、sambaサーバのホスト名をipv4とipv6で同じにしたら例の問題が再発。

もしやと思ってsmb.confのhosts allowに <prefix>::/64 を追記したら問題が解消した。

単に、名前を引く→AAAAが返ってくるのでipv6アドレス:445にアクセス→hosts allowにないから拒否 となっていただけっぽい。

これでしばらく様子を見てみる。

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を書いておくことにする。

忘れないようにリンクを張っておく。

＠IT総合トップ > Master of IP Network > キャッシュDNSサーバのDNSSEC対応

最初から順を追ってトラストアンカーの設定をしたけど、使っているのがbind9.8なので options のところに

dnssec-validation auto;

と書くだけでOKというオチ。

一応、

> dig +dnssec jprs.jp

; <<>> DiG 9.6.-ESV-R5-P1 <<>> +dnssec jprs.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23804
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...

と、status NOERROR、ad flag でdnssecがちゃんと機能していることを確認。

CNAMEとAAAAを同じホスト名に設定できない件、RFC1912に載っていた。

RFC1912の2.4章。

2.4 CNAME records

   A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.edu, or an A record, or
   even a TXT record.  Especially do not try to combine CNAMEs and NS
   records like this!:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      CNAME   mary
           mary            IN      A       1.2.3.4

   This is often attempted by inexperienced administrators as an obvious
   way to allow your domain name to also be a host.  However, DNS
   servers like BIND will see the CNAME and refuse to add any other
   resources for that name.  Since no other records are allowed to
   coexist with a CNAME, the NS entries are ignored.  Therefore all the
   hosts in the podunk.xx domain are ignored as well!

   If you want to have your domain also be a host, do the following:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      A       1.2.3.4
           mary            IN      A       1.2.3.4

   Don't go overboard with CNAMEs.  Use them when renaming hosts, but
   plan to get rid of them (and inform your users).  However CNAMEs are
   useful (and encouraged) for generalized names for servers -- `ftp'
   for your ftp server, `www' for your Web server, `gopher' for your
   Gopher server, `news' for your Usenet news server, etc.

CNAMEは他のいかなるデータと共存できません、特にNSと共存させると名前引けなくなりますよ、とな。