hito による投稿:

なんとなくnamed.confを含め、/etc/bindの下で何かをした結果のような気がしますが、その状態に至るまでの経緯は説明できるでしょうか。
説明できないなら、bind9パッケージを一度purgeして入れ直し、再設定した方がよさそうです。

さっそくどうも　hito さん
ご心配ありがとうございます。
さて、そうですね。
DNSを今のubuntuに載せてからはかれこれ１年くらい　この110号機は動いてくれています。
まあ仕事のほとんどはやってくれているわけです。
ドメインがあるが故に皆さん見にこられるわけでして、どこかにサーバを移転するとか委任するとか
を現在も将来もまったく考えていません。　自力で何とかしたいわけです。
個人しように近いので、責任はあまり無いです。うまくいかなくても人のせいにすることはありません。
ですからここでなんとか頑張るつもりです。頑固ですみません。
セキュリティの面では慎重に行いますのでどうかご安心ください。
踏み台にされたことは過去に2度１３年ほど前です。linuxとは2.0.29からのお付き合いでした。
その割りには成長は無いです。それは管理が医者に任せていたからです。
実力がついていないのは事実ですが安全面は気を配っています。

いまのところアパッチが動いていますので単体動作は問題ないので
久しぶりにDNSに手を入れて　と考えていたわけです。

確かにkeyの扱いが未だ理解していません。最近の機能についてはまったく理解できていません。

その点で言えば「あきらかに実地で自力運用するのは時期尚早」という意見は分かります。

そこでそのkey の関係したbind9 の今風の設定でやってみて、だめなら古の設定にすればいいじゃないか
と考えているわけです。

「かにか起きたら」と心配は無用です。お気軽にお教え願いたく。個人使用ですし、
なにかあっても文句はいうようなことは考えてもいません。

なお稚拙な質問のせいで「まったく知らん奴が無謀なこと」をとは考えないでいただきたい。
最近のDNSになれていないのです。

あまりに便利になりすぎた機能がついているために知識が追いついていないのです。
昔のように簡単に　named.conf だけにしてもいいかなと思いっているほどです。

半年程前にも前に質問させてもらっていて、先生方から
「基本は　named.conf だけしか見てないですよ」と教えてもらったので、最終的にどうしても
理解不能なら、そちらにすることを考えています。
でも、その前に今のUBUNTUに乗っている　今風のbind9 のファイル構成やらでやってみたいのです。

前置きが長くなりました。
セカンダリはmaehamaを設定したり、しました。db.local など　db.* など一応文法的にもあまり間違いが
無いのではと思うほどほど見つめています。
さきほどは　もしかしたら　db.root が古いからかな　ということで新しい　db.root
に差し替えました。もちろん/ etc/bind/ 内のあるべきところに置いていたわけです。

にも関わらず
db.root が見つからないとなったので、何のことだろうということで質問させてもらいました。

key も generator で作ってから　エラーは少なくなったとき記憶しています。これをいじったのは半年前

でも完全にはエラーが消えないわけです。

もうちょっとこのまま頑張ってみて、だめならパージでやり直し、それでもだめなら　naked.conf 一本で考えます。

よろしくご意見ください。

ryさんどうも回答ありがとう

ところで、DNSに詳しい方に質問です。
「二台PCを用意、一台のマシンをDNSとpopサーバとapache、その隣にもう一台は apache と smtp
二台目はサブドメインにしたい（いろいろテストしたいから）」という命題があるとします。
現在のUBUNTUには　bindでお勧めの設定が雛形で用意されています。
それらの「コマンド類の中で新しめの（ここ10年程度）（★とする）」には主として　option / forward / acl / view
などがありますが、
ここで、　「bindの新しめのコマンド★」をすべて使わなかった昔ながらの named.conf
ほぼ一本にまとめたとする。 つまり昔ながらのコマンド類だけで構成させたような場合ということですが、
このような場合においての質問です。

問一　：　UBUNTUにおいては、セキュリティ上特別な問題がありますか？　（拡張しません）
　　　　　UBUNTUとbindの関係上なにか問題となるとか
問二　：　UBUNTUもbind9 に合致すれば使えば良い。
　　　　　私感：　特に問題は無しと想像します。
問三　：　上記の場合、拡張性には問題がある。
　　　　　私感：　そう思います。今の方がよっぽど便利。
　　　　　サブとかキャッシュだののいろいろできる。
　　　　　しかしメインほぼ一機ですからいろいろできるようにしておくことがほとんど無い場合は
　　　　　特に問題点が絞りにくく間違いが発生しやすいと思う。
問四　：　同じく、速度的に不利な点がある。
　　　　　私感：　逆に早いかもしれない。　html の変遷を見ても同じようなことがいえるのでは？
問五　：　古（いにしえ）の bind コマンドしか知らない人はサーバーを立てない方が良い。
問六　：　同じくこのコーナーでは質問しないほうがよい。

