トップページ⇒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/
0745名無しさん＠お腹いっぱい。2011/10/30(日) 18:36:26.37
なんで最近「浸透言うな」ネタがはやってるん？
タイムラグが起きる事を端的に表した良い言葉だと思うんだけど
TTL調整は当たり前だろうに
0746名無しさん＠お腹いっぱい。2011/10/30(日) 19:36:38.26
言葉狩り、とレッテル貼るだけ、ってのも言葉狩り
同じ穴の貉なんだけどなw
0747名無しさん＠お腹いっぱい。2011/10/30(日) 19:50:24.92
>>745
今騒がれてる「浸透」問題はTTLはほとんど関係ない　言葉の問題でもない
DNS権威サーバの構成や設定や変更手順がまずくて、権威サーバでDNSレコードを変更しても、
TTLが経過しても、世間のキャッシュサーバのデータが新レコードに
なかなか更新されない現象に関する問題

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

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

どいつもこいつもオ㍗ルな……
0748名無しさん＠お腹いっぱい。2011/10/30(日) 20:41:03.02
「浸透」という言葉を当てるなということ？
Virtualが仮想ではないということのように。
0749名無しさん＠お腹いっぱい。2011/10/30(日) 21:16:27.04
>>748
DNSの仕組みがわかっていれば「浸透」と表現することはない。
0750名無しさん＠お腹いっぱい。2011/10/30(日) 21:47:21.11
クライアントが問うまでレコードは一切流れないもんね。
0751名無しさん＠お腹いっぱい。2011/10/30(日) 22:02:19.49
わかってる人がどう言ってるのか教えてください
ボクもわかってるフリをしたいです
0752名無しさん＠お腹いっぱい。2011/10/30(日) 22:23:59.74
地球に天体が衝突しそう！

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


こうですかわかりません＞＜
0753名無しさん＠お腹いっぱい。2011/10/31(月) 01:32:50.05
それクスッともこないんだけど
0754名無しさん＠お腹いっぱい。2011/11/03(木) 23:12:21.80
教授達も、PacketiX VPNでネットワーク作るなり
ＤＮＳの経験を積ませればいいのに･･･
すでに日本にはマシな技術者がいないという事か･･･
0755名無しさん＠お腹いっぱい。2011/11/04(金) 00:16:02.07
なぜSoftEther
0756名無しさん＠お腹いっぱい。2011/11/04(金) 00:26:07.59
同じリスト＆キャッシュポイズニング的な意味で
「qmail.jp」「e-ontap.com」は要注意ですね
0757名無しさん＠お腹いっぱい。2011/11/04(金) 01:14:37.80
大学准教が多数のDNSサーバを攻撃中！（ソースはニュー速）
ってtwitterにデマ流せばいいのか
0758名無しさん＠お腹いっぱい。2011/11/04(金) 01:36:33.07
次のテンプレで閲覧注意が丁度よいかと
さすがに攻撃はせんでしょ
0759名無しさん＠お腹いっぱい。2011/11/04(金) 01:38:11.93
くだらねーことしてる暇があったらRFC1912をupdateする活動してくれよ先生
0760名無しさん＠お腹いっぱい。2011/11/04(金) 09:54:56.03
>>759
RFC1912って何かマズいの？
0761名無しさん＠お腹いっぱい。2011/11/04(金) 10:36:46.56
>>758
危険なＤＮＳサーバとやらで見に行った後
何されるかわからんけどなｗ
0762名無しさん＠お腹いっぱい。2011/11/04(金) 22:00:47.52
>>760
RFC1912の内容がさすがに古いんじゃねってこと
Informational RFCのupdateってあるのかどうかしらんけど、
オープンリゾルバやソースポート固定や「浸透」の問題を明示的に
書いたRFCも無いと思うので、そういうのを盛り込んで更新するのがいいと思う
日本国内だけの問題じゃないしね
0763名無しさん＠お腹いっぱい。2011/11/04(金) 22:07:41.49
open resolverはRFC5358があるか
0764名無しさん＠お腹いっぱい。2011/11/07(月) 15:42:13.05
DNSが「浸透」するものならinfiltrationとかpenetrationとか言われてるんだろうけど、
実際にはpropagationと言われてるからそれは伝播だろうということだな？
0765名無しさん＠お腹いっぱい。2011/11/07(月) 19:25:15.63
tssさんの調査かと思った
named[1822]: client 74.115.28.50#10053: query (cache) 'dankaminsky.com/A/IN' denied
0766tss2011/11/08(火) 09:05:39.00
propagation いうな
07677262011/11/12(土) 21:17:03.17
>>729
盛り上がって？ますな

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

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

