Name Server 総合スレ【DNS】

**名無しさん＠お腹いっぱい。** · 2008/11/26(水) 01:14:36

立ててみるだよもん

●主なオープンソース
BIND
ttps://www.isc.org/software/bind
djbdns
ttp://djbdns.qmail.jp/
NSD
ttp://www.nlnetlabs.nl/projects/nsd/
Unbound
ttp://unbound.net/

●規格
RFC1034, 1035
ttp://www.ietf.org/rfc/rfc1034.txt
ttp://www.ietf.org/rfc/rfc1035.txt

●アプライアンス
Nominum
ttp://www.nominum.com/
Infoblox
ttp://www.infoblox.co.jp/

**名無しさん＠お腹いっぱい。** · 2011/08/31(水) 20:13:19.22

>>684
それ系のメーリングリストも一緒に購読しておくと
名無しでもそれをやってるのが誰なのか見当が付いてくるｗ

まぁ他人のドメインを使っちゃうのはまずいとは思うけどね。
Hoge Lumber Companyさんのドメインとかｗ

**名無しさん＠お腹いっぱい。** · 2011/08/31(水) 20:19:43.64

Glueレコードですか、なるほど
その設定をレジストラのサイトで探せばいいわけですね、わかりました
ありがとうございます

**名無しさん＠お腹いっぱい。** · 2011/08/31(水) 20:24:04.38

>>684
rootサーバが使ってると思われるゾーンファイルは
各トップレベルドメインのNSがずらーっと書いてあって
さらにその下にそのNSが指してる名前のAやAAAAも
ずらーっと書いてあるね。

**名無しさん＠お腹いっぱい。** · 2011/08/31(水) 21:08:12.43

運用上はどうでもいい疑問かもしれませんが、
NSレコードの設定ってTLDを管理してるネームサーバに直接記録されるんですか？
それともレジストラのネームサーバに記録されるんですか？

**名無しさん＠お腹いっぱい。** · 2011/08/31(水) 23:07:19.92

>>688
「TLDを管理しているネームサーバ」と
「レジストラのネームサーバ」を具体的に考えれば分かる。
たぶん。

**名無しさん＠お腹いっぱい。** · 2011/08/31(水) 23:42:34.03

実在するドメインを例示に使わないのは当然のマナー。
example教は俺も嫌いだが、主張は全く正しい。

**名無しさん＠お腹いっぱい。** · 2011/09/01(木) 00:06:41.26

爺か？爺なのか！？

**名無しさん＠お腹いっぱい。** · 2011/09/01(木) 00:22:57.66

マナー(笑)

**名無しさん＠お腹いっぱい。** · 2011/09/01(木) 00:24:01.05

若さしか取り柄のないDQNが開き直りですか

**名無しさん＠お腹いっぱい。** · 2011/09/01(木) 00:48:19.25

example教が「DNS & BIND」とか見れば発狂するよなー
movie.eduとか何だよｗｗｗ
第4版まではこの体たらくだが
第5版では直ってるのかな？

**名無しさん＠お腹いっぱい。** · 2011/09/01(木) 03:35:43.46

example教の糞なところは、example.なんとかを使えとでしゃばるくせに
質問にはノータッチなところだろ。
質問に答えられないほどの無能なのに何やってんの？みたいなｗ

**名無しさん＠お腹いっぱい。** · 2011/09/01(木) 09:34:09.39

第5版でも movie.eduだよ >>694
突っ込むなら先にこっちだよね

**名無しさん＠お腹いっぱい。** · 2011/09/01(木) 19:27:45.59

俺はおっさんなのでacme.comが好きだ

**名無しさん＠お腹いっぱい。** · 2011/09/01(木) 23:51:54.41

>>697
初めて見たときはドキドキしたのを思い出した
そんな俺もおっさん

**名無しさん＠お腹いっぱい。** · 2011/09/02(金) 03:41:59.64

Plan9のエディタかと思ってどきどきしちゃった

**名無しさん＠お腹いっぱい。** · 2011/09/02(金) 07:38:11.63

打ち合わせでマニュアルの例示見ながら皆でacme連呼してたな～

