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/

**名無しさん＠お腹いっぱい。** · 2010/06/18(金) 20:04:56

>>402
DNSOPSをsubscribeしているひとはJANOGもsubscribeしてるだろう

**名無しさん＠お腹いっぱい。** · 2010/06/21(月) 08:14:22

JANOGに投げて空気変えてほしいな。

**名無しさん＠お腹いっぱい。** · 2010/07/01(木) 12:35:08

るーと更新おめでとう!!
　　　　　　　　　　.o゜*。o
　　　　　　　　　／⌒ヽ*゜*
　　　∧_∧　／ヽ　　）｡*o　　ｯﾊﾟ
　　 (・ω・)丿゛￣￣' ゜
.　ノ/　 /
　　ノ￣ゝ

**名無しさん＠お腹いっぱい。** · 2010/07/01(木) 21:37:27

windowsでもdjbdns使いたいのだが駄目かな

**名無しさん＠お腹いっぱい。** · 2010/07/01(木) 23:38:26

>>406
変態

**名無しさん＠お腹いっぱい。** · 2010/07/02(金) 02:23:48

>>406
変態だな……。

**名無しさん＠お腹いっぱい。** · 2010/07/03(土) 00:47:26

>>406
DJ本人乙

**名無しさん＠お腹いっぱい。** · 2010/07/03(土) 21:09:28

愛が感じられるような

**名無しさん＠お腹いっぱい。** · 2010/07/16(金) 23:29:13

ルートサーバーがDNSSEC対応したらしいが、
お主らのキャッシュサーバーは対応やった？

**名無しさん＠お腹いっぱい。** · 2010/07/17(土) 10:25:37

>>411
うちのはBIND9.6系でトラストアンカーの自動更新は未対応っぽいから
しばらく様子見かな。鍵はどのくらいの間隔で更新されるの？

**名無しさん＠お腹いっぱい。** · 2010/07/17(土) 11:58:15

bindは9.7じゃないとsha-2が使えないから、9.6だとそっちが引っかかる。

**名無しさん＠お腹いっぱい。** · 2010/07/17(土) 12:10:42

http://www.iepg.org/2009-11-ietf76/rootsign-ietf76-iepg.pdf
によりますと
KSKは2～5年ごと
ZSKは年4回
だそうですが。

**名無しさん＠お腹いっぱい。** · 2010/07/17(土) 18:17:22

>>413
そこは気になったけど、9.6.2rc1で9.7からバックポートされたので問題ないよね？
ttp://lists.isc.org/pipermail/bind-announce/2010-February/000621.html

**名無しさん＠お腹いっぱい。** · 2010/07/17(土) 18:32:19

>>414
それなら導入しても大丈夫そうだな。
KSK変わるときはニュースになりそうですし。

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

これは次のセレモニー以降でZSKの更新の際に行われるのかな。
スケジュールでてる？

**anonymous** · 2010/07/17(土) 21:49:33

いくつかのccTLDにDSが入っています。

**名無しさん＠お腹いっぱい。** · 2010/07/17(土) 22:40:06

>>417
確かに8個ほど入ってた。.CATなんてあったんだ。
http://www.root-dnssec.org/faq/
dig . AXFR @xfr.lax.dns.icann.org

自ドメインが検証できるようになるまではまだ時間がかかりそうだ。

**名無しさん＠お腹いっぱい。** · 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/

**名無しさん＠お腹いっぱい。** · 2010/08/12(木) 10:42:04

>>394
この件と同種？で okwave に質問してる椰子がいるが
「普通のことです。違反でもなんでもありません。」って回答くらってるぞ

どっちが正しいんだ？

http://okwave.jp/qa/q6101868.html

**名無しさん＠お腹いっぱい。** · 2010/08/12(木) 10:48:17

okwave の回答が間違ってる。
その回答に対する質問主のフォローが正解。

**名無しさん＠お腹いっぱい。** · 2010/08/12(木) 11:01:57

そうか

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

A レコード書くと、ホスト引っ越しのときに不便なんだが。。
今のところクレーム来てないが、バレる前に直しておいたほうがいいのか

**名無しさん＠お腹いっぱい。** · 2010/08/12(木) 11:59:26

質問の仕方がまずいんだと思う。
「Aの別名にBを使っているけどいいの?」って読みとられてしまっているよね

**名無しさん＠お腹いっぱい。** · 2010/10/14(木) 01:08:48

