Cloudflare さんとこの public DNS が増えた。
Introducing 1.1.1.1 for Families
1.1.1.1 for Families
https://developers.cloudflare.com/1.1.1.1/1.1.1.1-for-families/
'2' がマルウェアなところからをブロック、 '3' がそれに加えてムフフなところもブロック。
ムフフなところブロックの例
$ dig 某ムフフなサイト +short @1.1.1.2
（普通に名前解決される）
$ dig 某ムフフなサイト +short @1.1.1.3
0.0.0.0
追記: （2020/4/26 に公開後、2023/3/24 に警告メッセージが表示されるようになったのでそれらしい箇所編集ずみ）
Secure IP: 9.9.9.9 Provides: Security blocklist, DNSSEC, No EDNS Client-Subnet sent. If your DNS software requires a Secondary IP address, please use the secure secondary address of 149.112.112.112
% dig twitter.com ns +short
ns1.p26.dynect.net.
ns2.p26.dynect.net.
ns4.p26.dynect.net.
ns3.p26.dynect.net.
% dig 37signals.com ns +short
ns4.p25.dynect.net.
ns1.p25.dynect.net.
ns2.p25.dynect.net.
ns3.p25.dynect.net.
% dig bit.ly ns +short
ns1.p26.dynect.net.
ns4.p26.dynect.net.
ns2.p26.dynect.net.
ns3.p26.dynect.net.
% for i in $(jot 4 1); do echo "--- ns${i}.p26.dynect.net"; dig @ns${i}.p26.dynect.net version.bind chaos txt +short ; doneどうハイジャックされたのかわからないけど、もしや bit.ly （の A RR）が書き換えられててもおかしくなかったのかな、と想像。BIND の事情よくわからんし、攻撃手法がわからないとなんとも・・？
--- ns1.p26.dynect.net
"9.6.1-P1"
--- ns2.p26.dynect.net
"9.6.1-P1"
--- ns3.p26.dynect.net
"9.6.1-P1"
--- ns4.p26.dynect.net
"9.6.1-P1"
Coverage:
- 8 Name servers (MaraDNS, MyDNS, PowerDNS, Bind, NSD, tinydns, ldapdns, dnsmasq)
- 5 caching name servers (Bind,PowerDNS,DNSCache, DNSProxy, Unbound)
- many Perl based scenarios
- Load balancing
- A HUGE variety of DNS Backend types (text files, DB, LDAP etc.)
- DNSSEC
- internationalization (i18n)
- OS Coverage of Windows and Linux
- incredible amount of detailed DNS products coverage never seen elsewhere !!
nlnetlabs develop nsd and unbound too. why? what's more it seems from the mailing list that the same people involved in both projects? so i've got a few querstions:
- why are to different name server?
- why not merge the two project?
再帰的名前解決の制限
フォワーダー（キャッシュサーバ）を構築する際に、許可をする再帰的名前解決の設定上の問題となります。LAN内部にフォワーダーを構築する場合は、この再帰的名前解決が有効になっているはずです。実際の設定は、/etc/named.confに以下の設定が書かれていると思います。
recursion yes;
LAN 内部のサーバであれば、これだけの設定でもさほど問題が発生することはありません。なぜならLANに接続できるのは許可されているクライアントと考えることができるからです。許可されていないクライアントが接続できる場合は、別のセキュリティ上の問題を解決する必要があります。
ここで問題とするのは、外部のプライマリをフォワーダーと兼用している場合になります。上記の設定がされていれば、名前解決については問題なく動作していることと思います。ですが、これだけでは再帰的名前解決を許可するクライアントの制限がされていないため、外部のクライアントからの要求も処理してしまいます。
その場合、DDoSの踏み台になる可能性があります。直接サーバに何かをするというわけではありませんが、DNSサーバを踏み台として特定のサーバへのDDoSの加担をすることとなってしまいます。つまり、知らないうちに加害者になってしまうのです。
再帰的名前解決を許可するサーバでは、上記設定と同時に以下の設定により、クライアントの制限をする必要があります。
allow-recursion { IP-Address; };
この問題については、2006年にJPCERT/CCより勧告が出ておりますので、目にした人も多いと思います。
===> domain: isuzu.co.jp ---> ns2.iprevolution.co.jp: x ---> elflock.isuzu.co.jp: o <=== ===> domain: suzuki.co.jp ---> dns-b.iij.ad.jp: o ---> dns-c.iij.ad.jp: o <=== ===> domain: subaru.jp ---> dns-c.iij.ad.jp: o ---> dns-b.iij.ad.jp: o <=== ===> domain: daihatsu.co.jp ---> majesta.tns.ne.jp: o ---> royal.tns.ne.jp: o ---> dkdns.daihatsu.co.jp: x <=== ===> domain: nissan.co.jp ---> sj000030.nissan.co.jp: x ---> nvs001.nissan.ne.jp: x <=== ===> domain: toyota.jp ---> majesta.tns.ne.jp: o ---> ns1a.toyota.co.jp: x ---> ns1b.toyota.co.jp: x ---> royal.tns.ne.jp: o <=== ===> domain: honda.co.jp ---> slasher.honda.co.jp: o ---> ns.spin.ad.jp: x ---> ns.tokyo.spin.ad.jp: x ---> hornet.honda.co.jp: o <=== ===> domain: mazda.co.jp ---> ns2.mazda.co.jp: o ---> rx7.mazda.co.jp: o ---> ns-tk012.ocn.ad.jp: x <=== ===> domain: mitsubishi-motors.co.jp ---> dns-b.iij.ad.jp: o ---> dns-c.iij.ad.jp: o <=== ===> domain: hino.co.jp ---> dutro.hino.co.jp: o ---> royal.tns.ne.jp: o ---> majesta.tns.ne.jp: o <===