**名無しさん＠お腹いっぱい。** · 2011/09/02(金) 09:46:41.52

電話番号の例示にも 0×0-1234-5678 っていうのがよく使われるが、
実在するぞ。さぞ迷惑だろうな。

**名無しさん＠お腹いっぱい。** · 2011/09/02(金) 09:54:01.85

懸賞の当選者名の例示にもセシウムさんっていうのがよく使われるが、
実在するぞ。さぞ迷惑だろうな。

**名無しさん＠お腹いっぱい。** · 2011/09/02(金) 10:16:36.43

>>701
それは実在しないだろ。

**名無しさん＠お腹いっぱい。** · 2011/09/02(金) 12:04:35.28

>>703
正規表現でないから分からないと申したか

**ひろゆき** · 2011/09/12(月) 08:21:56.06

続きはこちらで

くだらない質問はここに書き込め!なんでもアリ24
http://pc.2ch.net/test/read.cgi/unix/1053748966/

BIND その2
http://pc.2ch.net/test/read.cgi/unix/1042989999/

djb(3)
http://pc.2ch.net/test/read.cgi/unix/1047117464/

**名無しさん＠お腹いっぱい。** · 2011/09/21(水) 19:07:13.05

8.8.8.8でiPhoneが速くなった!と言ってる人がそれなりにいるということは
余程グダグダなDNSキャッシュサーバが多いってことなのかのう

**名無しさん＠お腹いっぱい。** · 2011/09/21(水) 22:34:19.67

禿携帯のインフラがクソなのは鉄板じゃないか

**名無しさん＠お腹いっぱい。** · 2011/09/22(木) 01:24:08.18

>>707
3G回線のDNS変更じゃないぞ

**名無しさん＠お腹いっぱい。** · 2011/09/22(木) 07:40:12.28

8.8.8.8とか結構改善されているかも

**名無しさん＠お腹いっぱい。** · 2011/09/22(木) 12:22:51.45

>>708
あほん興味ないから知らんかった
検索してみたら気味悪いくらい拡散してるな

禿のばらまいたアクセスポイントがキャッシュサーバになってて
キャッシュにヒットしないから遅いって話じゃないの？

**名無しさん＠お腹いっぱい。** · 2011/09/22(木) 20:03:36.76

8.8.8.8であるCDNサーバ引くとRTT倍増ｷﾀｺﾚｗ
相変わらず使えねーじゃん

**名無しさん＠お腹いっぱい。** · 2011/09/23(金) 01:40:20.25

>>706
十分にユーザ数があれば、メジャーなサイトは大体キャッシュ済み
になるので8.8.8.8がやってるプリフェッチの優位性も薄れるし、まともに
運用されているISPのDNSキャッシュのほうが総合的に良い結果になるはず
なんだけど、やっぱりまともでないキャッシュが多いんだろうなぁ

**名無しさん＠お腹いっぱい。** · 2011/09/23(金) 10:01:59.85

児ポトラップがかなりのオーバーヘッドになってそうｗ
あとIPv6関連か。

最近一発目はアドレスが存在しないエラーが出るサイトが時々ある。

**名無しさん＠お腹いっぱい。** · 2011/10/10(月) 19:05:31.08

unboundのprefechって、キャッシュにヒットしたレコードの
TTLが残り少なくなってたら裏で問い合わせをしてTTLを更新するってものなんだな
"popular items"じゃわからんつーの > マニュアル

さすがに放っておいても勝手に問い合わせして
キャッシュを維持するようにしたら怒られるか。

**名無しさん＠お腹いっぱい。** · 2011/10/11(火) 09:49:28.93

>>714
google public dnsなんかも同じようなことやってるはず。

今は確認してないが、サービス開始当時はそんな挙動をしてたよ。

**名無しさん＠お腹いっぱい。** · 2011/10/11(火) 16:36:12.33

DNSのプリフェッチは、キャッシュサーバがやるにしろクライアントが
やるにしろデメリットが大きい割にメリット少ないのでやめてほしいところ。
Unboundのプリフェッチはまだお行儀がいいほうだが、
FirefoxやChromeがやってるプリフェッチはISPのDNSキャッシュサーバの
負荷を無駄に上げるだけで、結果的に悪くなる方向に誘導しているに等しい。
ベンチマークで勝つためには必要かもしれないが。