DNS障害でYahooのほとんどのサービスが落ちてたね

**名無しさん＠お腹いっぱい。** · 2010/10/14(木) 01:44:18

具体的にはどーだったの？
hostやdigで単純に引くとaレコードが帰ってこなくて
明示的にaレコードを指定すると戻ってきたみたいだけど

**名無しさん＠お腹いっぱい。** · 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)

丸１日は途中のDNSがキャッシュ値を返してくれるの？

**名無しさん＠お腹いっぱい。** · 2010/10/15(金) 14:06:25

自分が参照してるキャッシュのタイミング次第だろ。

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

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

それともYahooクラスだと権威サーバでもロードバランサ
入れないとダメポなくらい負荷高いのかね？

**名無しさん＠お腹いっぱい。** · 2010/10/15(金) 18:27:53

普通はBindで困ることって特にないよな。
DNS運用業者やってたときは、10万ドメイン以上あったから色々考えることあったけども。

**名無しさん＠お腹いっぱい。** · 2010/10/18(月) 11:37:39

「BIND」な。

**名無しさん＠お腹いっぱい。** · 2010/10/25(月) 18:53:45

2008R2 な DNS 鯖だと
recruit.co.jp のドメイン情報が全く読めないんだが
SOA レコードすら引けない。
なんでだ！？

2003 な DNS 鯖で引くと大丈夫

**430** · 2010/10/25(月) 18:59:20

>>394 と同じ理由？
とりあえず、2008R2 の DNS 鯖で ISP の DNS にフォワーダかけたらうまくいく。

**名無しさん＠お腹いっぱい。** · 2010/10/25(月) 19:02:45

Windowsの話はよそでやったら。

**名無しさん＠お腹いっぱい。** · 2010/10/25(月) 19:03:13

>>430
ポートが開いてないんだろ

**名無しさん＠お腹いっぱい。** · 2010/10/25(月) 20:01:58

他は引けるからポートの問題じゃないよ

**名無しさん＠お腹いっぱい。** · 2010/10/25(月) 20:24:37

recruit.co.jp が特定の環境下で名前解決できないという話は別の所でもでていたような…
janogだったかdnsopsだったか

**名無しさん＠お腹いっぱい。** · 2010/10/26(火) 00:30:25

512バイト超えてるんだろう

**名無しさん＠お腹いっぱい。** · 2010/10/26(火) 22:07:15

recruit.co.jpはこれと同じ原因だよ
ttp://www.vwnet.jp/Windows/WS08R2/EDNS0/EDNS0.htm

**名無しさん＠お腹いっぱい。** · 2010/11/06(土) 03:43:18

BIND10使ってるひとどのくらいいますか？

**名無しさん＠お腹いっぱい。** · 2010/11/08(月) 11:16:37

20人くらい。

**名無しさん＠お腹いっぱい。** · 2010/11/26(金) 11:36:45

政府によるDNSポイゾニングっていよいよ本格的に始まったんじゃない？
検出した気がする
先日の法相更迭はサインを渋ったからだとみた

**名無しさん** · 2010/11/27(土) 15:55:54

DNSSEC対応どーすんべ。。。

**名無しさん＠お腹いっぱい。** · 2010/11/27(土) 17:31:50

>>441
慌てる必要はないよ。必要になったらやればいい。

**名無しさん＠お腹いっぱい。** · 2010/12/02(木) 00:57:02

眺めている段階

**名無しさん＠お腹いっぱい。** · 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

**名無しさん＠お腹いっぱい。** · 2010/12/02(木) 16:37:31

http://ya.maya.st/d/201012a.html#s20101201_1
CNAME の間違った使い方

>>394-397

**名無しさん＠お腹いっぱい。** · 2010/12/02(木) 16:55:57

http://blog.livedoor.jp/techblog/archives/65340720.html
> ライブドアドメインではこれまでdjbdnsを使用していましたが、
> 今年の11月1日にNSDというソフトウェアにリニューアルしまして、
> 新機能と同時にこのCNAME問題に対応しました。

やっと対応したって事かな。

**名無しさん＠お腹いっぱい。** · 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

**名無しさん＠お腹いっぱい。** · 2010/12/03(金) 10:35:56