私感　：　新しい構成は確かにいろいろできる。でも私がやりたいことはあまり拡張は考えていない。
　　　　わりとシンプルな要求構成だと思います。
　　　　実際に作ってみて今運用しているわけですが、実際には多くの分派したファイル群に分かれた為、
　　　　ミスを探す範囲が広がり正直とっつきにくいし面倒です。
　　　　ミスタイプを見つけにくくなっている。
　　　　現在の私の設定にはどこかのミスの項目があるのでしょう。
　　　　先だっては「．」と「,」を間違って入力していましたが、それを見つけるのに結構手間取ったのです。
　　　　一般の自称においては、シンプルイズベスト的な考えが通用しそうですが、
　　　　bindの場合そうといえるのかどうか　私は確信が持てません。
　　　　そこでお尋ねしていたわけです。

よろしくお願いします。

気になるとこだけ
問一　：　UBUNTUにおいては、セキュリティ上特別な問題がありますか？　（拡張しません）
　　　　　UBUNTUとbindの関係上なにか問題となるとか
問二　：　UBUNTUもbind9 に合致すれば使えば良い。
＊具体的な、バージョン間比較で質問しないと答え難いと思われます。
nameサーバは、特に古くて危険なサーバなので、頻繁に安全対策が施されているらしいので...
＊bindは、apparmorの影響を受けますので、よく知りませんが、Debianとも違う設定が必要かも。

si による投稿:

気になるとこだけ
問一　：　UBUNTUにおいては、セキュリティ上特別な問題がありますか？　（拡張しません）
　　　　　UBUNTUとbindの関係上なにか問題となるとか
問二　：　UBUNTUもbind9 に合致すれば使えば良い。
＊具体的な、バージョン間比較で質問しないと答え難いと思われます。
nameサーバは、特に古くて危険なサーバなので、頻繁に安全対策が施されているらしいので...
＊bindは、apparmorの影響を受けますので、よく知りませんが、Debianとも違う設定が必要かも。

基本的にupdate upgrade はすべて行っている状態での質問と思ってください。
UBUNTUは10.04
bind9 も最新です。

petitbootang による投稿:

グローバルではなく、内向きの DNS で十分に研究をされてからにしてください。
みなさんのアドバイスは、外部に深刻な迷惑をかける場合があることを心配してのことです。
ネームサーバのおかしな設定は、場合によっては DNS ネットワークを混乱に陥れる可能性があります。

個人しように近いので、責任はあまり無いです。うまくいかなくても人のせいにすることはありません。
「かにか起きたら」と心配は無用です。お気軽にお教え願いたく。個人使用ですし、
なにかあっても文句はいうようなことは考えてもいません。

このあたりの見解が、グローバルネットワークでのサーバ管理者の発言とはちょっと信じ難いんですね。
何かあったときに困るのは hotohoto さんの管理するネットワークではありませんよ。

セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)


petibuutangさん　ご心配ありがとうございます。
私もセキュリティは最優先して考えています。それはみなさんと認識は同じです。
「質問に回答してもらったことについて」責任を転嫁するつもりが無いと申し上げている訳ですが、
これは悪い言い方だったでしょうか？
「いい加減な海藤だったら責任追及しても良い」ということでしょうか？
私はお気軽にご回答をいただきたい、その思いでそう書いただけです。
それは信じがたいことでしょうか。

またご心配のことは言われる間でもなく当たり前のことです。
なにがあったとしても自分で責任を持つということこれも当たりまえのことと考えています。
セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

いつの時代も dns の攻撃などが良く行われていること。
防御方法の対策と攻撃者のまた新たな攻撃方法。いたちごっこ的なこと。
この辺については改めて申し上げることもない事柄です。
ですからこの辺の倫理的なことがらについて論じるコーナーにしたくなかったので、
あっさりと個人的な使用と書いただけです。「要は（セキュリティについては）心配ないですよ。
その心構えはあります。その対策もします」とは前提です。そで申し上げたわけで、
こう書いてもまだ「心構えじゃあまだダメだよ」という意見もでるかもしれないのでいいますが、
実績的にも攻撃され外向きに問題になったこと１３年前に一度あったきりです。
それ以後は外部に迷惑をかけたことはありません。
それだけセキュリティには注意をはらっていますししてきたつもりです。
もし心配していなければ、誰にも相談しないでさっさと「旧式の named.conf設定」でやっていたでしょう。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