**名無しさん＠お腹いっぱい。** · 2011/10/12(水) 09:58:20.03

>>716
ブラウザのプリフェッチとキャッシュサーバの
プリフェッチは少し意味合いが違うんじゃ？

キャッシュのは、ちゃんとTTLが切れてから普通
に1回聞きに来るだけだし、googleのだと使用頻度
に応じて、キャッシュを維持する候補から外れる
みたいだし。

ブラウザのはたしかにキャッシュに負担が掛かる
ので、はた迷惑だけどね。

**名無しさん＠お腹いっぱい。** · 2011/10/12(水) 17:41:00.76

UnboundはTTLが10%を切ったキャッシュ済みレコードにクエリが
あったときにそのレコードをプリフェッチする。すべての
DNSキャッシュサーバがUnboundのプリフェッチをするようになると
人気があるドメインのDNS権威サーバの負荷が10%上がる。

Unboundのプリフェッチはデフォルトでオフだし、unboundあまり
普及していないから問題にはならないけど、同じことをBIND9でデフォルトで
オンで実装されると困る人が出てくるかも。
ブラウザのプリフェッチほどひどくないけど。

**名無しさん＠お腹いっぱい。** · 2011/10/13(木) 10:23:16.97

>>718
たしかに負荷はあがるけど、自分が管理してる
ドメインへのクエリのレスポンス速度が他人の
キャッシュでも上がると考えれば、うれしい人
もいるかも？

キャッシュが落ちてる時の初回応答ってかなり
時間掛かったりするから、その辺が改善される
ならば、自分的にはうれしい。

**名無しさん＠お腹いっぱい。** · 2011/10/13(木) 13:03:54.36

プリフェッチの恩恵あるのは、そのレコードのTTLのexpire直後に同じクエリを
出すことになる最初のユーザのみ。2人目以降は、
人気があるドメインやキャッシュサーバならキャッシュ済み、
そうでなければやっぱりexpireしてるかのどちらか。

Unboundのプリフェッチの実装は悪くは無いと思うけど、そのTTL切れ
直後の1ユーザのためだけに、キャッシュ・権威双方で10%の負荷を
上げてまでやるほどのメリットがあるかは微妙だと思う。
もう少し厳密に評価はしたほうがいいけど。

**名無しさん＠お腹いっぱい。** · 2011/10/13(木) 19:00:00.60

負荷の高いキャッシュだと、初回応答の遅れが
他への影響が大きくなるパターンとかがあった
希ガス。

BINDだと、スレッドの大半がそのサイトの応答
待ちになって他のクエリが…とか、dnscacheだと
シングルスレッドの待ち行列が詰まるとかそんな
話を聞いたような？

いずれにせよ、聞いた話なので、確かに厳密な
検証は必要ですね。

つーか、そろそろUnboundを真面目に検証する
時間が欲しい。いい加減業務でも使ってみたい。

**名無しさん＠お腹いっぱい。** · 2011/10/13(木) 19:56:48.10

づぴぴｗｗづぐうぃｗちゆうぃｗぴうぃｗ

**名無しさん＠お腹いっぱい。** · 2011/10/14(金) 03:29:52.55

昔のことはあまり知らないけど、数万qpsのクエリを処理するキャッシュサーバ
運用してる立場から言わせてもらえば、パケット再送やlame delegationで再帰
問い合わせに時間がかかるケースは頻発するので、それくらいで待ち行列が
溢れて黙りこんでしまうキャッシュサーバは今時有り得ないですね。

Unboundは速いしセキュリティホール少なくていいんだけど、
BINDでは引けるがUnboundで引けないドメインが何個か見つかっているのが心配。
だいたい権威サーバ側の問題なんだけど、BINDは権威サーバの問題に
寛容であの手この手で頑張って引いてくれる。Unboundはかなり
厳格で引けなかったりする。いくら権威サーバ側の問題でも、
お客さんにとっては引けないよりも引けるほうがいいからね。