/etc/hosts に localhost がなかったり、
あっても hosts を参照せずいきなり DNS に聞く実装でも、
resolv.conf に search livedoor.jp と書いてあれば
localhost を問い合わせても 127.0.0.1 がちゃんと返ってくる。

……というメリットはあるけど、たいしたメリットでもないので
消してもいいと思う。

**名無しさん＠お腹いっぱい。** · 2010/12/03(金) 10:59:18

デメリットを聞いてるんだが

**名無しさん＠お腹いっぱい。** · 2010/12/03(金) 11:20:17

だからそういう環境で localhost の名前解決ができなくなるんだってば。

FQDN じゃなかったら勝手にドメイン名を補完してしまうものもあるので、
localhost. のゾーンを作っておけば済むという話じゃないんだな。

**名無しさん＠お腹いっぱい。** · 2010/12/03(金) 19:53:34

searchオプションの恩恵うける場面てそんなに多いのかな？
外の人にとっては意味ないし、中の人にしたってプログラムがsearch依存で名前解決するのも気持ち悪いだろうし。

**名無しさん＠お腹いっぱい。** · 2010/12/03(金) 20:19:29

>だからそういう環境で localhost の名前解決ができなくなるんだってば。

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

それならば削除する必要はないですね。

**名無しさん＠お腹いっぱい。** · 2010/12/03(金) 21:18:51

>>452は>>447のリンク先を日本語で解説してくれる人を釣ろうとしてるの？

**名無しさん＠お腹いっぱい。** · 2010/12/03(金) 21:22:34

なるほど！

**名無しさん＠お腹いっぱい。** · 2010/12/03(金) 21:51:53

ローカルＰＣで個人用ブックマークの検索サーバを立てた人がいるとする。

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

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

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

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

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

こんなとこ？

**名無しさん＠お腹いっぱい。** · 2010/12/05(日) 13:02:44

あとはNXDOMAIN連発とか？

**名無しさん＠お腹いっぱい。** · 2010/12/06(月) 00:59:34

こういうの一度書いちゃうとなかなか消せないんだよね。
副作用が怖くて。

**名無しさん＠お腹いっぱい。** · 2010/12/06(月) 09:19:43

なくなって困るのは中の人くらいじゃないの？
中からの問い合わせからだけ名前解決するんじゃだめなん？

**名無しさん＠お腹いっぱい。** · 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

**名無しさん＠お腹いっぱい。** · 2010/12/07(火) 03:47:54

Wikileaksをホスティングしていることでもおなじみの信頼と実績だな

**名無しさん＠お腹いっぱい。** · 2010/12/07(火) 08:07:03

アタックされたから追放したんじゃなかったのか

**名無しさん＠お腹いっぱい。** · 2010/12/10(金) 00:21:00

>>459
まだこんな馬鹿がいるのか

**名無しさん＠お腹いっぱい。** · 2010/12/10(金) 21:27:40

>>459
-DDoSを喰らったときの課金のありよう
-名前参照が終わるまで多段*4の参照が発生する
等を考えると若干首を傾げる。
Amazonにしては詰めの甘さを感じずにいられない。

Amazonがわのメンテナンスの都合でネームサーバのIPアドレスを
任意につけかえられるように設計するとこうなるのはわかるけれど。

**名無しさん＠お腹いっぱい。** · 2011/01/07(金) 02:19:48

2010年はBIND9の脆弱性が多くて嫌になった
でもUnboundとかnsdに移行する勇気がないヘタレ

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

数としてはたしかに多かったけど、dnssec を有効にしてなければ
放置しても問題ないものがほとんどだった気が。
dnssec はまだ本格的に使われてないからコードが枯れてないんだよね。
とはいえ、nsd/unbound は問題を起こしてないからそれを言い訳にはできないけど。

**名無しさん＠お腹いっぱい。** · 2011/01/07(金) 10:11:13

見つかってないだけかも。

**名無しさん＠お腹いっぱい。** · 2011/01/07(金) 16:09:39

Unboundはキャッシュとして使う限りはBIND9と遜色ない
機能はあると思う。DNSSEC validatorとしては最新の仕様に
追従してるし、ローカルデータもフォワーディングゾーンも設定できる。
Unboundに無い機能ってviewくらい？

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

>>467
Unboundはラウンドロビンを無視してTTLが切れるまで常に同じアドレスを返す
というちょっと切ない仕様があったけどアレはその後どうなったのかな

**名無しさん＠お腹いっぱい。** · 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

