トップページunix
1001コメント314KB

Name Server 総合スレ【DNS】

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。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/
0380名無しさん@お腹いっぱい。2010/05/12(水) 00:37:51
>>379

viewごとの細かい設定とかが必要ないんなら、
まずはview無しで単純に書いてみたら?
0381名無しさん@お腹いっぱい。2010/05/13(木) 18:59:03
BINDが入ってるローカル鯖で
[root@localhost named]# dig @127.0.0.1 0.168.0192.in-addr.arpa.SOA
を実行したところ、以下の結果が出ました。
これは逆引き設定がうまくいってると考えて良いのでしょうか?
NXDOMAINというのが気になるんですが
(ドメインを指定した正引きの場合、問題なのはわかるんですが)

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @127.0.0.1 0.168.192.in-addr.arpa.SOA +norec
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25808
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;0.168.192.in-addr.arpa.SOA. IN A
;; AUTHORITY SECTION:
. 9796 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2010051201 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu May 13 02:55:54 2010
;; MSG SIZE rcvd: 119
0382名無しさん@お腹いっぱい。2010/05/13(木) 20:26:36
>>381
in-addr.arpa. とSOAの間にスペースを
dig @127.0.0.1 0.168.192.in-addr.arpa. SOA
0383名無しさん@お腹いっぱい。2010/05/13(木) 20:43:56
>>382
うまくいきました! ありがとうございました
0384名無しさん@お腹いっぱい。2010/05/17(月) 07:56:17
動けばいい、っていうんじゃなくて、動作の理解をしなさいよ。
0385名無しさん@お腹いっぱい。2010/06/01(火) 04:35:23
unboundでGoogle Public DNS使おうと思って、

forward-zone:
name: "."
forward-addr: 8.8.8.8
forward-addr: 8.8.4.4

を設定したけれど、解決できないドメインがある

# drill example.com @127.0.0.1
だと解決できないが、
# drill example.com @8.8.8.8
とすると解決できる。

恐らくウチの環境(or設定)が悪いだけ、と思ってるけれど、
解決できるドメインもあるので原因が分からない・・
0386名無しさん@お腹いっぱい。2010/06/01(火) 11:01:16
>>385
そのドメインの設定が腐ってる可能性もあると思うよ。
0387名無しさん@お腹いっぱい。2010/06/01(火) 23:53:10
>>368みたいな腐った設定はゴマンとあるしな
stack*は相変わらずlameっぽ
0388名無しさん@お腹いっぱい。2010/06/02(水) 00:26:34
>>385
日本でGooglePublicDNS使うとAkamai他のCDN関係を全部日本以外に転送されてしまうから
ウェブブラウズなどが遅くなるだけでうれしいことはなにもないぞ。OpenDNSでも同様。

あれを日本から使ってうれしいのは「自組織以外からDNS参照をおこなったらどうみえるか」を
手軽に検証できることだけ。
0389名無しさん@お腹いっぱい。2010/06/02(水) 00:47:16
>>388
1月末に提案されたドラフトは01になったね。
ttp://tools.ietf.org/id/draft-vandergaast-edns-client-ip-01.txt

検証目的であればここも便利
ttp://www.dns-oarc.net/oarc/services/odvr
0390名無しさん@お腹いっぱい。2010/06/11(金) 00:51:08
BINDの動的なインターフェースなどのアドレスを一定時間毎に動的にListenする機能って
rootで動かしていないとうまく機能しないのかな?
0391名無しさん@お腹いっぱい。2010/06/11(金) 01:18:10
0.0.0.0:53にbindしていただくという方法での回避はできなかったから
やっぱりrootで動かすしかないかなぁ。
0392名無しさん@お腹いっぱい。2010/06/11(金) 03:05:30
>>390
リファレンスのinterface-intervalの項目に制約は書かれていないけど駄目?
DebianではPPPのup時にrndc reconfigで回避してる。
0393名無しさん@お腹いっぱい。2010/06/15(火) 03:17:52
>>392
ありがとうございます。
reconfigでもやっぱりpermission deniedという理由でbindさせてもらえてませんでした。
restartしてしまえばいいのかな?コストがアレですけど。
0394名無しさん@お腹いっぱい。2010/06/16(水) 20:49:00
この板のスーパーハカー様方に質問です。

hamusoku.com. IN NS ns1.domain.livedoor.com
IN NS ns1.domain.livedoor.com
IN CNAME blog-01.livedoor.jp

