【DNS】Name Server 総合スレ Part2

■前スレ
Name Server 総合スレ【DNS】
http://toro.2ch.net/test/read.cgi/unix/1227629676/

■関連スレ
djb(4)
http://toro.2ch.net/test/read.cgi/unix/1148064021/
NSD - Name Server Daemon
http://toro.2ch.net/test/read.cgi/unix/1092799781/
▲DHCPスレ
http://toro.2ch.net/test/read.cgi/unix/997686566/
【DNS】DNS (Domain Name System) 総合 Part02
http://pc11.2ch.net/test/read.cgi/network/1264403707/ (dat落)
【設定面倒】BIND　総合スレッド【DNS】
http://engawa.2ch.net/test/read.cgi/mysv/1258628558/

■主なオープンソース
BIND ttp://www.isc.org/software/bind
djbdns ttp://cr.yp.to/djbdns.html
NSD ttp://www.nlnetlabs.nl/projects/nsd/
Unbound ttp://unbound.net/
PowerDNS ttp://www.powerdns.com/

■規格
RFC1034 ttp://www.ietf.org/rfc/rfc1034.txt
RFC1035 ttp://www.ietf.org/rfc/rfc1035.txt

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

■ついでに
ISC DHCP ttp://www.isc.org/sw/dhcp
Solarisのシステム管理
　(DNS、NIS、LDAP 編) http://docs.oracle.com/cd/E19683-01/817-4911/
　(FNS、NIS+ 編) http://docs.oracle.com/cd/E19683-01/816-6236/

Windows Server のDNSは省略だよもん