たとえば Unbound users MLでも出てるけど、BINDとUnboundの
DNSSEC規格解釈の差が原因で、DNSSEC ONのUnboundでは faa.gov が
引けない (BINDでは引ける) 問題は絶賛進行中。

**名無しさん＠お腹いっぱい。** · 2011/10/14(金) 10:29:29.88

dnscacheは同時クエリー上限がUDP 200、TCP 20になってる。
この程度は大規模なキャッシュサーバだとわりと簡単に溢れる。
この値はハードコーディングされてて設定ではいじれない。

**tss** · 2011/10/14(金) 10:53:52.70

寛容というかいいかげんだからおかしなドメインが溢れかえるし、毒入れなんかもおきやすくなる。
BINDが寛容にみえるのは、過去仕様をころころかえている自分を許すため。
過去には、バグで毒入れできるのをDNSの仕様が悪いなんて嘘をついてもいるし。
これについてはまだ真相は表では語られていない。

**名無しさん＠お腹いっぱい。** · 2011/10/14(金) 14:35:26.00

>>724
dnscacheっていうかdjbの思想として、
1台のDNSキャッシュに多数のクライアントぶら下げるんじゃなくて
各自ローカルのキャッシュ動かせ、というのがあった気がする
大規模キャッシュという使い方はあまり想定していないように見える

>>725
その真相を語ってくれよ先生

**名無しさん＠お腹いっぱい。** · 2011/10/14(金) 18:47:12.00

マルチスレッド動作のBINDだと、キャッシュExpire後の
初回問い合わせが応答遅いと、他のスレッドで同じクエリ
を出してて応答待ち状態なのに、クエリを出しちゃうとか
はあったかも。

あと、Windowsなんかだと、優先DNSの応答が遅いとすぐに
代替DNS側にもクエリが行くので、代替に負荷が溜まりや
すかった気がする。特にネガティブキャッシュになるレコ
ードだと顕著だったかと…

まあ、ささいな話なんだふが。

>>724
昔どっかのMLでソースを改変してる人を見たような気が
したけど、何かの理由であまり効果がなくてうんぬん
とか話してた気がする。

**tss** · 2011/10/16(日) 00:16:26.83

そのうち語る予定。

**tss** · 2011/10/19(水) 17:29:55.06

>>726
昨日、DNSOPS-JP ML へ真相の一旦を流しました。
http://www.e-ontap.com/dns/bindmatrix.html

**tss** · 2011/10/20(木) 00:09:45.00

一端 orz

**名無しさん＠お腹いっぱい。** · 2011/10/20(木) 18:29:27.61

トリップつけてblogのどこかに書いておきなよ先生
ここID出ないんだから

**名無しさん＠お腹いっぱい。** · 2011/10/20(木) 19:04:32.57

こういところで自サイトの宣伝する奴はカスだな

**名無しさん＠お腹いっぱい。** · 2011/10/20(木) 20:50:12.60

書かれてることはウソではないんだろうが、
3年後にドヤ顔で言われてもなぁ
「DNSプロトコルの脆弱性てはない」
というところは議論の余地はありそうだが
議論しても何も生産的なことはなさそうなんで何も言わない

**名無しさん＠お腹いっぱい。** · 2011/10/22(土) 21:48:20.54

ほげー

**名無しさん＠お腹いっぱい。** · 2011/10/23(日) 19:38:53.40

崩壊→浸透→移行の次は
「Kaminsky attackはウソだった！」ですか
売名も大変ですね私大教員も楽じゃない

**tss** · 2011/10/24(月) 08:17:57.55

ウォッチしていてくれてありがとう ;-)

**名無しさん＠お腹いっぱい。** · 2011/10/26(水) 00:26:02.00

BIND 9.7.3-P3なんだけど、forwarders経由の情報を
ネガティブキャッシュしないっぽいんだけど設定がおかしいのかな？
NXDOMAINもNXRRSET(Aしかないドメイン大してAAAAを引いた場合)
もキャッシュしないみたいなんですが。

// named.conf はこれだけです↓
options {
forwarders { 10.0.0.1;}; // プロバイダのキャッシュサーバ
forward only;
};