これってRFC違反だと思うのですがどうでしょう。
ちなみにWIN2008R2のDNSサーバだとエラーになって引けません。
最近のBINDではどうですか?

0395名無しさん@お腹いっぱい。2010/06/16(水) 21:07:18
>>394
これいかんね。
http://bonz.squares.net/~dais/misc/rfc1912j.html#cname
0396名無しさん@お腹いっぱい。2010/06/16(水) 21:20:58
おかしいね。
とりあえず bind 9.6.1-P1 と unbound 1.4.3 では引けちゃったけど、
エラーにするキャッシュ DNS があったとしても不思議ではない。

ただ、bind ならこういう腐ったゾーンはエラーにして読み込まなかったような。
……と思ったら、なんか nsd っぽいなぁ。
nsd って bind よりゾーンファイルのバリデーションが緩いんだよなぁ。
0397名無しさん@お腹いっぱい。2010/06/16(水) 22:14:21
394です。
ありがとうございます。
ライブドアにこんなん引けねーよと言ってみたのですが
「問題を認識できません」て返されました。
こういうお馬鹿さんはどうすればいいんでしょうね。
0398名無しさん@お腹いっぱい。2010/06/17(木) 00:28:12
相手にするおまえがおバカさんだ
日本はこういう国になっちまったんだ諦めろもう終わり
0399名無しさん@お腹いっぱい。2010/06/17(木) 09:40:04
DNSOPSあたりで話題に出せば誰か反応するかも。
0400名無しさん@お腹いっぱい。2010/06/17(木) 12:28:36
TwitterでLivedoorの技術系の中の人に直接つっこんでみるとか
0401名無しさん@お腹いっぱい。2010/06/18(金) 00:07:12
>>400

俺もそう思った。
サポートに言っても障害として検知していない状態で、類似のクレームも
他になければ取り合わなさそう。
0402名無しさん@お腹いっぱい。2010/06/18(金) 03:58:34
>>399
参加者あまり多くないんじゃない?
空気読まずにjanogとか(w

>>401
国税庁の時も全く返事が来なくて、忘れたころにこっそり直してたな。
0403名無しさん@お腹いっぱい。2010/06/18(金) 20:04:56
>>402
DNSOPSをsubscribeしているひとはJANOGもsubscribeしてるだろう


0404名無しさん@お腹いっぱい。2010/06/21(月) 08:14:22
JANOGに投げて空気変えてほしいな。
0405名無しさん@お腹いっぱい。2010/07/01(木) 12:35:08

るーと更新おめでとう!!
          .o゜*。o
         /⌒ヽ*゜*
   ∧_∧ /ヽ    )。*o  ッパ
    (・ω・)丿゛ ̄ ̄' ゜
.  ノ/  /
  ノ ̄ゝ
0406名無しさん@お腹いっぱい。2010/07/01(木) 21:37:27
windowsでもdjbdns使いたいのだが駄目かな
0407名無しさん@お腹いっぱい。2010/07/01(木) 23:38:26
>>406
変態
0408名無しさん@お腹いっぱい。2010/07/02(金) 02:23:48
>>406
変態だな……。
0409名無しさん@お腹いっぱい。2010/07/03(土) 00:47:26
>>406
DJ本人乙
0410名無しさん@お腹いっぱい。2010/07/03(土) 21:09:28
愛が感じられるような
0411名無しさん@お腹いっぱい。2010/07/16(金) 23:29:13
ルートサーバーがDNSSEC対応したらしいが、
お主らのキャッシュサーバーは対応やった?
0412名無しさん@お腹いっぱい。2010/07/17(土) 10:25:37
>>411
うちのはBIND9.6系でトラストアンカーの自動更新は未対応っぽいから
しばらく様子見かな。鍵はどのくらいの間隔で更新されるの?
0413名無しさん@お腹いっぱい。2010/07/17(土) 11:58:15
bindは9.7じゃないとsha-2が使えないから、9.6だとそっちが引っかかる。
0414名無しさん@お腹いっぱい。2010/07/17(土) 12:10:42
http://www.iepg.org/2009-11-ietf76/rootsign-ietf76-iepg.pdf
によりますと
KSKは2〜5年ごと
ZSKは年4回
だそうですが。
0415名無しさん@お腹いっぱい。2010/07/17(土) 18:17:22
>>413
そこは気になったけど、9.6.2rc1で9.7からバックポートされたので問題ないよね?
ttp://lists.isc.org/pipermail/bind-announce/2010-February/000621.html
0416名無しさん@お腹いっぱい。2010/07/17(土) 18:32:19
>>414
それなら導入しても大丈夫そうだな。
KSK変わるときはニュースになりそうですし。