　　　　　　　 　 　 　 　 　 　 　 　 |:::ﾊ:.:.:.:.:.:i:.:.:i.:.:i./.:.:／／メノ　 左ｫ}::::ﾉ::ﾉﾉ
　　　　　　　　　　　　　　　　　 　 |::::i:::';::::::::l､::i:::ﾊ:／,ｨﾁ爪'　 　 {ﾋﾁ'!::ｲイ
　　　　　　　　　　　 　 　 　 　 　 |ﾊ::::::ヾ::::ﾊ 'Ｖﾘ ﾞ´ {､込ｿ　　　 ゛″!:::i:.:l
　　　　　 　 　 　 　 　 　 　 　 　 |:.::ﾄ､:.:.:ヾ:.ﾊｰi| 　　::::::::　 　 　 〉　ﾉ::::i::.|
　　　　　　　　　　　　　　　 　 　 {:.:.ﾄ､ヾ.:.:.:ヾﾊ lﾄ､　　 　 　 　_,　, ｲ:.:.:.:i.:ﾊ
　　　　　　　　　　　　 　 　 　 　 ヾ::ヽゞ､＼.::.＼!!　ヽ､.　　　´ ／!.::!.:.i:.:!:.!:l 　　　>>1乙ぱい
　　　　　　　　　　　　　　　　　,　'" ヾ＼ ＼:::::::::k　　 /｀　ｰ ' ｀ﾒ'ﾘ:.:.ﾉ.ﾉ:ﾉﾉ
　　 　 　 　 　 　 　 　 　 　 ／　 　 　川 　 リllＶハ. （　 i　｀＼ ,ｲｲ// //
　　　　　　　　　 　 　 　 ／　 　 　 　 　 　 　 |ｌ￣｀ヽ　 ﾉ 　　　`ﾒ､
　　　　 　 　 　 　 　 ,／　　　　　　　　　　　　{:}　 　 　 　 　 ｀ｰ'- ﾆ_
　　 　 　 　 　 　 ,／　　　　　　　　　_∠ 　 　 |ｌ　　 　 ＼ ,　　　　　　＼
　　　　　　　　／　　　　　 　 _ ,. イ´:　　 　 　 |ｌ　　　　　 ＼　　　　　　,λ
　　　　　　 ／　　 -‐‐‐-＜´　　 .!　　 /　　　 |ｌ　　　　　　　' ,　　 _,ィ'ンy}
　 　 　 　 〈　 　 　 　 　 　 ＼　 .ﾉ｀ｰ斗rｪ,,_,_,_|ｌ　 　 　 　 　 ,.ｉr'彡イy-´ !
　　 　 　 　｀ヽ､　　　　　　　　｀ ' ＜._ {jt=t-ｔ-ミ｀^Yｰrﾍr-彡'水k}　!：}　.ﾉ
　　　 　 　 　 　 ｀ ｰ-　 .._　　　　　　　｀ -ヽ.　 l｀亠^{：i￣ {：ﾘ |ﾊ　ﾉﾉ／ﾉ
　　　　　　　 _,.　-‐ ' ￣　´￣｀ ー- ､　　　 ＼｛{ 　 ｛：l 　 {：i ﾉ_,ィﾆ_ン´
　　　　　 ／/　　　 　 　 　 　 　 　 　 ｀ヽ ､＼ ＼　 ｛：l　　{∠ニｧ--'
　　 　 ／　/　　　　　　　　　　　　　　　　　｀ヽミﾆ＞ｧ┴ '´
　　　/＼Ｖ|　　　　　　　　　 　 　 　 　 　 　 　 　 ／
　　./ 　　ヾ.､　　　　　　　　　　　　　　 　 　,.　' ´

嫌です

スレ違い

糞スレだな

お母さん

キャッシュポイズニングの開いたパンドラの箱
ttp://www.e-ontap.com/dns/endofdns.html

キャッシュポイズニングの開いたパンドラの箱 -2-
ttp://www.e-ontap.com/dns/endofdns2.html

4のAAが超気になる

DNSSECしてますか？
先ごろプロバイダにDNSのセカンダリーを依頼したんですが
プロバイダのDNSがDNSSECしてませんでした。orz

それ以前にDNSSECのキーを登録できないレジストラが多すぎ。

DSレコード登録させてくれたらそれでいいのにな
でも利用者が少ないのは確実だから改修したくないんだろうね

実験用にch使ってます。

実験用に入れたISC DLVのままだ

>>15
もう使ってないのでDSレコードは削除したけどアカウントの削除方法が不明なんだよな。

自分のドメイン example.jp があって、プロバイダのドメインが example.com とします。
自前のDNS(dns1.example.jp)のIPアドレスは a.b.c.d、プロバイダのDNS(dns1.example.com)のIPアドレスは w.x.y.zとします。
プロバイダのDNSにセカンダリーを依頼しています。

example.jp NS dns1.example.jp
example.jp NS dns1.example.com
dns1.example.jp A a.b.c.d

としているあるのですが、これを

example.jp NS dns1.example.jp
example.jp NS dns2.example.jp
dns1.example.jp A a.b.c.d
dns2.example.jp A w.x.y.z

とするのは宜しくない設定でしょうか。
w.x.y.z は変更される場合は置いといて。

なぜ宜しくないかもしれないと思ったのか教えてください。
うーむ・・・どの部分がひっかかっているのでしょう？ w.x.y.z の逆引きが dns2.example.jp
ではない、とかじゃないですよね？

何かと問われると、自分では気が付いていない宜しくないことがあるのかもしれないという不安です。

>>17
そうする必要なくね。

プロバイダのDNSはDNSSECしてないので
dns1.example.com A w.x.y.z
は署名がありません。

dns2.example.jp A w.x.y.z
にすれば、自分のドメインなので署名できます。

内部名にするのはいいことだ、と言われてる。
が、DNSホスティング業者がサーバのIPアドレスを変更したら名前解決できなくなる。
そしてたいていの場合、アドレス変更は予告なくおこなわれる。
アドレスは金輪際変えないよ、と明言してるのであればいいかもしれんけど。

セカンダリ引き受けサービスをして貰うくらいなら、
ゾーン転送許可用にサーバIPを連絡されているのでは？

それなら、IP変更前に連絡はくるんじゃないか？

ゾーン転送のソースのIPアドレスは指定されています。
whoisに登録するDNSはホスト名で指定されています。
現状、これらのホスト名とIPアドレスは一致しています。

ゾーン転送のソースとセカンダリDNSのサービスIPが
この先も一致しているとは限りません。一致させない
理由は特に考えられませんが。
dns2.example.jp A w.x.y.z
と設定する w.x.y.z が急に使われなくなるのは、まあいいとしても
w.x.y.z が突如キャッシュサーバーに変身することがあると
困るかもしれません。

なるほど。DNSSEC 署名するため、自ドメイン名で外部ネームサーバを
登録したいということですね。その気持ちは理解できる気がします。
それに >>22 さんの言うように、内部名の方が好ましいとする考え方も
ありますしね。

んで本題の「宜しくないのか」という点ですが、IP アドレスの変更に気を
付ける必要があるというのは既出ですが、DNS 的には問題ないように
思えます。やってみてもいいんじゃない？

やってみましたのですが、プロバイダのDNSが
dnssec-enable no;
になってるような…。bindなのかどうか分かりませんが
bindなら、そうなってるような。

dig @(プロバイダのDNS) (自分のドメイン) +dnssec
でRRSIGが表示されません。
DNSSECに対応しているかどうか、問い合わせ中です。

dnssec-enable no相当の設定してるとこは結構あるぞ
昔DNSSEC機能まわりでBIND9の脆弱性が出たときにdnssec-enable no
とすればワークアラウンドになることがあって、その時の設定が
そのまま入ってるとこが沢山ある。
あと、ブロードバンドルータの類がDNSSECというかEDNS0に
対応してるのはほとんどない。
こんなんじゃDNSSEC普及に何年かかるのやら

DNSSECはDSレコードが自動更新可能になるまで普及しないでしょ。
年2回程度でも鍵の定期更新に人手が必要になるとかコストが高すぎる。

IETFではCDS/CSYNCを使って自動的にDSレコードを吸い上げる案が出てるけど、
まだ、時間が掛かりそうな感じ。
http://tools.ietf.org/html/draft-hardaker-dnsop-csync-02
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-11

ローコストで委託できるようにならないと普及はムリな気がする

上位にDSをアップロードするプロトコルができても、
そもそもDSを含む鍵更新の手順が複雑すぎて、ふつうのオペレータ
には対応不可能というのが問題。これ自動化されても問題の本質は変わらない。
何かがおかしくなったときに人手でちゃんと修正できるようになって
初めて実用になるが、たかがDNSをセキュアにするためだけに
全てのオペレータにプロトコルとPKIを精緻に理解することを要求する
DNSSECは人的コストがかかりすぎる
（さもなくば運用ミスは直ちにbogusになって引けなくなり、
　さらにキャッシュのため修正しても回復に時間がかかる）
IETFとかのDNSSECやってる連中は想像できないかもしれないが、
オペレータにはDNS以外にもやらなきゃならないことは沢山あるのだ

まぁこれはDNSSECだけじゃなくて、DNSCurveとかにも同じことは
言えるけどな　DNSCurve・DNSSECそれぞれ固有の難しさがあるが、
難易度は大きくは変わらないだろう

IETFではプライバシー保護の観点でのDNS over TLS/DTLSの議論が
始まってるけどな。こうなるとDNSSECとは何だったのかということ
になりかねないが

>>9
「パンドラの箱」とはおそれいった。
記事中では新規性が無いという指摘を巧妙に回避するための
レトリックを使っているが、こういう煽り記事を書いて目立たないと
いけない私大の先生も大変だな

毒がいわゆるin-bailiwickルールにマッチしていればDNSキャッシュサーバ
はそれを受け入れる（すでにキャッシュ上に同じデータがあれば
RFC2181 Rankingに従い上書きされる）という従来からある話に過ぎない。
基本的な対策はポートランダマイゼーションというのは6年前から
変わっていない。ポートランダマイゼーションしてないキャッシュサーバが
10%もあることは頭が痛いが。

この人は以前カミンスキー攻撃でDNSに毒は入らない、BIND9のバグに
過ぎないと主張していたが、こういう誤解を生む主張は全く迷惑だ。
カミンスキーの本質はそれではなく、TTLがoff-path攻撃からの保護にならず、
攻撃の成功確率を大きく向上させることができることを示したことだ。
カミンスキー以降、どのような毒が入るか研究が進んで、2010年前後に
にその手の論文や解説がいくつか出ているが、概ね↑で書いたものだ。

>>32
元文章を理解して書いているとは思えない内容ですが…??

従来の攻撃法の範疇だしポートランダム化が
緩和策いうのはその通りだけど、攻撃成功した時の影響が
大きいということでしょ。カミンスキーと類似の攻撃で
ポート・TXIDのランダム化を突破できれば、
TLD丸ごと、SLD(co.jp)丸ごと乗っ取れるという話。
TLDをターゲットにした具体的な攻撃法を示したのは
新規と言っていいんじゃないの

この人よほどDNSSEC嫌いなのか知らんけど、ポートランダム化だって
限界があるしDNSSECくらいしか次の現実的な対抗策はなさそう
（NSEC3はOptOpt無しでな）
RFC2181のルールを見直しても穴がありそうだし

DNSSECが現実的とかｗ

DNSSEC難しいことは言われなくてもわかってるよ
でも他に何があるのさ？

まともに運用できる人がほとんどいない技術じゃ無いのと同じだろ

浸透いうな・大岡山の両氏はDNSはオワコンであきらめろと言っとるよな。

DNSSECに対応しなくてもサービス提供側は困らない、というのも理由の一つじゃないでしょうか。
むしろDNSSECしたら「お宅だけメールが送れないので、お宅のメールサーバーがおかしいですよ」と言われてorzする。
さすがに今はないか？

DNSやめて別のにするのとDNSSECやるのとどっちが難しいかという話じゃね
別のを作ってもDNSと同じものができそうｗ

今の世界は腐ってるから一度リセットしろなんて聞き飽きた
いい歳して何を言ってんだ、いまどきマンガでもねえよ

現実的な代替策を提案するでもなく世界は腐ってると叫ぶだけじゃなあ

別にDNSは今のままでいいんじゃない。
サイト証明したければSSL使えばいい。

>>34
2008年当時でも、TLDの乗っ取りができないなんて話は誰もしていなくて
ポートランダマイズしてなければあらゆるものが簡単に乗っ取れる
という空気だった。
tss氏が示した毒が、ポート・TXIDのランダマイズをすり抜けられれば
TLDやSLDを乗っ取れるし、それが重大なのもよくわかるけど、
それは2008年当時から状況は変わらない。よくわからないのは、それでなにを
主張したいのかということだ。

ポートランダマイズを無効にする攻撃法を見つけたという主張なのか？
ポートランダマイズではもう不足だと言いたいのか？
ランダマイズしてないのがいっぱいあるのでランダマイズしろよという主張なのか？
カミンスキー的な攻撃は頻繁に行われているがRFC2181 Rankingによって
結構守られていた（今回そうでない毒を見つけた）という主張なのか？
DNSSECでもNSEC3 Opt-Out運用ではinsecure delegationを毒と
して入れることが可能なので、Out-Outはやめろと言いたいのか？
DNSは欠陥だらけで手の施しようがないので、もうやめろということなのか？

非専門家ばかりが騒ぎ、専門家の反応がいまいちなのはそのあたりなんじゃないか。

化けの皮がはがれるから、はっきり主張できないんだろ
attackerに情報を与えることになるから
詳細は公表しないって逃げるに決まってる

>>43
ポートランダマイズの効果を薄くする方法はある…っぽいが、
オープンリゾルバで無ければ大丈夫かと思う。

普通のフルリゾルバであれば、とりあえずランダマイズで
対応する、で行くしかないんじゃないかな。

ただ、TXID＆ランダマイズを抜けた後の手法がより危なく
なったので、ポイズニングに対する監視は充実させたほうが
よいのかもしれない。

unboundなら、「unwanted-reply-threshold」設定とか、
その他ならば、パケットキャプチャでクエリとレスポンスの
割合とかを見ておくとかかな？他にもあればPLZ.

いずれにせよ、今全てを投げ出すわけにもいかんのだし、
やれることを粛々と頑張るしか無いよね。

オープンでもクローズでも、基本的な動作原理は変わらないのでは?

それに一口にオープン良くないというけど、そのオープンてどういう定義なの?
オープンは危ないという風評被害もありそう

>>46
え、オープンリゾルバに定義いくつもあるの？

ISPのDNSサーバは、ISP加入者全てからのクエリを受けつけるようにしてるのでかなりオープンに近いけどな。ISP加入者がボットに感染してるとか普通にある

>>46
あまり詳しく書くのははばかられるが、オープンだと
ポートランダマイズの効果を下げる事前作業がやりやすい

>>48
許可NW内のBOTを使えば、同じようなことは出来るので、
許可NWが多いリゾルバとかは危険かもしれない

いずれにせよ、そういうところは監視による警戒を厳
として、危険な兆候が見られたら即対応などを考えて
おいたほうがよいのかもしれない

もう監視しかないんですかね。それに検知したら出来ることって何でしょう

GoogleDNSって、たしかUnbound使ってたと思うけど
何か特殊な設定仕込んでるのかなぁ

自前でオープンリゾルバなDNS公開設定しようかと思ってるんだけど・・・

用途は、避けたいサイト（正引き）で127.0.0.1を返すため
スマホとかで自前DNSを利用したい

>>50
JPRSも書いてたけど、危ないと思ったらキャッシュクリアするとか…

あとは攻撃元IPを見つけたら、BANして通報とかかな。

>>51
GoogleDNSは権威側で動作を見てると、多段で構成されてるっぽい。

フロントはオープンだが単なるフォワーダっぽいリゾルバみたい。

バックエンドはオープンでないフルリゾルバで、フロントからの
問い合わせにだけ答えている模様で、こちらは色々対策している
のでは無いかと思う。

>>51
> GoogleDNSって、たしかUnbound使ってたと思うけど
それどこ情報?

「攻撃元IP」が偽装されたJP DNSだったりするからBANできないっしょ

>>51
それってオープンリゾルバの一種なの?

Googleのはオープンリゾルバだよ。

リゾルバは何回もバシバシ叩くことはほとんど無いし
基本的にパケットの分割も無いから
同じ相手にUDPのパケットを返すときに
2つ目以降のパケットは数秒待たせても
問題ないよね？

フォワーダっぽいリゾルバ ?

自前でオープンリゾルバなDNS公開設定しようかと思ってるんだけど??

質問を続けるなら名前入れといてくれ。
どれが誰だかわからん。

>>52
フォワーダっぽいリゾルバって何だ？
VIPで受けて大量のキャッシュDNSサーバへロードバランシングしてるんじゃなくて、
回送専用のDNSサーバで受けて、ドメイン単位で回送したら再起検索専用のDNSサーバで検索…ってこと？
なにそれ怖い。

TLDごとにその国に近いリゾルバに回送してそこで反復問い合わせさせれば、確かに理論的には速くなるな。

>>61
aho ?

やめた、DNSSECやめた。

急にどうしたんだｗ
鍵更新をしくじりでもしたのか。

プロバイダがね、セカンダリがね、DNSSECはね、やってねえだって。

セカンダリならたいした手間でもないだろうけど、逆にプライマリ提供できないのが浮き彫りになるのが嫌なのかな。

へー、そんなところもあるのか。

ウチは DNSSEC に関して何もアナウンスしてないけど、問い合わせを受けたら「レジストリへの取次と
セカンダリ運用は承りますが、プライマリの運用はお受け出来ません。ごめんなさい」と回答する予定です。

まだ問い合わせは一度も来たこと無いけどね！ (酷いオチ)

自分とこでDNSを二台たててDNSSECしてたんだけど、プロバイダにセカンダリをやってもらおうと思って。
zone転送の設定まではスイスイと行ったけど dnscheck.jp で見たら、プロバイダ側のDNSSECが×だらけ。
サポートに問い合わせして、「おかしいにゃー、調べてみるんで待ってて」ってことで待ってたら
「やっぱりDNSSECはやってないんで、メンゴ」ってことになった。

atndやっちゃった？

atnd 見えないね。権威サーバが何も返してこないんだけど、この時間になっても
復旧してないとは思わなかった。何やってんだ、中の人。

参考
↓
ttp://www.e-ontap.com/blog/20140527.html

あ、ようやく見えるようになった。だけど TTL が 300 になってるねｗ
絶賛リカバリ中ってとこなのかな。

まともに運用できねえやつにかぎってDNSSECとか使いたがるんだよな。

今回のはそれ以前の問題w

ん？ まだ atnd.org の TTL が 300 のままですね。権威サーバの ns[1-3].x.recruit.co.jp という
ホスト名がいかにも仮のものっぽいけど、しばらくこのままなのかな……

数年前、名前解決の障害でrecruit.co.jp調べたとき、EDNS未対応だったか、
TCP非対応だったか忘れましたが変なサーバだったのを覚えてます。

古い上にあやふやな情報だな。

で？
なぜインフラ予約ドメイン名を定義しないで、ねずみ講のようにドメイン登録をプッシュするんだ？
ARPAとかがあるから、今後は
おれんち.ARPAとかで逃げ始めるバカがわくと思うんだけど

おう、直接言ってやれ。

インテリやくざ集団に直接談判とかヤダー
判子屋と組んでうまい汁をすおうとかプレゼンかいてインターネットでシェアするような奴が集まるのがIT業界じゃないですか

んじゃ状況は変わらんね。

重複をお許しくださいキター
# まだ7月じゃないのに・・・

OpenBINDはよ。

重福

>>82
???「ANSﾄﾞｿﾞｰ」

でもお高いんでしょう?

DNSがオワコンなのに、気付いてないヤシが大杉留みたいね
合掌

みんな気付いてるよ。
気付いてるけどかわりがないから使わざるをえないだけで。

http://www.dnszone.jp
DNS 進化への渇望

>>86
DNS使わない派？

やっぱ NIS+ だよな

やっぱり僕は、王道を征く、Active Directoryですか

いやいや、hosts を共有するってのはどう？

FQDNを所定のハッシュ関数に通すとIPアドレスが一意に決まるようにしておけばいい。

>>91
DNS抜きでActiveDirectoryを使える？

>>93
そのハッシュ関数はどのように実装されるのでしょうか？
IPアドレスが変わったら、どうなるのでしょうか？

>>95
ハッシュ関数はだれかが「これ」と決める。
IPアドレスは変更できない。というか、使いたいIPアドレスになるようなFQDNをハッシュ関数から探して使う。

>>96
なるほどー
例えば192.168.10.203というIPを使う場合、それに該当するFQDNを採掘するわけですな。
あらかじめ発見しておいて、○.○.○.○に対応するFQDN教えます、という広告をオークションに出しおけばいいのか。
203.10.168.192.in-addr.arpa より分かりやすいものであることを願おう。

>>94
すいません許してください！なんでもしますから！

>>98
ならば、これからは私利私欲ではなく、世の人のためにその力を使うのじゃ。

なんでホモが沸いてるんですかね

使うコマンドが dig （穴とかを掘る意味から）だからじゃない？

ISCのBIND祭と言えば、六尺褌一丁のDNS担当者たちが、
namedをアップデートし合う、勇壮な祭りとして、
この地方に知られている。

BIND兄貴オッスオッス

Google Public DNS (8.8.8.8) から ようこそﾜﾛﾀ
うっせーよハゲ

8.8.8.8 でこっパチー

浸透っていうと育毛剤を連想しちゃうハゲ

あーじゃあ浸透って言ってる奴には
浸透させなければいけないのは育毛剤です
と返せば良いのかｗ

知識が浸透してくれればいいのに…

夏のbind祭りﾏﾀﾞｰ?

DNS名前衝突ブロックリストな件
ttp://internet.watch.impress.co.jp/docs/news/newgtld/20140812_661957.html

これ、DNSプリフェッチ機能で問い合わせされたドメインは、除外されてるの？
どうしても登録させたくないドメインを毎日機械的に問い合わせてれば、禁止にできるの？

中の人、あ意外とほっぽい。

「できる」じゃなくて「できた」だな。

あれ、この記事、申請拒否されたドメインがプレミアム予約リストに該当してるんなら、
やっぱりレジストラが腹黒ってことになるじゃね？

>>112
どういうこと？

>>113
そのページだと軽く流して、直ぐに名前衝突に話が進んでいるが、
付加価値がつく名前はレジストラが先に予約しているって書いてある

.network .dot .inspire .trust
.nt .do .nex .aegis .terra
とかプレミアついて人気レジストラになれそうじゃん

こういうのはレジストラがキープしてねずみ講の親になるから、パンピーにはやらんってことだよ

今に手数料の上納ルールが作られるだろうしね
仕組み上必ずルートに検索かける通り、上の方は負荷がかかるから保守費払え、インフラただ乗りすんなーってね

Alternicが法的に禁止されるのかw

nsdでセカンダリ建ててます。
プライマリのレコードが（SOAも）変更されたとき
セカンダリに転送かかるべきところ、そのタイミングでセカンダリ側のnsdが落ちます。
(プロセスにも残らない)

Sep 9 08:00:48 ubuntu14 nsd[14255]: database corrupted, cannot update
Sep 9 08:00:41 ubuntu14 nsd[1149]: message repeated 54 times: [ wait failed: No child processes]
Sep 9 08:00:48 ubuntu14 nsd[1149]: handle_reload_cmd: reload closed cmd channel
Sep 9 08:00:48 ubuntu14 nsd[1149]: Reload process 14255 failed with status 256, continuing with old database
Sep 9 08:00:48 ubuntu14 nsd[1149]: wait failed: No child processes

※ubuntu14 はホスト名

shutdown -r now で再起動かけると
ちゃんと起動直後にゾーン転送が行われ正常終了します。

プライマリのSOAが変わらないうちは好調に動作しますが、
またゾーン転送がかかると落ちます。

なにか原因として考えられることありますでしょうか。

database corrupted

再起動すると正常動作（かつゾーン転送も済んだ状態）になるから
実際にはデータベース壊れてないと思うんだけど・・・

重複をお許しくださいｷﾀｰ

>>117
nsdc patch してみてください

DNS1で名前解決できなかったらDNS2に問い合わせ
という仕組みを構築したいんですが、これって無理ですかね？

DNS1の電源が落ちているとか通信自体ができない場合はDNS2へ問い合わせに行くのですが、
DNS1の応答が「そんなレコードありません」という応答だった場合、
DNS2に見に行かないのです。

おそらく通常の仕様なのはわかっているのですが、何とかなりませんか？

社内向けDNSサーバーで解決できなかったら
クラウド上のDNSサーバーで解決させたいのですが・・・。
同じレコードを持てない理由がありまして・・。

「同じレコードを持てない」というのをもちっと詳しく書けませんか？

なんとなくzoneとかforwarderとか
そんな感じのことで調べてみるとなんとかなったりするかもしれません。

DNS2だけ見に行くようにして
DNS2をforwarderにするのがよさそう

hoge.jpは他者管理



「www.hoge.jp」←インターネット上のhoge.jpの名前解決はDNS2
　　　　|
(インターネット)
｜
「自社：jiya.jp」-(VPN)-「wwwsec.hoge.jp」←VPN上のhoge.jpの名前解決はDNS1


VPN上はセキュアなネットワークというポリシーらしく、
DNS1-DNS2間の通信はできない

hoge.jpという同名のドメイン名が
VPN上とインターネット上　両方にあるのが問題かなーっと
でも他者なので口を挟めない。

自社にDNSサーバーにwww.sec.hoge.jpの問い合わせが来たら
DNS1へフォワードするってのが簡単に思いついた事だけど、
hoge.jpのサーバーが増えたりするたぶに手で修正すうのは面倒・・・。
DNS1レコードがなかったらDNS2へ追い合わせ汁！っていう形とれないかな？

/etc/hostsに書いちゃえば

実在のドメイン名を例示に使うな。

hoge.jpに勤務してる人じゃないの？

あそこは勤務とかそういうとこじゃないよ。

hoge.comの日本法人かと思った

hoge はあれなんで example.jp で話すけど
example.jp は他者が管理していて、そのサブドメイン sec.example.jp を
自分のところの中でだけ存在させたい、ってことかな。

もし、そうなら自分のところDNS(DNS1なのか？)に勝手に sec.example.jp のドメインを持たせてしまえばいいんじゃないか？
example.jp のDNSで委譲してもらわなくても、クライアントがDNS1に問い合わせるようにしとけば
sec.example.jp については名前解決できる。

サブドメインじゃないよ、ホスト名だよって場合でも、ホスト毎にzoneを作ることは可能。

localhostのサブドメインでやればいいだよ好き放題作っていいんだから

>>122
そういう名前解決をしてくれるDNS3を用意したいけどどのDNSサーバだと実現できるんだろうって話？
>>132
RFC2606で予約されてるのは、.test、.example、.invalid、.localhost、example.com、example.net、example.org
example.jpは予約されてませんよ、という野暮なツッコミ

example.jpは実在するレジストリサービスが例示用だと言ってなかった？

RFC2606がすべてではないという話だな

VPSで逆引きホスト名って１つ設定できるようになっているけど
xxx.jp か　www.xxx.jp　にするべきか

実在のドメイン名を例示に使うな。

example厨が沸いてきた

>>133
これは気持ち悪い。

例示にはアスタリスクとか、あり得ない文字使えばええんちゃいますの？
www.***.jp とか。

実在するワイルドカードとの見分けがつかなくなる

perlのバージョン違いのテスト用に
p516.localhost
p518.localhost
p520.localhost
とか
vmに振るなら
deb.localhost debian
net.localhost netbsd
ubu.localhost ubuntu

アスタリスクってドメインに使えますのん？

アスタリスクかぁ
使い方としたら、こんな感じ？
zone "localhost" { type master; file "localhost.db"; }

@ IN SOA localhost. mail.localhost. ( 1 2 3 4 5 )
IN NS localhost.
@ IN A 127.0.0.1
* IN A 127.0.0.1

かなり遊んだ設定だけど。

DNSの仕様上は、名前に*という文字が含まれていても問題ない。
アプリケーションがそういう文字を含む名前を扱えるかどうかはそれとは別問題。

むかし、*.cnというAレコードが実際に存在してたことがあるよ。
ワイルドカードを作るつもりで間違ってそうなっちゃったのか、
意図してそうしたのか、cnのやることだからわからん。

>>146
> DNSの仕様上は、名前に*という文字が含まれていても問題ない。
その根拠は。

横から失礼するけど、DNSの仕様ってどの範囲までを言うのかよーわからん
RRのフォーマットまでが仕様っぽいように見えるけど、そんなんネームサーバの
実装ごとに違っても別にいいじゃんって思うし。

仕様っていったら、当然 RFC に書かれた文章そのままだろうに…
古いホテルの様な拡張につぐ拡張で、わかりにくいけどな。

いいんだぜ。 hosts に記載された内容を応答する named を作っても。

>>149
*を使っていいってどのRFCに書いてんのよ。

>>147
きっと大元は RFC2181 なんだろうけど、ラベル名の定義が他の RFC で
アップデートされてるのかどうかが、よくわからん。これを読めば DNS の
仕様が一通り把握できる便利な RFC とか、ポータルなサイトとか無いのかな？

Information on RFC 2181
ttp://www.rfc-editor.org/info/rfc2181

ドメイン名の管理を代行する企業であってすら、
設定ミスを浸透と呼んで誤魔化すのが日常だし…
そんな便利なもんがあったらこんな状況にはならん気が

使えるのはアルファベットと数字とハイフンだけじゃなかったっけ。
ソースは RFC952 の 1.、RFC1035 の 2.3.1. あたり。ついでに RFC1123 の 2.1.も。
情報古いかな?

>>151
> きっと大元は RFC2181 なんだろうけど、
* 使っていいってどこに書いてある?

*に関してはRFC1034の4.3.2., 4.3.3.かな?

>>154
それは>>146とは別の話でしょう。

例示にはドットを使えばいい。

www.....jp

>>153
孫引きばかりで申し訳ないけど、以下のような解説を複数見かけました。
それで RFC 2181 が「DNSの仕様上は、名前に*という文字が含まれて
いても問題ない」の根拠なのかな、と。

# それにしてもあやふやだよな〜とは思う

> BIND 9 はドメイン名に使われる文字集合について制限しない。 RFC2181 の第11章にしたがい、
> 完全に 8 ビットクリーンである。DNS で広報されるホスト名は RFC952 の規則に従うことが強く
> 推奨されるが、 BIND 9 ではそれを強制しない。
(ttp://d.hatena.ne.jp/S_a_k_U/touch/20130612 より引用)

> RFC2181 #11 によると、DNS のラベルに使える文字に制限はない。バイナリ値でもかまわない
> （「日本語.jp」を punycode で符号化せずに Shift JIS で登録したって、DNS の仕様上は
> 違反ではない。JPRS が却下するけど）。ラベルの制限は長さだけ。
(ttp://ya.maya.st/d/200605c.html#s20060529_2 より引用)

> RFC1034 #3.5 や RFC1035 #3.1 にはアンスコがマズいと受けとれるような記述があるが、
> これは DNS でそういう文字を使うのが禁止という意味ではなく、アプリ側の都合でそういう
> 文字を使うことができないかもしれないから注意しろ、という意味である。
(同上)

>>157
分散データベースとしての DNS システムは
使える文字に制限はない、ってことか。
なるほど。

3com.comが登場したとき
数字で始まるのはAUTOだろ、と
誰かがfjで議論してた記憶があるのだが

アスタリスクはもっとだめだろ

それはともかく例示のexample厨はタヒね

DNSの仕様上使える文字＝レコード定義に使っていい文字、ではないし、
BINDなどの各DNS実装で実際に定義できる文字＝レコード定義に使っていい文字、でもない

ホスト名、ドメイン名、リソースレコード名、メールドメイン名などなど、
それぞれのRFCで使っていい文字、長さなどが規定されている

でも

hoge.example.com

これはホスト名？（サブ）ドメイン名？リソースレコード名？メールドメイン名？
適用されるべきRFCは何番？
そんなの区別つかんやろ？ そもそも排他でもないし。

それをデフォルトで安全側に倒してチェックしていたのが BIND 8 まで、
自分で勉強して正しく定義しろや、となったのが BIND 9

最近は静かだと思ってたら、こんなんが来るのか。DNS は罪深いのう。

（緊急）複数のDNSソフトウェアにおける脆弱性（システム資源の過度な消費）について（2014年12月9日公開）
- BIND 9では権威DNSサーバーにも限定的に影響、バージョンアップを強く推奨 -
ttp://jprs.jp/tech/security/2014-12-09-multiple-impl-vuln-delegation-limit.html

とっくにNSD/Unboundに切り替えました

Unboundも対象だよ

▽対象となる実装／サービス・バージョン

現時点において判明している、本脆弱性が影響を及ぼすDNSソフトウェアは
以下の通りです。

・すべてのバージョンのBIND 9

・すべてのバージョンのUnbound

・すべてのバージョンのPowerDNS Recursor

某氏の後出しじゃんけん…w

dnsmasqのことは書かれてないな、どうなの？

djb()笑

そういやBIND10はどうなったんだ？
開発諦めたの

Bundy(笑)

うちはBIND8だから（震え声）

10は鬼門だな。
Sendmail Xなんてのもあったね。

この案内を見てパッチ当てようと思ったら、まだyumで提供されていないんだが？
サポート料金は言い訳しか言わないテレクラ料金か？
と思っているけど恐くて口に出せませんです

そういうのはLinux板へ。

unbound.conf ですけど

　forward-zone:
　　name: "."
　　forward-addr: 192.168.1.1

の行が無視されてしまってます。
192.168.1.1に問い合わせに行かず、rootへ聞いてるるみたいでして。
ちなみにこの3行を削除しても dig に成功してしまいます。

どうなってるんでしょうか。

BIND「フヒヒｗサーセンｗｗ」

>>174
まったく検証せずにテキトーなこと言ってみるけど、それは本当に root に
問い合わせがされているのか、どうやって確認しましたか？

root hint が関係している予感がします。

bindのforward only相当の設定が必要ってこと？

>>174ancher-keyなんちゃらってのをコメントアウト
あとはunboundのDNSSECの無効化参照。

>>174
基本的には、それで 192.168.1.1にforwardされるはず。
Unboundのforward-zoneは、デフォルトで
BINDのforward-only yes相当だしなぁ。確認するポイント：

1. unbound-control list_forwards で、
Unboundが認識している設定として forward先が 192.168.1.1になってるか
確認。なってるなら「. IN forward: 192.168.1.1」という表示になるはず。
　→ OS付属やパッケージのUnboundの場合、起動スクリプトやresolvconfが、
Unbound起動後に勝手にforward先を変えることがある

2. 対象のUnboundに digできてるか確認。dig @127.0.0.1 www.google.com
のようにIPを指定して digしているか?

また重複をお許しくださいが来ましたね。いつもの通り BIND が対象ですが、今回は
DNSSEC 検証が有効になっていなければ影響を受けないそうで……

正直なところウチの会社は有効にしてないんだけど、有効にしていることろって
結構多いんですかね？ 一般コンシューマ向けにサービスしているキャッシュサーバでは
有効になっているところの方が多いのかなあ。

なんでBINDのDNSSECはこんなに穴が出るんだろうな
根本的に作りがおかしいんじゃないのか？

iscのソフトウェアは必要なら再発明するようにして全て排除すべきだよ

OpenSSLのような？

>>180
権威サーバーがヘマこいてるのにこっちのリゾルバの障害だなんだとディスられるんじゃ割に合わんだろ。
NASAですらやらかすのに。

某ISPとか、キーマンらしき中の人抜けたけど無事に回せてるのかな。

こんなDNSSECにまじになっちゃってどうするの

国内のキャッシュサーバーは「有害サイト」をブロックするために勝手に虚偽の応答を返すし

気休めかもしれんがDNSSEC標準化にはちょっとだけ期待している

>>181
BIND9ってNominumに委託して作り直したんじゃなかったっけ？
にしても痛いバグ大杉だね

>>187
そんな話あったの？
Infobloxにお願いしたほうが早そうだよね。
Cricket LiuさんやJimmeiさんいるし。

>>188
「BIND9 Nominum」でググると出てくるよー。
Wikipediaにも書いてある。
http://en.wikipedia.org/wiki/BIND
>Version 9 was developed by Nominum, Inc. under an ISC outsourcing contract,