**名無しさん＠お腹いっぱい。** · 2011/10/26(水) 00:28:21.10

ネガティブキャッシュしないというのは、
NXDOMAIN/NXRRSETになるパターンだと必ずプロバイダのキャッシュサーバ
に聞きに行ってるということです。ポジティブキャッシュは効いてるみたい。

**名無しさん＠お腹いっぱい。** · 2011/10/26(水) 19:31:34.97

ほんとだ。何か理由があるのかな。

**名無しさん＠お腹いっぱい。** · 2011/10/26(水) 20:15:55.47

ちょうど上でKaminsky attackの話が出てきたので思ったんだけど．．．

ポジティブキャッシュするけどネガティブキャッシュしないってことは
Aしかないドメインに、ニセのAAAAレコードを追加する攻撃が成功する
確率が上がるんじゃね

**tss** · 2011/10/26(水) 22:02:45.90

良いところに気がつきましたね ;-)

**名無しさん＠お腹いっぱい。** · 2011/10/27(木) 00:04:49.70

あんたいつも上から目線だな

**名無しさん＠お腹いっぱい。** · 2011/10/30(日) 01:14:35.72

タイムスタンプみればわかるだろ
寂しいんだよ

**名無しさん＠お腹いっぱい。** · 2011/10/30(日) 17:16:01.51

「浸透いうな」が言葉狩り扱いされて残念でしたね先生
その上から目線の態度じゃ仕方ないけどね

**名無しさん＠お腹いっぱい。** · 2011/10/30(日) 18:36:26.37

なんで最近「浸透言うな」ネタがはやってるん？
タイムラグが起きる事を端的に表した良い言葉だと思うんだけど
TTL調整は当たり前だろうに

**名無しさん＠お腹いっぱい。** · 2011/10/30(日) 19:36:38.26

言葉狩り、とレッテル貼るだけ、ってのも言葉狩り
同じ穴の貉なんだけどなw

**名無しさん＠お腹いっぱい。** · 2011/10/30(日) 19:50:24.92

>>745
今騒がれてる「浸透」問題はTTLはほとんど関係ない　言葉の問題でもない
DNS権威サーバの構成や設定や変更手順がまずくて、権威サーバでDNSレコードを変更しても、
TTLが経過しても、世間のキャッシュサーバのデータが新レコードに
なかなか更新されない現象に関する問題

ただ何だか知らんがtss先生が上から目線で「浸透いうな」とtweetしまくって
くれたせいで世間には言葉の問題と捉えられてしまった
（あの文書長くて読む気しないし）

さらにどういう意図か知らないがオレンジ氏が先日の講演で
「浸透という言葉は技術的におかしい」という話だけに終始して言葉の
問題であることを強調してしまった。オレンジ氏ってJPRS広報担当だそうだが

どいつもこいつもオ㍗ルな……

**名無しさん＠お腹いっぱい。** · 2011/10/30(日) 20:41:03.02

「浸透」という言葉を当てるなということ？
Virtualが仮想ではないということのように。

**名無しさん＠お腹いっぱい。** · 2011/10/30(日) 21:16:27.04

>>748
DNSの仕組みがわかっていれば「浸透」と表現することはない。

**名無しさん＠お腹いっぱい。** · 2011/10/30(日) 21:47:21.11

クライアントが問うまでレコードは一切流れないもんね。

**名無しさん＠お腹いっぱい。** · 2011/10/30(日) 22:02:19.49

わかってる人がどう言ってるのか教えてください
ボクもわかってるフリをしたいです

**名無しさん＠お腹いっぱい。** · 2011/10/30(日) 22:23:59.74

地球に天体が衝突しそう！

NASA「地球はよく小惑星が落ちてくるんで仕方ないですわー」（本当は軌道を変える方法があるのに）
tss「小惑星いうな」
Orange「あれを小惑星と呼ぶのは技術的におかしい。小惑星の定義とは……」

こうですかわかりません＞＜

**名無しさん＠お腹いっぱい。** · 2011/10/31(月) 01:32:50.05

それクスッともこないんだけど