ちなみに、DNSSECディスりたくて仕方ないようだけど、誰がプロモしようが
今のままのDNSSECは運用が難しすぎてディスるまでもなく
普及しないから無視していいと思います。まぁ、スペック表に○を増やしたい
人もいるのは見逃してやれよ。DNSなんて差別化できなくて久しくて、
リストラの危機に常にさらされてるわけだから。
0768名無しさん＠お腹いっぱい。2011/11/12(土) 22:31:16.29
あの攻撃的な論調にもかかわらず当事者と言っていい人からコメントもらえたのに何が不満なんだか
かまってちゃんだな

0769名無しさん＠お腹いっぱい。2011/11/12(土) 23:37:04.96
上から目線で思わせぶりにうそぶいたところで
痛いお馬鹿さんにしか見えないって気付いてほしいｗ
0770名無しさん＠お腹いっぱい。2011/11/13(日) 00:47:19.44
いつも核心を書かないよね。
話長引くだけなのに。
0771名無しさん＠お腹いっぱい。2011/11/13(日) 01:30:15.96
ていうか、早く「論文」とやらを書けよｗ
0772名無しさん＠お腹いっぱい。2011/11/13(日) 19:40:55.20
仕方ないよ、VISA.co.jpを救ったという実績だけで
天狗になってんだもん。
次の実績は、キャッシュポイズニングって事。

ちなみに、
http://www.aguse.jp/
を使うと、whoisだとかマルウエアだとかチェックしてくれるよ
0773名無しさん＠お腹いっぱい。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もいらない、
というつもりなら止めないけど。
0774tss2011/11/14(月) 12:46:13.04
誰だかわかりますよ ;-)
DNSSEC の問題は DNSSEC自体にあるのではなくて、その推進によってそれ以外の対策が疎かにされていることにあります。
port固定もまだまだ多いし、オープンリゾルバもなかなか減らない。
そのあたりの読解よろしく。
0775tss2011/11/14(月) 12:52:13.84
そうそう。Kaminskyの説明は間違いですが毒入れは簡単です。誤解なきよう。
0776名無しさん＠お腹いっぱい。2011/11/14(月) 14:16:24.24
DNSSECが無かったからといってそれ以外の対策が今よりも
進んでたかというとそうじゃないだろ。むしろDNSSECを
採用してるオペレータのほうが比較的進んでるでしょ（あくまで「比較的」だが）。
これに関してはdisる対象はDNSSECじゃないと思う。
0777名無しさん＠お腹いっぱい。2011/11/14(月) 15:47:42.60
>>774
で、相変わらずまともな周知活動やるつもりないんですか？
0778名無しさん＠お腹いっぱい。2011/11/14(月) 17:23:44.46
もしも、てぃんぽにＩＰがあったら
毒入れこわいです；；
0779名無しさん＠お腹いっぱい。2011/11/14(月) 19:44:13.69
お前らなんだかんだでtss先生にやさしいじゃねぇか
0780名無しさん＠お腹いっぱい。2011/11/14(月) 21:36:12.30
べ、べつにあんたのために書いてるわけじゃないんだからね
0781名無しさん＠お腹いっぱい。2011/11/15(火) 16:32:52.71
アレな人はコントロールできる範囲でコントロールしておかないと余計に面倒くさいからだろ。
0782名無しさん＠お腹いっぱい。2011/11/15(火) 20:49:46.13
コントロールできると思ってるのかい？
0783名無しさん＠お腹いっぱい。2011/11/15(火) 22:17:00.79
嘘大げさ紛らわしいデマ発言は片っ端から否定していけばよかろう