**名無しさん＠お腹いっぱい。** · 2011/01/07(金) 22:17:59

権威サーバから得たデータは変にいじらずにそのまま
クライアントに返すべきだ、DNSの仕様にもラウンドロビンなんて
定義されてない、というのがUnbound側としての立場だったはず。

とはいえ、ラウンドロビンは必要な機能なんだろうなぁ
Windows Vista は複数Aレコードを得ると
RFC 3484 Rule 9 にしたがって特定のIPを選択
するのでラウンドロビンが効かないんだけど、
Win7 はラウンドロビンが効くように変更されたりしてるし

**名無しさん＠お腹いっぱい。** · 2011/01/07(金) 22:21:23

UNIXの getaddrinfo()もラウンドロビンが効くように変更してください！

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

BSDやglibc派生のスマフォンは
DNSラウンドロビン的にどう動くんだろ？

**anonymous** · 2011/01/18(火) 23:57:00

いよいよjpドメインでもDNSSEC使えるようになりましたが、
おまえらDNSSEC使いますか？

**名無しさん＠お腹いっぱい。** · 2011/01/19(水) 18:03:47

いやべつに

**名無しさん＠お腹いっぱい。** · 2011/01/19(水) 19:35:29

そのうち対応しないととは思っているが検証が面倒くさい
今のところキャッシュDNS鯖の負荷が無駄にあがってるだけだな

**anonymous** · 2011/01/19(水) 19:56:58

DNSSECは効果の割に苦労が大きすぎるから普及は難しいんじゃないか
キャッシュはともかく、権威サーバの運用がとっても面倒だからなー

だいたいDNSSECなしのDNSだってちゃんと運用できてねーし
DNSSECがまともに運用できるとはおもえない

**名無しさん＠お腹いっぱい。** · 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 みたいにすれば、署名の連鎖とか考えなくてすむんだけどどうでしょう。

**anonymous** · 2011/01/19(水) 20:35:41

とりあえずはTXIDを128ビットとかに
増やすだけでよかったんじゃね
source port randomizationや0x20のやってることの本質は
それだし

**名無しさん＠お腹いっぱい。** · 2011/01/19(水) 20:54:39

>>477
それをやると証明書屋さんばっかり儲かっちゃうのよね。
SSL って netscape の独自規格が元になってるので、
政治的な話とは無関係に仕様が決まっちゃったけど、
インターネットのガバナンスってそういう特定の誰かに
集中/依存する仕組みを嫌うんだよね。

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

**名無しさん＠お腹いっぱい。** · 2011/01/19(水) 21:16:02

>>476
DNSSEC は付け焼き刃の勉強ではすぐにボロが出て失敗するので、
よほど自信あるかよほどの物好きでなければはじめから手を出さない方がいい。
概要だけ理解して、必要だと思えば信頼できる業者にアウトソースする、
つまり手間はかけずに金をかけるのが正しい道だと思う。

もっとも、信頼できる業者がどれだけ存在するのかはなはだ疑問ではあるが。

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

>>479
PKIの維持ってコストがかかるから儲からないとやってられんでしょう
DNSSECのコストをエンドユーザに転嫁しないモデルで、
本当にやっていけるのかねぇ

**名無しさん＠お腹いっぱい。** · 2011/01/20(木) 12:24:39

下のはフィッシング用？のコピーサイトなんだけど
正引きしても本家のウォルマートのIP返す

これって技術的にどうやってんの？

ちなみにトップページだけコピーしてるみたいでaguseでチェックしても安全と判定される

http://walmart.f8f8.us/

**名無しさん＠お腹いっぱい。** · 2011/01/22(土) 16:11:45

http://www.google.co.jp/search?q=site:arpa

arpaにAレコード作ると何か便利なことでもあるの？

**名無しさん＠お腹いっぱい。** · 2011/01/22(土) 23:02:12

ただの設定ミスのような気がする

**名無しさん＠お腹いっぱい。** · 2011/01/23(日) 17:27:29

walldnsみたいなことができる。

**名無しさん＠お腹いっぱい。** · 2011/01/24(月) 07:58:25

ネームサーバがin-bailiwickにできるから、逆引きにかかる手間が減ったりする

**名無しさん＠お腹いっぱい。** · 2011/01/24(月) 21:45:56

なるほど、わからん。

**名無しさん＠お腹いっぱい。** · 2011/01/24(月) 23:52:17