dns　に限らず　新たな攻撃など次々と開発されています。
外部にサービスを提供するものは人的な運用を含めて慎重なつもりです。
だからその点は心配ないですよと申し上げているわけですね。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

なにかおかしなことがあったらすぐ止めます。ですから私の手元にはいつもモニターがあります。
log は流しっぱなしで、 dnsに限らず不調があれば、それは
「個人的な使用」ですからいつでも期限不定期に止めることが出来ます。
（厳密に言えば特定の会員だけにスタティック中たちのデータを提供です。サーバ止めたら「ごめんね」で済む程度）
このようにソフトだけ人間だではない体制です。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

こう書くと今度は「個人的ないつでも止めてもいいなんて、そんないい加減なサービスするくらいならやめちまえ」
といわれそうですが、どうかいたら分かってもらえるでしょうかね。
まあもしそういう質問が来たら「そんなの勝手」と答えるかも（笑い）
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

もどって、逆にここで質問しているのは、前提としてはセキュリティを考えての質問と理解してください。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

「過去のそんなにいろい経験があるなら質問するな」といわないでいただきたい。
私は特にUBUNTUのことをあまり良く知りません。
端末にもやっととなれてきた程度です。しかし端末は端末それほど危なくない。
自分は「端末ではやれそうだったらやってみよう」で進める傾向がある。稚拙な質問も多いでしょう。
でもサーバに関してはそうではない。
端末のことはさておきサーバ運用には１３年前の踏み台にされた記憶は鮮明で悔しい思いをした。
競って意味すだったからではありません。脆弱性をつかれた。
その時は何かあるかもということで出城サーバまで用意しましたが本丸サーバーもやられてしまった。
だから今は絶対安全主義です。
実際にサーバはサービス提供（自分だけへのsmtpが主です）は最低限に限っています。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

あらためて書きますが特に基本はセキュリティを考えています。それを前提として質問しています。
dnsの解説はプリントにして読んでいます。熱さは５センチ位になります。
厚ければ良く勉強しているのでえらいでしょとかはいいませんよ、でも勉強して無い分けでもありません。
（そんなに勉強をしてるなら分かっているなら質問するなとは言わないでね）
私はほぼ完全に納得理解しないと分かったとは言わない主義なので。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

その資料はネットで落とした資料ものですが親切に書いてもらっている。為になる。
そしていろいろな形での設定方法があるわけです。大まかにいうと
「maned.conf だけの簡便な方法」　「db.domainなどを使って設定ファイルを分割する方法」
が紹介されてもあります。（関係していることはこれなのでこの２つに絞った分類にした）
UBUNTUでは最近の思想に基づいて「設定構成ファイルを分割する方法」がとられていますね。

この方法は、それぞれはシンプル・補修・修正・拡張しやすかったりでメリットでしょう。
でもデメリットとしては「ファイル群が多く、間違いが見つけにくいこともある」ことでしょう。
そういう意見をどこかで見たことがあります。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

一般的に完全なソフトはない　linux / ububtu / bind / apache しかり。
それぞれをもし完全にマスターしたとして、それぞれを完璧に設定できたとしても、
全体の動きが完全に動くとは限りません。 ましてや人的なミスも重なります。
という認識は私も当然もっています。だからサーバ運用するなら特に慎重にしなければなりません。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

だから私はセキュリティには特に気を配りたいわけです。
だからここで改めて質問させてもらっています。
私は危なっかしい質問をするかもしれませんが、そのまますぐにそれを実行するかと言うと、
「サーバに関しては私は行動として、それは無い」ということをご理解いただきたい。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

さて、セキュリティの件が気になっている私は、先日、どうしても分からなかった件でしたが
（外部にはまださらしてないですよ、ご安心ください）
一つ間違っていたことを見つけました。

それは、 /etc/bind 以下の１０個ほどの設定ファイルの一部に間違った設定があったことです。
Serial の項目の数値が間違っていたことです。
例えば通常というかおすすめにはは、　yyyymmddooの形式（例で言えば　2010081600） とかです。
私もそれに習ってdateを入れました。というか正しくいれたつもりでした。
しかしそこに　yyymmddoomm としたファイルが複数あったことを思い出しました。
途中から直してありましたが、これは問題の一つであることは間違いない。
というのは以前から修正して更新したつもりでも、どうも更新がされていない挙動をしたからです。