0784名無しさん＠お腹いっぱい。2011/11/16(水) 01:06:51.89
>>782
コントロールできる範囲でならコントロールできるだろう。
0785名無しさん＠お腹いっぱい。2011/11/16(水) 13:14:44.18
同じ上から目線　ってのは
qmail.jpも同じなんだけどねｗ
0786名無しさん＠お腹いっぱい。2011/11/16(水) 20:17:33.09
おまえらアップしとけよ
0787名無しさん＠お腹いっぱい。2011/11/16(水) 20:18:57.10
これこれ
https://www.isc.org/software/bind/advisories/cve-2011-tbd
0788名無しさん＠お腹いっぱい。2011/11/16(水) 21:08:07.93
メール使えば外からでも撃ち落されるかもってことでFA?
https://lists.isc.org/pipermail/bind-users/2011-November/thread.html
0789名無しさん＠お腹いっぱい。2011/11/16(水) 21:47:27.26
パッチまだかな
0790名無しさん＠お腹いっぱい。2011/11/17(木) 11:33:13.04
赤帽
https://bugzilla.redhat.com/show_bug.cgi?id=754398
0791名無しさん＠お腹いっぱい。2011/11/17(木) 12:45:27.24
パッチは出たけど、とりあえず落ちないようにしただけで穴はふさがれていない。
もしかしたら、素直に落ちてくれた方がまだマシだったという可能性もありうるので要注意。
0792名無しさん＠お腹いっぱい。2011/11/17(木) 13:23:58.36
原因わかってないんだよね
パッチって言えるのかあれ
0793名無しさん＠お腹いっぱい。2011/11/17(木) 13:26:07.54
パッチとは言えるだろ。
0794名無しさん＠お腹いっぱい。2011/11/17(木) 13:44:23.70
CHANGESのとおりだろ？
--- 9.8.1-P1 released ---
3218. [security]
Cache lookup could return RRSIG data associated
with nonexistent records, leading to an assertion
failure. [RT #26590]

0795名無しさん＠お腹いっぱい。2011/11/18(金) 05:55:31.05
パチパチ
https://rhn.redhat.com/errata/RHSA-2011-1458.html
0796名無しさん＠お腹いっぱい。2011/11/18(金) 07:04:42.30
商用機に当てる前の検証やってるんだけど
終わった頃に新パッチが出そうで虚しい
0797名無しさん＠お腹いっぱい。2011/11/18(金) 09:53:59.23
次の仕事加が出来てよかったじゃん
N関連で
0798名無しさん＠お腹いっぱい。2011/11/18(金) 11:20:58.12
うちのbind-9.2.4ちゃんは元気だよ？
0799名無しさん＠お腹いっぱい。2011/11/20(日) 01:08:08.05
>>798
よかったな、カツ丼食うか？
0800名無しさん＠お腹いっぱい。2011/11/20(日) 17:57:05.72
BIND9はバグが多くてダメだな
うちのBIND8.4ちゃんは4年アップしないで済んでるぜ
0801名無しさん＠お腹いっぱい。2011/11/20(日) 18:04:14.75
8のバグは周知されないだけ。
0802名無しさん＠お腹いっぱい。2011/11/20(日) 18:13:33.19
マジレスされてもな…
でもBIND8や初期のBIND9のままって所けっこうあるよね
脆弱性発表されないから大丈夫と誤解してる奴もいるんじゃないか
0803名無しさん＠お腹いっぱい。2011/11/20(日) 18:30:43.58
客先で古いSolarisでBIND4動いてるよ
保守範囲じゃないから知らないふりしてる
0804名無しさん＠お腹いっぱい。2011/11/21(月) 07:41:32.42
bindで
zone "in-addr.arpa" {
type slave;
file "in-addr.arpa.slave";
masters {
192.5.5.241; // F.ROOT-SERVERS.NET.
};
notify no;
};
で動かしていたのですが

named[???]: zone in-addr.arpa/IN: expired
になっています

やめた理由等が書いてあるページ等
これに関する情報ありますでしょうか？


0805名無しさん＠お腹いっぱい。2011/11/21(月) 08:25:43.88
そんな設定どこでおぼえたんだ。
0806名無しさん＠お腹いっぱい。2011/11/21(月) 10:15:30.58
理由を知ってどうしたいのか知りたい。
0807名無しさん＠お腹いっぱい。2011/11/21(月) 14:14:30.74
>>806
そりゃ晒し上げにゃ、元ネタを聞くのが一番ｗ
0808名無しさん＠お腹いっぱい。2011/11/21(月) 15:15:34.22
>>804
そんな設定をしたくなった動機の方が気になるわ
0809名無しさん＠お腹いっぱい。2011/11/21(月) 17:00:48.15
root name server がaxfr受け付けない根拠は RFC 2870と思われる。

>>804 の謎設定の由来はなんとなく分からんでもないが、
今じゃ何の利益もなく害ばかりなのでやめとけ
一応こんな情報はあるけどね
http://dns.icann.org/services/axfr/
0810名無しさん＠お腹いっぱい。2011/11/21(月) 17:02:10.96
まぁ受け付ける必要ないよね。
0811名無しさん＠お腹いっぱい。2011/11/21(月) 17:07:10.31
どっかのサンプル設定ファイルに埋まってんのかな。
0812名無しさん＠お腹いっぱい。2011/11/21(月) 17:48:21.31
FreeBSDの設定サンプルで発見
http://svnweb.freebsd.org/base/head/etc/namedb/named.conf?revision=170914&view=markup

最新だとさすがにコメントアウトされてるが。。。。。
0813名無しさん＠お腹いっぱい。2011/11/21(月) 18:03:25.07
804です

>>809
ありがとうございます。

設定はFreeBSD 8のサンプルにありました

試験的に1台おこなっていたのですが、いつのまにかエラーを吐いていたので
気になりました。
0814名無しさん＠お腹いっぱい。2011/11/21(月) 22:14:33.38
「気になりました。」ｗ
0815tss2011/11/22(火) 22:50:21.43
root server axfr できますよ～
0816名無しさん＠お腹いっぱい。2011/11/23(水) 00:15:11.42
root serverでも . の AXFRはできるのはあるね

ルートサーバが in-addr.arpa ゾーンを持たなくなったのが
>>804 ができなくなった理由じゃないの？
0817名無しさん＠お腹いっぱい。2011/12/05(月) 12:03:59.95
浸透でも伝播でもなく単に正規の手順を踏んでないことによるデッドロックなだけなのね。
0818名無しさん＠お腹いっぱい。2011/12/05(月) 12:07:37.84
スレーブなんかやめて ttp://www.internic.net/zones/ あたりにある物使って
. のマスターになっちゃえよｗ
0819名無しさん＠お腹いっぱい。2011/12/06(火) 21:36:33.13
JPRSは minimal-responses yes というworkaroundを省略するのは何でだぜ？
https://deepthought.isc.org/article/AA-00549
0820名無しさん＠お腹いっぱい。2011/12/06(火) 22:09:46.44
>>818
究極の浸透問題状態だろそれwww
0821名無しさん＠お腹いっぱい。2011/12/07(水) 10:25:52.42
>>819
権威サーバと混在してる場合は軽減できるけど完全な解決策にはならないからでは。
キャッシュDNSでもlocalhostやAS112ゾーンは持つのがふつーだから、
純粋にキャッシュ専用で動いてるところなんてまずないと思う。
0822名無しさん＠お腹いっぱい。2011/12/07(水) 18:22:16.28
>>819
更新されたね。
0823名無しさん＠お腹いっぱい。2011/12/19(月) 20:23:43.55
JPRSはさっさとDNSSECで使うDSレコードを
外部から登録するためのプロトコルを実装して公開して欲しい。

DSレコードの登録が手動とか、面倒くさくてDNSSECを導入できない。
0824名無しさん＠お腹いっぱい。2011/12/19(月) 20:55:14.04
1年～数年に1回やれば済むような作業をめんどくさいというのは
「自分にはできない」のを「自分がやらない」理由としてごまかしてるだけ。
SSLの証明書更新とかに比べればずっと手間が少ないのに。

NSの登録だって昔からJPRSに直接はできず、指定事業者経由でしかできないんだから、
DSでそれをできるようにするとはとても思えん。
0825名無しさん＠お腹いっぱい。2011/12/19(月) 21:05:12.34
ネームサーバーのセキュリティパッチは必要な時に都度当てられるけど、
DSレコードは任意のタイミングで更新するわけにはいかないから自動化したいんだよ。

JPDirectのサービスとして始めればいいよ。

他の事業者は自分で実装すればいいだろ。IIJは出来るようにしたみたいだし。
http://www.iij.ad.jp/company/development/tech/activities/dnssec/index.html
0826名無しさん＠お腹いっぱい。2011/12/20(火) 18:13:16.11
>>824
JPRSが他TLDの販売をしようとして
コテンパンに叩かれて、「*.dns.jp」の管理一本に
なったはず
0827名無しさん＠お腹いっぱい。2011/12/20(火) 19:27:52.85
>DSレコードは任意のタイミングで更新するわけにはいかないから自動化したいんだよ。

？？？ いつでも好きなときにできるけど？
DNSSECの仕様の話ではなく、客の都合に合わせてやらなきゃいかんとかいう話なら知らないけど。

外部からDS登録するAPIが存在しないわけではなく、指定事業者（レジストラ）には公開されてると思うよ。
sannetはjpがdnssec対応した初日にレンサバサービスで契約されている全ドメインの
DSを登録したらしいけど、ひとつずつ手でやったとはとても思えない。sannetは指定事業者なので
それ用のAPIを使ったと考えるのが妥当。

ただ、そのAPIを一般に公開できるかというと、ドメインの取得に際して
jprsから認証用のID/PWなどがドメイン所有者に渡されるわけではないので、
認証のしようがない。甘い認証でDSを更新させたらDNSSECの意味がない。
そのへんの認証情報を持ってる指定事業者を経由させるのもしかたないかと。

jpに限らず他のTLDでもレジストラを経由せずにDSを登録できないところばっかり。
自動化できるAPIを作れと言うなら、相手はjprsではなく自分がドメイン管理に使ってる事業者かと。

ちなみに、DS登録用のプロトコルとしてはRFC5910というのがあって、opendnssecはこれに対応してたはず。

>>826
jprsは最近jpだけでなくgTLDも売りはじめたよ。
0828名無しさん＠お腹いっぱい。2011/12/20(火) 20:30:39.50
>>827
DNSはセキュリティパッチと、正引き・逆引き設定の変更が必要な時以外は、
一度設定したら手間を掛けなくて良かったんだから、
DNSSECを導入した場合でもキーの更新に新たなコスト(時間と金)は掛けたくない。

特にDSレコードの更新前後にKSKのTTLを気にするとかを手動でやりたくない。
DSレコードの更新、KSKの更新、ZSKの更新などを全部自動化したい。

うちの指定事業者はJPDirect(=JPRS)なの。
ドメインにまつわる設定を操作するためのIDとパスワードは、
既にもらっているので、あとはAPIがあれば良いだけなんだけど、
それをJPDirect(=JPRS)に用意して欲しいって言ってるの。

今現在提供されているJPDirectのwebインターフェースを使うことで、
DSレコードの更新は可能なんだけど、これにアクセスするソフトを書くとしても、
JPDirectが提供しているWebインターフェースなんて、いつ仕様が変わるか分からないから、
長期間に渡って動作する見込みが無い物は使えない。

だからJPDirect(=JPRS)には、ちゃんと仕様の決まった
DSレコードの更新方法を提供して欲しい。
既にRFCに習った実装があるなら、提供されるのがそれでも構わない。
0829名無しさん＠お腹いっぱい。2011/12/21(水) 01:22:18.55
unboundもやられたか
ヤツはDNS四天王のうちでも（ｒｙ
0830名無しさん＠お腹いっぱい。2011/12/21(水) 01:24:18.67
つ ttp://www.unbound.net/downloads/CVE-2011-4528.txt
0831名無しさん＠お腹いっぱい。2011/12/21(水) 10:28:09.75
jpdirectはjprsが自前でやってる指定事業者にすぎないから。
jprsへの要望とjpdirectへの要望をごっちゃにしちゃいかん。

jpdirectって新規受け付けを終了しちゃってるが、
既存向けに続けてるのもそのうちやめそうな気がしてならない。
jpdirectそのものをやめたがってる感がアリアリ。
よその事業者にドメインを移管した方がいいような。
0832名無しさん＠お腹いっぱい。2011/12/21(水) 18:34:12.07
BIND、unbound以外で良い感じのキャッシュサーバって何かある？
PowerDNS recursor試してみようかな
0833名無しさん＠お腹いっぱい。2011/12/21(水) 21:04:25.74
良い感じってのも色々だしなぁ
DJBのも調査してみたら？
0834名無しさん＠お腹いっぱい。2011/12/21(水) 22:40:07.45
セキュリティ第一ならdjbdns一択だな
djbwareは嫌いだがこれは認めざるを得ない
もう機能拡張は望めないけど、ほとんどの用途では必要十分だし
不安はIPv6トランスポート対応くらいか
08358342011/12/21(水) 22:45:30.23
> 不安はIPv6トランスポート対応くらいか

サードバーティ製のパッチはあるけどね……
0836名無しさん＠お腹いっぱい。2011/12/21(水) 23:01:43.81
現状JPドメインでIPv6 glue, DNSSEC(DSレコード取次)対応してるレジストラとしては一番安いから無くなると困るなJPDirect。
適当に安いレジストラがDSレコード取次対応してくれれば他に移るんだが。
0837名無しさん＠お腹いっぱい。2011/12/21(水) 23:25:00.06
GMOの熊谷が余計な横槍入れてきたから、しぶしぶ対応しただけの話でしょ。
0838名無しさん＠お腹いっぱい。2011/12/21(水) 23:39:44.47
>>834
djbdnsではEDNS0に対応していないから512byte問題を回避できない。
いわゆるdjbwareは既に過去のプロダクトであって、いま動いているものを無理に止めろとまでは言わないが、
新規に使うべきものではない。
0839名無しさん＠お腹いっぱい。2011/12/22(木) 00:07:46.10
EDNS0はMUSTじゃないでしょ
DNSのTCPトランスポートのサポートはMUSTになったけど
EDNS0がMUSTになる見込みはないと思う
0840名無しさん＠お腹いっぱい。2011/12/22(木) 01:49:34.61
TCPにフォールバックしないのはqmailかな（パッチはある）
今からdnscacheを新規で入れるのも気がひけるな
0841名無しさん＠お腹いっぱい。2011/12/24(土) 00:00:47.15
EDNS0はDNSSECのために作られたようなもんだからな
IPv6やDNSSECが必須にならなきゃdjbdnsでも生きていける、ような気がする
0842名無しさん＠お腹いっぱい。2011/12/26(月) 18:28:55.15
IPv6やDNSSECの情報をDNSで扱う場合、RFC3226でEDNS0への対応は必須とされている。
これはサーバだけでなく、クライアント側も対応せよ、となっている。
つまり、v6のアドレスを問い合わせるならEDNS0を必ず使え、ということ。
まだv6は必須な状況にはなってないけど、現実にばんばん問い合わせてるのに
対応していないdnscacheはよろしくない。

もっとも、RFC3226が言及しているのはv6といってもAAAAじゃなくてA6だし、
DNSSECといってもDS方式じゃなくて実用化されなかったRFC2535方式だけど。
# DOビットを立てるならEDNS0を有効にしろ、という意味に解釈するなら
# 現行のDS方式のDNSSECについてもRFC3226は有効。
0843名無しさん＠お腹いっぱい。2011/12/28(水) 00:01:04.52
DOビットと聞いてFW-1の余計な機能を思い出した。
0844名無しさん＠お腹いっぱい。2011/12/30(金) 17:44:11.27
djbdnsの利用を推奨するわけじゃないが……

>>842
A6なんてhistoricalになろうとしてるし、EDNS0のクエリを投げてくる
クライアント(スタブリゾルバ)なんて皆無。EDNS0非対応はその実装を
使わない理由にはならないと思う。
■ このスレッドは過去ログ倉庫に格納されています