ところで、現時点でルートゾーンは署名されたけど、
既にDNSSEC導入済みのTLDへの署名はまだだよね?

これは次のセレモニー以降でZSKの更新の際に行われるのかな。
スケジュールでてる?
0417anonymous2010/07/17(土) 21:49:33
いくつかのccTLDにDSが入っています。
0418名無しさん@お腹いっぱい。2010/07/17(土) 22:40:06
>>417
確かに8個ほど入ってた。.CATなんてあったんだ。
http://www.root-dnssec.org/faq/
dig . AXFR @xfr.lax.dns.icann.org

自ドメインが検証できるようになるまではまだ時間がかかりそうだ。
0419名無しさん@お腹いっぱい。2010/07/18(日) 00:05:24
設定方法・・・ってほどでもないけど。
"9.6 or higher"は誤りで"9.6.2 or higher"に訂正予定とのこと。
ttp://www.isc.org/community/blog/201007/using-root-dnssec-key-bind-9-resolvers

keyはコッチで確認すること。
ttps://data.iana.org/root-anchors/
0420名無しさん@お腹いっぱい。2010/08/12(木) 10:42:04
>>394
この件と同種?で okwave に質問してる椰子がいるが
「普通のことです。違反でもなんでもありません。」って回答くらってるぞ

どっちが正しいんだ?

http://okwave.jp/qa/q6101868.html
0421名無しさん@お腹いっぱい。2010/08/12(木) 10:48:17
okwave の回答が間違ってる。
その回答に対する質問主のフォローが正解。
0422名無しさん@お腹いっぱい。2010/08/12(木) 11:01:57
そうか

いやなに、俺が立ててる DNS サーバーでも
ライブドアのあれみたいな書き方やってるんだw
ホスト名なしのドメイン名を別ホストへcnameさせてる。

A レコード書くと、ホスト引っ越しのときに不便なんだが。。
今のところクレーム来てないが、バレる前に直しておいたほうがいいのか
0423名無しさん@お腹いっぱい。2010/08/12(木) 11:59:26
質問の仕方がまずいんだと思う。
「Aの別名にBを使っているけどいいの?」って読みとられてしまっているよね
0424名無しさん@お腹いっぱい。2010/10/14(木) 01:08:48
DNS障害でYahooのほとんどのサービスが落ちてたね
0425名無しさん@お腹いっぱい。2010/10/14(木) 01:44:18
具体的にはどーだったの?
hostやdigで単純に引くとaレコードが帰ってこなくて
明示的にaレコードを指定すると戻ってきたみたいだけど
0426名無しさん@お腹いっぱい。2010/10/14(木) 10:02:45
primary name server = yahoo.co.jp
responsible mail addr = postmaster.yahoo.co.jp
serial = 2010101401
refresh = 1800 (30 mins)
retry = 900 (15 mins)
expire = 86400 (1 day)
default TTL = 900 (15 mins)

丸1日は途中のDNSがキャッシュ値を返してくれるの?
0427名無しさん@お腹いっぱい。2010/10/15(金) 14:06:25
自分が参照してるキャッシュのタイミング次第だろ。

expire直前にヤフーが死ねばすぐにアウトになる。

なんか、負荷分散サーバの障害とかいうてるみたいだけど、
権威サーバをIPAnycast化とかしてたんかな?

それともYahooクラスだと権威サーバでもロードバランサ
入れないとダメポなくらい負荷高いのかね?
0428名無しさん@お腹いっぱい。2010/10/15(金) 18:27:53
普通はBindで困ることって特にないよな。
DNS運用業者やってたときは、10万ドメイン以上あったから色々考えることあったけども。
0429名無しさん@お腹いっぱい。2010/10/18(月) 11:37:39
「BIND」な。
0430名無しさん@お腹いっぱい。2010/10/25(月) 18:53:45
2008R2 な DNS 鯖だと
recruit.co.jp のドメイン情報が全く読めないんだが
SOA レコードすら引けない。
なんでだ!?