http://www.e-ontap.com/internet/nagoya-u/img46.html
に書いてある、コンテンツサーバがキャッシュサーバを兼ねていると
DDos に弱い、ということについて質問です。

自分がDNSサーバやサイトを構築する場合、いちおうコンテンツサーバと
キャッシュサーバは分けて構築していますが、上記のように
兼ねているとDDosに弱い(→ 兼ねていなければ強い？)というのがわかりません。

私が example.jp というドメインを持っているとして、
コンテンツサーバとキャッシュサーバは分けているとする。
分けていても、コンテンツサーバに直接 DDosアタックを掛ければ、
コンテンツサーバは応答が遅くなったりできなくなると思うのですが。

上記の資料では、DNS への DDos 攻撃はキャッシュサーバへ行われることが多い
という前提がある?

**名無しさん＠お腹いっぱい。** · 2011/01/25(火) 01:23:06

キャッシュサーバの足回りは動的IPで済む
コンテンツサーバはどうしても固定IPでないと運営が辛い

**名無しさん＠お腹いっぱい。** · 2011/01/25(火) 08:32:08

djb教の教えが微妙に混ざっていると思う。経典にあたれば考えがわかると思うよ。

**488** · 2011/01/25(火) 10:04:09

>>489-490
レスどうもありがとうございます。
教典とは以下のことでしょうか?
http://djbdns.qmail.jp/djbdns/separation.html
ここに書いてあることは感覚的には納得がいきます。

外に晒しているDNSサーバがキャッシュサーバの場合、再起検索も受け付ける
↓
再起検索は、再起検索でない検索より負荷が掛かる
↓
検索を多数受け付けるとサーバの負荷が上がる

一方、コンテンツサーバは再起検索を受け付けないように設定する
↓
DDoS(多数の再起検索)が投げられた
↓
再起検索を拒否するように設定されたDNSサーバは、超多数のDNSクエリを
受け付けても、拒否するだけならなんとか耐えられる

こんな感じでしょうか。

**名無しさん＠お腹いっぱい。** · 2011/01/25(火) 10:24:35

DDoS 攻撃を受ける、というよりも、
DDos 攻撃の踏み台に使われることがあるんでやめた方がいい。
# 詳細は dns amp でぐぐれ

allow-recursive で再帰検索の acl をかければ防げるけど、
権威サーバと共用してるようなところではどうせそんなことしてないだろう。

**488** · 2011/01/25(火) 10:43:30

>>492
dns amp でググってヒットした記事をいくつか読みました。
なるほど、自分で管理しているDNSサーバのレスポンスよりも、
誰でも使えてしまうキャッシュサーバをインターネット上に置いてしまうことが問題ですね。
(http での open proxy を、インターネット上に置くな、というのと同じか)。

どうもありがとうございました。

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

そろそろBINDも再帰検索受付不可をデフォルトとして
ACL書いた先だけ可能にするという設定になっていいと思うんだよな
9.8あたりでそうしていただきたい

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

>>494
9.4.あたりからそうなってますが。
allow-queryなどのオプションと連動するので中途半端に設定してると意味がないですが。

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

BIND9 のクエリ制限の設定って
allow-query
allow-query-cache
allow-recursion
っていう3つの項目あるけど、この3つの相互作用は
とても分かりづらいよね
9.7.2-P2のallow-queryが効かないバグとか見てると開発者さえ
理解してるか怪しいんじゃないか

**名無しさん＠お腹いっぱい。** · 2011/01/28(金) 00:37:41

セキュリティホールもいつになっても止まらないし、
もう BIND の時代は終わりだと思う

sendmail が Postfix になったように、BIND に取って代わるソフトウェアは出てこないのだろうか
コンテンツサーバ→NDS、キャッシュサーバ→unbound がいちおうあるけど。

MyDNS、maraDNS ってどうなの？

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

>>497
そこで、BIND X・・・じゃなくてBIND 10ですよ。

**名無しさん＠お腹いっぱい。** · 2011/01/28(金) 02:18:20

売店

**名無しさん＠お腹いっぱい。** · 2011/01/30(日) 21:44:27

PowerDNSは?

**名無しさん＠お腹いっぱい。** · 2011/01/30(日) 22:41:55

え?

**名無しさん＠お腹いっぱい。** · 2011/01/31(月) 14:00:59

え?