【DNS】Name Server 総合スレ Part2
■ このスレッドは過去ログ倉庫に格納されています
■主なオープンソース
BIND ttp://www.isc.org/software/bind
djbdns ttp://cr.yp.to/djbdns.html
NSD ttp://www.nlnetlabs.nl/projects/nsd/
Unbound ttp://unbound.net/
PowerDNS ttp://www.powerdns.com/
■規格
RFC1034 ttp://www.ietf.org/rfc/rfc1034.txt
RFC1035 ttp://www.ietf.org/rfc/rfc1035.txt
■アプライアンス
Nominum ttp://www.nominum.com/
Infoblox ttp://www.infoblox.jp/
■ついでに
ISC DHCP ttp://www.isc.org/sw/dhcp
Solarisのシステム管理
(DNS、NIS、LDAP 編) http://docs.oracle.com/cd/E19683-01/817-4911/
(FNS、NIS+ 編) http://docs.oracle.com/cd/E19683-01/816-6236/
Windows Server のDNSは省略だよもん |:::ハ:.:.:.:.:.:i:.:.:i.:.:i./.:.://メノ 左ォ}::::ノ::ノノ
|::::i:::';::::::::l、::i:::ハ:/,ィチ爪' {ヒチ'!::イイ
|ハ::::::ヾ::::ハ 'Vリ ゙´ {、込ソ ゛″!:::i:.:l
|:.::ト、:.:.:ヾ:.ハーi| :::::::: 〉 ノ::::i::.|
{:.:.ト、ヾ.:.:.:ヾハ lト、 _, , イ:.:.:.:i.:ハ
ヾ::ヽゞ、\.::.\!! ヽ、. ´ /!.::!.:.i:.:!:.!:l >>1乙ぱい
, '" ヾ\ \:::::::::k /` ー ' `メ'リ:.:.ノ.ノ:ノノ
/ 川 リllVハ. ( i `\ ,イイ// //
/ |l ̄`ヽ ノ `メ、
,/ {:} `ー'- ニ_
,/ _∠ |l \ , \
/ _ ,. イ´: |l \ ,λ
/ -‐‐‐-<´ .! / |l ' , _,ィ'ンy}
〈 \ .ノ`ー斗rェ,,_,_,_|l ,.ir'彡イy-´ !
`ヽ、 ` ' <._ {jt=t-t-ミ`^Yーrヘr-彡'水k} !:} .ノ
` ー- .._ ` -ヽ. l`亠^{:i ̄ {:リ |ハ ノノ/ノ
_,. -‐ '  ̄ ´ ̄` ー- 、 \{{ {:l {:i ノ_,ィニ_ン´
// `ヽ 、\ \ {:l {∠ニァ--'
/ / `ヽミニ>ァ┴ '´
/\V| /
./ ヾ.、 ,. ' ´ キャッシュポイズニングの開いたパンドラの箱
ttp://www.e-ontap.com/dns/endofdns.html
キャッシュポイズニングの開いたパンドラの箱 -2-
ttp://www.e-ontap.com/dns/endofdns2.html DNSSECしてますか?
先ごろプロバイダにDNSのセカンダリーを依頼したんですが
プロバイダのDNSがDNSSECしてませんでした。orz それ以前にDNSSECのキーを登録できないレジストラが多すぎ。 DSレコード登録させてくれたらそれでいいのにな
でも利用者が少ないのは確実だから改修したくないんだろうね >>15
もう使ってないのでDSレコードは削除したけどアカウントの削除方法が不明なんだよな。 自分のドメイン example.jp があって、プロバイダのドメインが example.com とします。
自前のDNS(dns1.example.jp)のIPアドレスは a.b.c.d、プロバイダのDNS(dns1.example.com)のIPアドレスは w.x.y.zとします。
プロバイダのDNSにセカンダリーを依頼しています。
example.jp NS dns1.example.jp
example.jp NS dns1.example.com
dns1.example.jp A a.b.c.d
としているあるのですが、これを
example.jp NS dns1.example.jp
example.jp NS dns2.example.jp
dns1.example.jp A a.b.c.d
dns2.example.jp A w.x.y.z
とするのは宜しくない設定でしょうか。
w.x.y.z は変更される場合は置いといて。 なぜ宜しくないかもしれないと思ったのか教えてください。
うーむ・・・どの部分がひっかかっているのでしょう? w.x.y.z の逆引きが dns2.example.jp
ではない、とかじゃないですよね? 何かと問われると、自分では気が付いていない宜しくないことがあるのかもしれないという不安です。 プロバイダのDNSはDNSSECしてないので
dns1.example.com A w.x.y.z
は署名がありません。
dns2.example.jp A w.x.y.z
にすれば、自分のドメインなので署名できます。 内部名にするのはいいことだ、と言われてる。
が、DNSホスティング業者がサーバのIPアドレスを変更したら名前解決できなくなる。
そしてたいていの場合、アドレス変更は予告なくおこなわれる。
アドレスは金輪際変えないよ、と明言してるのであればいいかもしれんけど。 セカンダリ引き受けサービスをして貰うくらいなら、
ゾーン転送許可用にサーバIPを連絡されているのでは?
それなら、IP変更前に連絡はくるんじゃないか? ゾーン転送のソースのIPアドレスは指定されています。
whoisに登録するDNSはホスト名で指定されています。
現状、これらのホスト名とIPアドレスは一致しています。
ゾーン転送のソースとセカンダリDNSのサービスIPが
この先も一致しているとは限りません。一致させない
理由は特に考えられませんが。
dns2.example.jp A w.x.y.z
と設定する w.x.y.z が急に使われなくなるのは、まあいいとしても
w.x.y.z が突如キャッシュサーバーに変身することがあると
困るかもしれません。 なるほど。DNSSEC 署名するため、自ドメイン名で外部ネームサーバを
登録したいということですね。その気持ちは理解できる気がします。
それに >>22 さんの言うように、内部名の方が好ましいとする考え方も
ありますしね。
んで本題の「宜しくないのか」という点ですが、IP アドレスの変更に気を
付ける必要があるというのは既出ですが、DNS 的には問題ないように
思えます。やってみてもいいんじゃない? やってみましたのですが、プロバイダのDNSが
dnssec-enable no;
になってるような…。bindなのかどうか分かりませんが
bindなら、そうなってるような。
dig @(プロバイダのDNS) (自分のドメイン) +dnssec
でRRSIGが表示されません。
DNSSECに対応しているかどうか、問い合わせ中です。 dnssec-enable no相当の設定してるとこは結構あるぞ
昔DNSSEC機能まわりでBIND9の脆弱性が出たときにdnssec-enable no
とすればワークアラウンドになることがあって、その時の設定が
そのまま入ってるとこが沢山ある。
あと、ブロードバンドルータの類がDNSSECというかEDNS0に
対応してるのはほとんどない。
こんなんじゃDNSSEC普及に何年かかるのやら ローコストで委託できるようにならないと普及はムリな気がする 上位にDSをアップロードするプロトコルができても、
そもそもDSを含む鍵更新の手順が複雑すぎて、ふつうのオペレータ
には対応不可能というのが問題。これ自動化されても問題の本質は変わらない。
何かがおかしくなったときに人手でちゃんと修正できるようになって
初めて実用になるが、たかがDNSをセキュアにするためだけに
全てのオペレータにプロトコルとPKIを精緻に理解することを要求する
DNSSECは人的コストがかかりすぎる
(さもなくば運用ミスは直ちにbogusになって引けなくなり、
さらにキャッシュのため修正しても回復に時間がかかる)
IETFとかのDNSSECやってる連中は想像できないかもしれないが、
オペレータにはDNS以外にもやらなきゃならないことは沢山あるのだ まぁこれはDNSSECだけじゃなくて、DNSCurveとかにも同じことは
言えるけどな DNSCurve・DNSSECそれぞれ固有の難しさがあるが、
難易度は大きくは変わらないだろう IETFではプライバシー保護の観点でのDNS over TLS/DTLSの議論が
始まってるけどな。こうなるとDNSSECとは何だったのかということ
になりかねないが
>>9
「パンドラの箱」とはおそれいった。
記事中では新規性が無いという指摘を巧妙に回避するための
レトリックを使っているが、こういう煽り記事を書いて目立たないと
いけない私大の先生も大変だな
毒がいわゆるin-bailiwickルールにマッチしていればDNSキャッシュサーバ
はそれを受け入れる(すでにキャッシュ上に同じデータがあれば
RFC2181 Rankingに従い上書きされる)という従来からある話に過ぎない。
基本的な対策はポートランダマイゼーションというのは6年前から
変わっていない。ポートランダマイゼーションしてないキャッシュサーバが
10%もあることは頭が痛いが。
この人は以前カミンスキー攻撃でDNSに毒は入らない、BIND9のバグに
過ぎないと主張していたが、こういう誤解を生む主張は全く迷惑だ。
カミンスキーの本質はそれではなく、TTLがoff-path攻撃からの保護にならず、
攻撃の成功確率を大きく向上させることができることを示したことだ。
カミンスキー以降、どのような毒が入るか研究が進んで、2010年前後に
にその手の論文や解説がいくつか出ているが、概ね↑で書いたものだ。 >>32
元文章を理解して書いているとは思えない内容ですが…?? 従来の攻撃法の範疇だしポートランダム化が
緩和策いうのはその通りだけど、攻撃成功した時の影響が
大きいということでしょ。カミンスキーと類似の攻撃で
ポート・TXIDのランダム化を突破できれば、
TLD丸ごと、SLD(co.jp)丸ごと乗っ取れるという話。
TLDをターゲットにした具体的な攻撃法を示したのは
新規と言っていいんじゃないの
この人よほどDNSSEC嫌いなのか知らんけど、ポートランダム化だって
限界があるしDNSSECくらいしか次の現実的な対抗策はなさそう
(NSEC3はOptOpt無しでな)
RFC2181のルールを見直しても穴がありそうだし DNSSEC難しいことは言われなくてもわかってるよ
でも他に何があるのさ? まともに運用できる人がほとんどいない技術じゃ無いのと同じだろ
浸透いうな・大岡山の両氏はDNSはオワコンであきらめろと言っとるよな。 DNSSECに対応しなくてもサービス提供側は困らない、というのも理由の一つじゃないでしょうか。
むしろDNSSECしたら「お宅だけメールが送れないので、お宅のメールサーバーがおかしいですよ」と言われてorzする。
さすがに今はないか? DNSやめて別のにするのとDNSSECやるのとどっちが難しいかという話じゃね
別のを作ってもDNSと同じものができそうw 今の世界は腐ってるから一度リセットしろなんて聞き飽きた
いい歳して何を言ってんだ、いまどきマンガでもねえよ 現実的な代替策を提案するでもなく世界は腐ってると叫ぶだけじゃなあ 別にDNSは今のままでいいんじゃない。
サイト証明したければSSL使えばいい。 >>34
2008年当時でも、TLDの乗っ取りができないなんて話は誰もしていなくて
ポートランダマイズしてなければあらゆるものが簡単に乗っ取れる
という空気だった。
tss氏が示した毒が、ポート・TXIDのランダマイズをすり抜けられれば
TLDやSLDを乗っ取れるし、それが重大なのもよくわかるけど、
それは2008年当時から状況は変わらない。よくわからないのは、それでなにを
主張したいのかということだ。
ポートランダマイズを無効にする攻撃法を見つけたという主張なのか?
ポートランダマイズではもう不足だと言いたいのか?
ランダマイズしてないのがいっぱいあるのでランダマイズしろよという主張なのか?
カミンスキー的な攻撃は頻繁に行われているがRFC2181 Rankingによって
結構守られていた(今回そうでない毒を見つけた)という主張なのか?
DNSSECでもNSEC3 Opt-Out運用ではinsecure delegationを毒と
して入れることが可能なので、Out-Outはやめろと言いたいのか?
DNSは欠陥だらけで手の施しようがないので、もうやめろということなのか?
非専門家ばかりが騒ぎ、専門家の反応がいまいちなのはそのあたりなんじゃないか。 化けの皮がはがれるから、はっきり主張できないんだろ
attackerに情報を与えることになるから
詳細は公表しないって逃げるに決まってる >>43
ポートランダマイズの効果を薄くする方法はある…っぽいが、
オープンリゾルバで無ければ大丈夫かと思う。
普通のフルリゾルバであれば、とりあえずランダマイズで
対応する、で行くしかないんじゃないかな。
ただ、TXID&ランダマイズを抜けた後の手法がより危なく
なったので、ポイズニングに対する監視は充実させたほうが
よいのかもしれない。
unboundなら、「unwanted-reply-threshold」設定とか、
その他ならば、パケットキャプチャでクエリとレスポンスの
割合とかを見ておくとかかな?他にもあればPLZ.
いずれにせよ、今全てを投げ出すわけにもいかんのだし、
やれることを粛々と頑張るしか無いよね。 オープンでもクローズでも、基本的な動作原理は変わらないのでは?
それに一口にオープン良くないというけど、そのオープンてどういう定義なの?
オープンは危ないという風評被害もありそう >>46
え、オープンリゾルバに定義いくつもあるの? ISPのDNSサーバは、ISP加入者全てからのクエリを受けつけるようにしてるのでかなりオープンに近いけどな。ISP加入者がボットに感染してるとか普通にある >>46
あまり詳しく書くのははばかられるが、オープンだと
ポートランダマイズの効果を下げる事前作業がやりやすい
>>48
許可NW内のBOTを使えば、同じようなことは出来るので、
許可NWが多いリゾルバとかは危険かもしれない
いずれにせよ、そういうところは監視による警戒を厳
として、危険な兆候が見られたら即対応などを考えて
おいたほうがよいのかもしれない もう監視しかないんですかね。それに検知したら出来ることって何でしょう GoogleDNSって、たしかUnbound使ってたと思うけど
何か特殊な設定仕込んでるのかなぁ
自前でオープンリゾルバなDNS公開設定しようかと思ってるんだけど・・・
用途は、避けたいサイト(正引き)で127.0.0.1を返すため
スマホとかで自前DNSを利用したい >>50
JPRSも書いてたけど、危ないと思ったらキャッシュクリアするとか…
あとは攻撃元IPを見つけたら、BANして通報とかかな。
>>51
GoogleDNSは権威側で動作を見てると、多段で構成されてるっぽい。
フロントはオープンだが単なるフォワーダっぽいリゾルバみたい。
バックエンドはオープンでないフルリゾルバで、フロントからの
問い合わせにだけ答えている模様で、こちらは色々対策している
のでは無いかと思う。 ■ このスレッドは過去ログ倉庫に格納されています