2003 な DNS 鯖で引くと大丈夫
04314302010/10/25(月) 18:59:20
>>394 と同じ理由?
とりあえず、2008R2 の DNS 鯖で ISP の DNS にフォワーダかけたらうまくいく。
0432名無しさん@お腹いっぱい。2010/10/25(月) 19:02:45
Windowsの話はよそでやったら。
0433名無しさん@お腹いっぱい。2010/10/25(月) 19:03:13
>>430
ポートが開いてないんだろ
0434名無しさん@お腹いっぱい。2010/10/25(月) 20:01:58
他は引けるからポートの問題じゃないよ
0435名無しさん@お腹いっぱい。2010/10/25(月) 20:24:37
recruit.co.jp が特定の環境下で名前解決できないという話は別の所でもでていたような…
janogだったかdnsopsだったか
0436名無しさん@お腹いっぱい。2010/10/26(火) 00:30:25
512バイト超えてるんだろう
0437名無しさん@お腹いっぱい。2010/10/26(火) 22:07:15
recruit.co.jpはこれと同じ原因だよ
ttp://www.vwnet.jp/Windows/WS08R2/EDNS0/EDNS0.htm
0438名無しさん@お腹いっぱい。2010/11/06(土) 03:43:18
BIND10使ってるひとどのくらいいますか?
0439名無しさん@お腹いっぱい。2010/11/08(月) 11:16:37
20人くらい。
0440名無しさん@お腹いっぱい。2010/11/26(金) 11:36:45
政府によるDNSポイゾニングっていよいよ本格的に始まったんじゃない?
検出した気がする
先日の法相更迭はサインを渋ったからだとみた
0441名無しさん2010/11/27(土) 15:55:54
DNSSEC対応どーすんべ。。。
0442名無しさん@お腹いっぱい。2010/11/27(土) 17:31:50
>>441
慌てる必要はないよ。必要になったらやればいい。
0443名無しさん@お腹いっぱい。2010/12/02(木) 00:57:02
眺めている段階
0444名無しさん@お腹いっぱい。2010/12/02(木) 16:15:10
BIND: cache incorrectly allows a ncache entry and a rrsig for the same type
Versions affected: 9.6.2 - 9.6.2-P2, 9.6-ESV - 9.6-ESV-R2, 9.7.0 - 9.7.2-P2
Severity: High
https://www.isc.org/software/bind/advisories/cve-2010-3613

BIND: Key algorithm rollover bug in bind9
Versions affected: 9.0.x to 9.7.2-P2, 9.4-ESV to 9.4-ESV-R3, 9.6-ESV to 9.6-ESV-R2
Severity: Low
https://www.isc.org/software/bind/advisories/cve-2010-3614

BIND: allow-query processed incorrectly
Versions affected: 9.7.2-P2
Severity: High
https://www.isc.org/software/bind/advisories/cve-2010-3615
0445名無しさん@お腹いっぱい。2010/12/02(木) 16:37:31
http://ya.maya.st/d/201012a.html#s20101201_1
CNAME の間違った使い方

>>394-397
0446名無しさん@お腹いっぱい。2010/12/02(木) 16:55:57
http://blog.livedoor.jp/techblog/archives/65340720.html
> ライブドアドメインではこれまでdjbdnsを使用していましたが、
> 今年の11月1日にNSDというソフトウェアにリニューアルしまして、
> 新機能と同時にこのCNAME問題に対応しました。

やっと対応したって事かな。
0447名無しさん@お腹いっぱい。2010/12/03(金) 01:23:19
localhost.livedoor.jp has address 127.0.0.1
localhost.livedoor.com has address 127.0.0.1

この設定はよろしくないらしいけど削除するとまずいことでもあるのかな。

http://www.securityfocus.com/archive/1/486606
0448名無しさん@お腹いっぱい。2010/12/03(金) 10:35:56
/etc/hosts に localhost がなかったり、
あっても hosts を参照せずいきなり DNS に聞く実装でも、
resolv.conf に search livedoor.jp と書いてあれば
localhost を問い合わせても 127.0.0.1 がちゃんと返ってくる。

……というメリットはあるけど、たいしたメリットでもないので
消してもいいと思う。
0449名無しさん@お腹いっぱい。2010/12/03(金) 10:59:18
デメリットを聞いてるんだが
0450名無しさん@お腹いっぱい。2010/12/03(金) 11:20:17
だからそういう環境で localhost の名前解決ができなくなるんだってば。