**名無しさん＠お腹いっぱい。** · 2011/11/03(木) 23:12:21.80

教授達も、PacketiX VPNでネットワーク作るなり
ＤＮＳの経験を積ませればいいのに･･･
すでに日本にはマシな技術者がいないという事か･･･

**名無しさん＠お腹いっぱい。** · 2011/11/04(金) 00:16:02.07

なぜSoftEther

**名無しさん＠お腹いっぱい。** · 2011/11/04(金) 00:26:07.59

同じリスト＆キャッシュポイズニング的な意味で
「qmail.jp」「e-ontap.com」は要注意ですね

**名無しさん＠お腹いっぱい。** · 2011/11/04(金) 01:14:37.80

大学准教が多数のDNSサーバを攻撃中！（ソースはニュー速）
ってtwitterにデマ流せばいいのか

**名無しさん＠お腹いっぱい。** · 2011/11/04(金) 01:36:33.07

次のテンプレで閲覧注意が丁度よいかと
さすがに攻撃はせんでしょ

**名無しさん＠お腹いっぱい。** · 2011/11/04(金) 01:38:11.93

くだらねーことしてる暇があったらRFC1912をupdateする活動してくれよ先生

**名無しさん＠お腹いっぱい。** · 2011/11/04(金) 09:54:56.03

>>759
RFC1912って何かマズいの？

**名無しさん＠お腹いっぱい。** · 2011/11/04(金) 10:36:46.56

>>758
危険なＤＮＳサーバとやらで見に行った後
何されるかわからんけどなｗ

**名無しさん＠お腹いっぱい。** · 2011/11/04(金) 22:00:47.52

>>760
RFC1912の内容がさすがに古いんじゃねってこと
Informational RFCのupdateってあるのかどうかしらんけど、
オープンリゾルバやソースポート固定や「浸透」の問題を明示的に
書いたRFCも無いと思うので、そういうのを盛り込んで更新するのがいいと思う
日本国内だけの問題じゃないしね

**名無しさん＠お腹いっぱい。** · 2011/11/04(金) 22:07:41.49

open resolverはRFC5358があるか

**名無しさん＠お腹いっぱい。** · 2011/11/07(月) 15:42:13.05

DNSが「浸透」するものならinfiltrationとかpenetrationとか言われてるんだろうけど、
実際にはpropagationと言われてるからそれは伝播だろうということだな？

**名無しさん＠お腹いっぱい。** · 2011/11/07(月) 19:25:15.63

tssさんの調査かと思った
named[1822]: client 74.115.28.50#10053: query (cache) 'dankaminsky.com/A/IN' denied

**tss** · 2011/11/08(火) 09:05:39.00

propagation いうな

**726** · 2011/11/12(土) 21:17:03.17

>>729
盛り上がって？ますな

jinmeiさんの言うとおり、Kaminskyの発表自体には誤りはあったけど、
原理は依然有効で、BINDのバグが無くてもニセ委任情報の毒入れ
（の確率を上げること）は可能だしその議論も既出なんだよね。それでよくね？
もう屁理屈モードに入ってきてるけど、あんまり人に絡むもんじゃないよ先生

それにKaminsky attackは間違いだったということをあまり強調しすぎると、
port randomizationみたいな対策しなくていいよという話にもなり
かねんと思う。先生も良くご存じのように、どうせちゃんと説明しても
理解する人は少数なんだし。

ちなみに、DNSSECディスりたくて仕方ないようだけど、誰がプロモしようが
今のままのDNSSECは運用が難しすぎてディスるまでもなく
普及しないから無視していいと思います。まぁ、スペック表に○を増やしたい
人もいるのは見逃してやれよ。DNSなんて差別化できなくて久しくて、
リストラの危機に常にさらされてるわけだから。

**名無しさん＠お腹いっぱい。** · 2011/11/12(土) 22:31:16.29

あの攻撃的な論調にもかかわらず当事者と言っていい人からコメントもらえたのに何が不満なんだか
かまってちゃんだな

**名無しさん＠お腹いっぱい。** · 2011/11/12(土) 23:37:04.96