これを私は早とちりしたのかもしれません。
「設定ファイルがたくさんあることによるそれらの相互間のなんらかの加減で誤動作をしているのかも
、だから言うことを聞かないのかも」と感じたのです。

セキュリティ重視思考なので　シンプルな設定ファイルnamed.conf だけにしたらどうかなと考えたわけです。
しかしそうすると想像もつかない問題点が潜んでいるのかもと慎重に考えている。
そこでこうしてお尋ねしているわけです。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

これからの対策と修正作業としては、
最初にその serial　の数値を電卓で足して入れ直しをしてdns の設定をリセットするつもりです。
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

そういえば
/etc/bind 内をシンプルにして、試しましたがその設定にならない、思い通りにならなかったわけです。
これは私のミスです。
しかし「１ファイルより数多くの設定ファイルがあれば、より間違えやすい」ことは間違いありません。
（度々、書きますが特に基本はセキュリティを考えています。それを前提として質問しています）


セキュリティを重要視していることはご理解いただきましたでしょうか？

そこで、改めて質問です。
-----------------------------------------------
・最新の linux を使用する　かつ

・最新の bind9 を使用する　かつ

・ option acl  view  など近代的なコマンドを使わずに かつ

・named.conf を下記のごとく分割せず

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

（念のため書きますが　古いbind ではない）　　かつ

・極力 「named.conf ひとつ」だけの設定ファイルにする。　

・smtp は1台、内部の特定の端末のみ数台限定（個人使用）

・apache2は最新で、一台ですがこれを２台にしたいなということろ
セキュリティを考えてテスト的な内部運用からスタートします。
（度々、書きますが特に基本はセキュリティを考えています。それを前提として質問しています）

・ドメイン一つ
--------------------------------
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

というところですが、

こういった条件ですと、危険でしょうか？
「bind9が新しい」場合に【「伝統的な形式の設定コマンド」を使った】ならば、危ないでしょうか？
それとも、それなら問題ない　でしょうか？
私は問題はなさそうだと考えています。
linux + Fedora + bind9 + apache2 なら　OK
linux + Debian + bind9 + apache2 なら　OK
linux + slachware + bind9 + apache2 なら　OK
linux + Redhat + bind9 + apache2 なら　OK
　でも
linux + UBUNTU + bind9 + apache2 は　だめなのかもしれない

だから質問しているわけです。
もちろん設定ミスは除くです。

（最後にも書きますが、特に基本はセキュリティを考えています。それを前提として質問しています）

よろしくお願いします。

hotohoto さんの投稿 (#11):

そこで、改めて質問です。
-----------------------------------------------
・最新の linux を使用する　かつ

・最新の bind9 を使用する　かつ

・ option acl  view  など近代的なコマンドを使わずに かつ

・named.conf を下記のごとく分割せず

コード:

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

（念のため書きますが　古いbind ではない）　　かつ

・極力 「named.conf ひとつ」だけの設定ファイルにする。　

・smtp は1台、内部の特定の端末のみ数台限定（個人使用）

・apache2は最新で、一台ですがこれを２台にしたいなということろ
セキュリティを考えてテスト的な内部運用からスタートします。
（度々、書きますが特に基本はセキュリティを考えています。それを前提として質問しています）

・ドメイン一つ
--------------------------------
(セキュリティ第一)(サービスはいつでも止めらる)(モニターは手元にある)(攻撃された記憶は鮮明)

というところですが、

こういった条件ですと、危険でしょうか？
「bind9が新しい」場合に【「伝統的な形式の設定コマンド」を使った】ならば、危ないでしょうか？
それとも、それなら問題ない　でしょうか？

危険です
理由は「option acl view など近代的なコマンドを使わず」にあります

最近の有名な DNS の不正アクセスについて調べれば、すぐに分かるはずです
そのような事項を調べもせずに「セキュリティ重視思考」とか「攻撃された記憶は鮮明」とか言われても、絵空事にしか聞こえません

hotohoto さんの投稿 (#14):

ryさんのおっしゃる
「最小の構成で、bind が読み込む設定ファイルは named.conf ただ一つ」
というところと
「近代的なコマンドを使うべき」
とは矛盾しませんか？

全く以て矛盾しません

セキュリティを高めるために「近代的なコマンド」を使うべきであり、現時点の BIND9 では「近代的なコマンド」を使うか、OS やネットワーク環境を適切に設定するのどちらかをせずにセキュリティを高めることはできません

コマンドがいくつあっても、全てを使うことは希であり、実際に使うのは限られた数だけでしかありません
「近代的なコマンド」もこれと同じで、その全てを使わなくてはいけないなどということではありません