FQDN じゃなかったら勝手にドメイン名を補完してしまうものもあるので、
localhost. のゾーンを作っておけば済むという話じゃないんだな。
0451名無しさん@お腹いっぱい。2010/12/03(金) 19:53:34
searchオプションの恩恵うける場面てそんなに多いのかな?
外の人にとっては意味ないし、中の人にしたってプログラムがsearch依存で名前解決するのも気持ち悪いだろうし。
0452名無しさん@お腹いっぱい。2010/12/03(金) 20:19:29
>だからそういう環境で localhost の名前解決ができなくなるんだってば。

つまりそれ以外のデメリットは無いということですね。

それならば削除する必要はないですね。
0453名無しさん@お腹いっぱい。2010/12/03(金) 21:18:51
>>452>>447のリンク先を日本語で解説してくれる人を釣ろうとしてるの?
0454名無しさん@お腹いっぱい。2010/12/03(金) 21:22:34
なるほど!
0455名無しさん@お腹いっぱい。2010/12/03(金) 21:51:53
ローカルPCで個人用ブックマークの検索サーバを立てた人がいるとする。

Referer: http://your.private.pc/search?q=hoge

からこの検索サーバのURLを知った攻撃者は、
こりゃ脆弱そうなURLだわいと何らかの方法で

http://localhost.livedoor.jp/search?q=<;script>...</script>

を本人に踏まさせて、実際に脆弱でかつlivedoor利用者であれば
livedoor.jpのCookieの詐取に成功する。

CUPSのような広く知られたものがあれば後半だけでいい。

こんなとこ?
0456名無しさん@お腹いっぱい。2010/12/05(日) 13:02:44
あとはNXDOMAIN連発とか?
0457名無しさん@お腹いっぱい。2010/12/06(月) 00:59:34
こういうの一度書いちゃうとなかなか消せないんだよね。
副作用が怖くて。
0458名無しさん@お腹いっぱい。2010/12/06(月) 09:19:43
なくなって困るのは中の人くらいじゃないの?
中からの問い合わせからだけ名前解決するんじゃだめなん?
0459名無しさん@お腹いっぱい。2010/12/07(火) 02:47:47
AmazonのDNS これいいんじゃない?
http://aws.amazon.com/route53/
http://aws.typepad.com/aws_japan/2010/12/amazon-route-53-the-aws-domain-name-service.html
0460名無しさん@お腹いっぱい。2010/12/07(火) 03:47:54
Wikileaksをホスティングしていることでもおなじみの信頼と実績だな
0461名無しさん@お腹いっぱい。2010/12/07(火) 08:07:03
アタックされたから追放したんじゃなかったのか
0462名無しさん@お腹いっぱい。2010/12/10(金) 00:21:00
>>459
まだこんな馬鹿がいるのか
0463名無しさん@お腹いっぱい。2010/12/10(金) 21:27:40
>>459
-DDoSを喰らったときの課金のありよう
-名前参照が終わるまで多段*4の参照が発生する
等を考えると若干首を傾げる。
Amazonにしては詰めの甘さを感じずにいられない。

Amazonがわのメンテナンスの都合でネームサーバのIPアドレスを
任意につけかえられるように設計するとこうなるのはわかるけれど。
0464名無しさん@お腹いっぱい。2011/01/07(金) 02:19:48
2010年はBIND9の脆弱性が多くて嫌になった
でもUnboundとかnsdに移行する勇気がないヘタレ
0465名無しさん@お腹いっぱい。2011/01/07(金) 10:07:11
数としてはたしかに多かったけど、dnssec を有効にしてなければ
放置しても問題ないものがほとんどだった気が。
dnssec はまだ本格的に使われてないからコードが枯れてないんだよね。
とはいえ、nsd/unbound は問題を起こしてないからそれを言い訳にはできないけど。
0466名無しさん@お腹いっぱい。2011/01/07(金) 10:11:13
見つかってないだけかも。
0467名無しさん@お腹いっぱい。2011/01/07(金) 16:09:39
Unboundはキャッシュとして使う限りはBIND9と遜色ない
機能はあると思う。DNSSEC validatorとしては最新の仕様に
追従してるし、ローカルデータもフォワーディングゾーンも設定できる。
Unboundに無い機能ってviewくらい?
0468名無しさん@お腹いっぱい。2011/01/07(金) 21:21:11
>>467
Unboundはラウンドロビンを無視してTTLが切れるまで常に同じアドレスを返す
というちょっと切ない仕様があったけどアレはその後どうなったのかな
0469名無しさん@お腹いっぱい。2011/01/07(金) 22:03:15
最新の1.4.7でもラウンドロビンしないよ
権威サーバから教えてもらった順番のまま答える