上から目線で思わせぶりにうそぶいたところで
痛いお馬鹿さんにしか見えないって気付いてほしいｗ

**名無しさん＠お腹いっぱい。** · 2011/11/13(日) 00:47:19.44

いつも核心を書かないよね。
話長引くだけなのに。

**名無しさん＠お腹いっぱい。** · 2011/11/13(日) 01:30:15.96

ていうか、早く「論文」とやらを書けよｗ

**名無しさん＠お腹いっぱい。** · 2011/11/13(日) 19:40:55.20

仕方ないよ、VISA.co.jpを救ったという実績だけで
天狗になってんだもん。
次の実績は、キャッシュポイズニングって事。

ちなみに、
http://www.aguse.jp/
を使うと、whoisだとかマルウエアだとかチェックしてくれるよ

**名無しさん＠お腹いっぱい。** · 2011/11/14(月) 11:13:18.09

DNSSECやDNSCurveが守るのはDNS仕様の穴による
キャッシュポイズニングだけじゃないんだけど、
disってる人はそこのところわかってるのかしら。

DNSSECやDNSCurveは、DNSの穴だけでなく、その穴に頼らず
通信経路上でパケット書き換えするような攻撃に対しても防御する。
telnetやHTTPというプロトコル自体に穴があるわけじゃないけど、
経路上での盗聴を防ぐためにsshやHTTPSを使うのと同じ発想。
port randomizationはあくまでDNSの穴をふさぐためだけのもので、
経路上でなされる攻撃に対してはまったく効果がない。

DNSSECをdisるのは別に好きにすればいいと思うけど、
kaminsky attackはそれほど脅威じゃない、port randomizationだけやってれば
十分だからDNSSECはいらない、って方向から攻めるつもりなら
見当違いだからやめた方がいいよ。同時にDNSCurveもdisることになるし。

経路乗っ取りなんてありえないからdnssecもsshもsslもいらない、
というつもりなら止めないけど。

**tss** · 2011/11/14(月) 12:46:13.04

誰だかわかりますよ ;-)
DNSSEC の問題は DNSSEC自体にあるのではなくて、その推進によってそれ以外の対策が疎かにされていることにあります。
port固定もまだまだ多いし、オープンリゾルバもなかなか減らない。
そのあたりの読解よろしく。

**tss** · 2011/11/14(月) 12:52:13.84

そうそう。Kaminskyの説明は間違いですが毒入れは簡単です。誤解なきよう。

**名無しさん＠お腹いっぱい。** · 2011/11/14(月) 14:16:24.24

DNSSECが無かったからといってそれ以外の対策が今よりも
進んでたかというとそうじゃないだろ。むしろDNSSECを
採用してるオペレータのほうが比較的進んでるでしょ（あくまで「比較的」だが）。
これに関してはdisる対象はDNSSECじゃないと思う。

**名無しさん＠お腹いっぱい。** · 2011/11/14(月) 15:47:42.60

>>774
で、相変わらずまともな周知活動やるつもりないんですか？

**名無しさん＠お腹いっぱい。** · 2011/11/14(月) 17:23:44.46

もしも、てぃんぽにＩＰがあったら
毒入れこわいです；；

**名無しさん＠お腹いっぱい。** · 2011/11/14(月) 19:44:13.69

お前らなんだかんだでtss先生にやさしいじゃねぇか

**名無しさん＠お腹いっぱい。** · 2011/11/14(月) 21:36:12.30

べ、べつにあんたのために書いてるわけじゃないんだからね

**名無しさん＠お腹いっぱい。** · 2011/11/15(火) 16:32:52.71

アレな人はコントロールできる範囲でコントロールしておかないと余計に面倒くさいからだろ。

**名無しさん＠お腹いっぱい。** · 2011/11/15(火) 20:49:46.13

コントロールできると思ってるのかい？

**名無しさん＠お腹いっぱい。** · 2011/11/15(火) 22:17:00.79

嘘大げさ紛らわしいデマ発言は片っ端から否定していけばよかろう

**名無しさん＠お腹いっぱい。** · 2011/11/16(水) 01:06:51.89

>>782
コントロールできる範囲でならコントロールできるだろう。