トップページ⇒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/
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非対応はその実装を
使わない理由にはならないと思う。
0845名無しさん＠お腹いっぱい。2012/02/18(土) 21:21:06.35
Ghost Domain Names…
cron で rndc flush で Ghost Busters できるん？
0846名無しさん2012/02/18(土) 22:39:56.52
それでいいはず。
ついでに浸透いうな対策にもなる。
0847名無しさん＠お腹いっぱい。2012/02/18(土) 22:42:48.70
一番効果的かつ正しいワークアラウンドだけど、
ISCやJPRSの人がそれを勧めるわけにいかないだろうね。
0848名無しさん＠お腹いっぱい。2012/02/25(土) 14:01:18.59
>>847
JPRSが「キャッシュDNSサーバーにおいて定期的なキャッシュデータ
のクリアを実施することにより、危険性を低減できます。」
って言ってるぞ
0849名無しさん＠お腹いっぱい。2012/03/08(木) 12:06:58.70
>>848
それをやる日本ISPが存在するかどうかだがなｗ
0850名無しさん＠お腹いっぱい。2012/03/08(木) 12:27:02.31
キャッシュは立ち上がりが一番性能低くなるからきついよな。

0851名無しさん＠お腹いっぱい。2012/03/09(金) 04:04:08.13
1日1回、早朝時間帯にクリアなら問題ないかなぁ
むしろ同じ時間に複数のISPで一斉にクリアされるとTLDな人たちが困るかも？
0852名無しさん＠お腹いっぱい。2012/03/09(金) 09:05:03.49
なぜ1日1回？

最低1回は権威を委任されなくちゃ成立しない攻撃方法だから、1〜数ヶ月は運用されるでしょ。
1ヶ月に1回で十分だと思うけど。
0853名無しさん＠お腹いっぱい。2012/03/09(金) 10:23:01.00
大丈夫、bindの穴で定期的に再起動してるから。
0854名無しさん＠お腹いっぱい。2012/03/09(金) 23:18:28.42
むしろキャッシュなんかやめればクリアする必要もなくなるのに
0855名無しさん＠お腹いっぱい。2012/03/09(金) 23:57:03.94
>>854
それは、すべて再帰検索で、という意味？
思慮の浅いヤツ…
0856名無しさん＠お腹いっぱい。2012/03/10(土) 00:38:48.37
というと?
0857名無しさん＠お腹いっぱい。2012/03/10(土) 00:47:04.19
ルートDNSがとても死ねる。
0858名無しさん＠お腹いっぱい。2012/03/10(土) 17:23:01.76
>>855
思慮以前の問題かと。
日頃から浸透とか言ってそう＞854
0859名無しさん＠お腹いっぱい。2012/03/10(土) 20:33:59.36
具体的に。
0860名無しさん＠お腹いっぱい。2012/03/12(月) 17:07:07.76
キャッシュが無い場合は、なにかアクセスすると必ずルートDNSから問い合わせることになる。

ロケットニュースから引用してみる。
【図解】60秒間にインターネット上で起こっていること ttp://p.tl/Nljh
合計して60で割ると、主だったサービスだけで秒間 2,835,284 回のクエリーがでるよね。
example.com を検索した場合、ルートDNS は gtld-servers.net. で com. を署名付きで返すから 735 bytes
単純にクエリー数をかけると 2,083,933,850 byte →最低でも秒間 2GB のトラフィックくらいは捌く必要があるんじゃない？

IP anycast やら ロードバランサやらで 13台 以上あるんだろうけど…
Twitter でバルスを叫ぶだけで 14,594q/s が簡単に乗ったりするのを考えると、ルートDNSの中の人に同情したくなる数値。

1日で2800GB以上…と考えて、回線使用料はいくら？
最終的にユーザが負担することになる金額は？
0861名無しさん＠お腹いっぱい。2012/03/12(月) 17:47:53.30
>>860
>IP anycast やら ロードバランサやらで 13台 以上あるんだろうけど…
現状だけで283拠点
http://www.root-servers.org/
>Servers in total: 283
ただクライアントがクエリーを投げる先は当然13個
0862名無しさん＠お腹いっぱい。2012/03/22(木) 21:20:30.38
そろそろエイプリールフールだな
騒がれてないからすっかり忘れてた
0863名無しさん＠お腹いっぱい。2012/03/23(金) 08:55:34.13
うちの会社は3月32日だから…
0864名無しさん＠お腹いっぱい。2012/04/23(月) 00:29:11.13
世の中には F5 攻撃というものがあるのをすっかり忘れてた…

F5 1回 = DNSクエリー 1個だから、F5 アタックがそのまま DNS への DoS アタック。
キャッシュのない世界って、ｌ怖い。
0865名無しさん＠お腹いっぱい。2012/04/23(月) 00:51:50.72
>>864
某半島のネットが一瞬で麻痺しそうだな
0866名無しさん＠お腹いっぱい。2012/05/02(水) 14:35:54.49
unboundでDNSラウンドロビンが入ったと聞きましたが、どのverからですか？
最新の1.4.16入れたけどラウンドロビンしてないようです
0867名無しさん＠お腹いっぱい。2012/05/02(水) 20:07:29.84
>>866
まだ対応してない。
ラウンドロビン対応にするパッチを書いてMLに投げた人がいる
0868名無しさん＠お腹いっぱい。2012/05/03(木) 21:49:14.52
>>866 >>867
trunkにマージされたので次の1.4.17には入るかと

今すぐ試したいならsvnからtrunkをcheckoutするか
1.4.16用のpatchをunbound-usersに投げたので使ってみてください
http://unbound.net/pipermail/unbound-users/2012-April/002324.html
08698662012/05/07(月) 18:23:23.32
>>868
わかりました、1.4.17を待ちます。。。
0870名無しさん＠お腹いっぱい。2012/05/24(木) 20:12:29.29
Unbound 1.4.17きた
ラウンドロビンも入ってますね
http://www.unbound.net/download.html
0871名無しさん＠お腹いっぱい。2012/06/06(水) 17:22:24.80
いつの間にかAAAAレコードが(あるのに)引けなくなってるな。
0872名無しさん＠お腹いっぱい。2012/06/06(水) 17:35:17.14
それだけじゃ何もわからん。
0873名無しさん＠お腹いっぱい。2012/06/06(水) 17:46:24.07
今日が何の日か知ってればわかるよな
0874名無しさん＠お腹いっぱい。2012/06/06(水) 17:55:14.07
NTTのせいでトリッキーな事をしなければ接続できない
日本って変だよ
■ このスレッドは過去ログ倉庫に格納されています