> dig +short @localhost www.l.google.com
66.249.89.104
66.249.89.99
> dig +short @localhost www.l.google.com
66.249.89.104
66.249.89.99
> dig +short @localhost www.l.google.com
66.249.89.104
66.249.89.99
> dig +short @localhost www.l.google.com
66.249.89.104
66.249.89.99
0470名無しさん@お腹いっぱい。2011/01/07(金) 22:17:59
権威サーバから得たデータは変にいじらずにそのまま
クライアントに返すべきだ、DNSの仕様にもラウンドロビンなんて
定義されてない、というのがUnbound側としての立場だったはず。

とはいえ、ラウンドロビンは必要な機能なんだろうなぁ
Windows Vista は複数Aレコードを得ると
RFC 3484 Rule 9 にしたがって特定のIPを選択
するのでラウンドロビンが効かないんだけど、
Win7 はラウンドロビンが効くように変更されたりしてるし
0471名無しさん@お腹いっぱい。2011/01/07(金) 22:21:23
UNIXの getaddrinfo()もラウンドロビンが効くように変更してください!
0472名無しさん@お腹いっぱい。2011/01/14(金) 01:17:03
BSDやglibc派生のスマフォンは
DNSラウンドロビン的にどう動くんだろ?
0473anonymous2011/01/18(火) 23:57:00
いよいよjpドメインでもDNSSEC使えるようになりましたが、
おまえらDNSSEC使いますか?
0474名無しさん@お腹いっぱい。2011/01/19(水) 18:03:47
いやべつに
0475名無しさん@お腹いっぱい。2011/01/19(水) 19:35:29
そのうち対応しないととは思っているが検証が面倒くさい
今のところキャッシュDNS鯖の負荷が無駄にあがってるだけだな
0476anonymous2011/01/19(水) 19:56:58
DNSSECは効果の割に苦労が大きすぎるから普及は難しいんじゃないか
キャッシュはともかく、権威サーバの運用がとっても面倒だからなー

だいたいDNSSECなしのDNSだってちゃんと運用できてねーし
DNSSECがまともに運用できるとはおもえない
0477名無しさん@お腹いっぱい。2011/01/19(水) 20:15:30
なんか IA64(itanium) の大風呂敷を広げたけど受け入れられず、
中庸な AMD64 が受け入れられるような感じ。

だれか DNSSEC よりもうちょっと手軽な仕組みを考えないかな

今思いついたアイデア:

署名の連鎖を考えず、
1.ドメイン(例:example.jp)の管理者は、自分の権威サーバに各種レコードと一緒に、証明書を意味するレコード(Xとする)も登録する
2.ドメイン管理者は、ベリサインから証明書を取得したとする。
3.リゾルバは、example.jp ゾーンの問い合わせをしたときに、ベリサインにも証明書の鍵? みたいなの(Yとする)を取得する。
4.XとYをつじつまが合えば、ドメイン example.jp はクラックされていないと判断する。

SSL みたいにすれば、署名の連鎖とか考えなくてすむんだけどどうでしょう。
0478anonymous2011/01/19(水) 20:35:41
とりあえずはTXIDを128ビットとかに
増やすだけでよかったんじゃね
source port randomizationや0x20のやってることの本質は
それだし
0479名無しさん@お腹いっぱい。2011/01/19(水) 20:54:39
>>477
それをやると証明書屋さんばっかり儲かっちゃうのよね。
SSL って netscape の独自規格が元になってるので、
政治的な話とは無関係に仕様が決まっちゃったけど、
インターネットのガバナンスってそういう特定の誰かに
集中/依存する仕組みを嫌うんだよね。

そうはいってもすべてを分散管理できる仕組みなんて作れないので、
IANA とか ICANN とかの組織にそういうのまかせるようにしてあるんだけど、
それでもなお不満がある人も多いわけで。
これが営利の私企業だったらどうなっていたことか、と。
SSL 証明書ってインターネットにおいては営利企業が牛耳ってる数少ない例外なんですよ。
■ このスレッドは過去ログ倉庫に格納されています