【DNSサーバ構築・管理の難易度?】


素人考えなのですが、様々なサーバの構築・管理の難易度を比較した場合、メールやWebは難しく、DNSは易しいような印象を受けます。これはあくまで自分でやったわけではなく、書籍を読んでの感想です。

ところが、まわりのネットワークに詳しい人に聞くと、DNSサーバが一番奥深いとのことです。決められた手順を進めれば、DNSサーバは立てられるような気がするのですが、なぜこのような意見がでてくるのでしょうか? 教えてください。

回答の条件
  • 1人3回まで
  • 登録:2008/12/10 19:47:17
  • 終了:2008/12/14 13:50:58

回答(9件)

id:pahoo No.1

pahoo回答回数5960ベストアンサー獲得回数6332008/12/10 20:01:03

ポイント16pt

構築は簡単だが、運用・管理には注意が必要だということでしょうか。


そもそも、Webサーバ、メールサーバ、DNSは各々性質が異なるサーバですので、一概に簡単だとか難しいとかいった比較はできません。また、それらのサーバにぶら下がるクライアントの台数によっても、構築から運用までの手間が変わってきます。


極端な話、世界中に13台しかないルートDNSサーバが止まったら、インターネットは大混乱に陥ります。

一方で、ルートDNSに対するクエリーの99%は無意味という調査もあります。これだけの無意味なトラフィックを裁き、24時間365日ノンストップで運用するというのは、並大抵の努力でできるものではありません。


ルートDNSとまでいかないにせよ、そのDNSがどの位の規模のネットワークを支えているかによって、運用の大変さは変わってきます。

id:witt

回答ありがとうございます。下のコメントを参照ください。

2008/12/10 21:46:32
id:ymlab No.2

ymlab回答回数506ベストアンサー獲得回数332008/12/10 20:32:06

ポイント16pt

私は、SMTP,POPサーバとHTTPサーバを構築していますが、DNSは構築していませんので、

正しい回答でないかもしれませんが・・・。


DNSサーバは、たとえばアクセスが大きくなってくると、

ラウンドロビンなど、高負荷に対する手法など、

チューニングのしがいがあるからではないですか?[もちろん、高負荷対策はほかのサーバも同様に重要です。]

id:witt さんが、簡単と思うのも事実。

ほかの詳しい人が奥が深いと思うのも事実だと

思います。

ただ、ほかのサーバと、比べて最初の敷居が低いのではないでしょうか?

奥の深さでいえば、どれも同じようにおくが深いような気が個人的にはしますよ^^;

id:witt

回答ありがとうございます。下のコメントを参照ください。

2008/12/10 21:46:35
id:infograve No.3

Infograve回答回数47ベストアンサー獲得回数22008/12/10 20:38:41

ポイント16pt

どのサーバーも難しいと思っているレベルでの戯言ですが、


・DNSサーバーには、今の所サーバー間での認証・暗号化ができていません。(ゾーン転送・動的更新除く)

・他のサーバーに比べて資料が少ない

等があげられると思います。


また、設定も人によって方針が違うので、主に設定・運用面で問題が出ることが多いです。


使い方によっては負荷分散や、一時的な障害対応を行えたり、

どの本で学んだか、どういったネットワーク設計を目指すのかで設定ファイルの組み方が変わってきますので、

奥が深いと言われるのかもしれないですね。

id:witt

回答ありがとうございます。下のコメントを参照ください。

2008/12/10 21:46:41
id:hijk05 No.4

hijk05回答回数1307ベストアンサー獲得回数232008/12/10 22:36:44

ポイント16pt

http://www.atmarkit.co.jp/fnetwork/rensai/tcp06/01.html

このあたりじゃないでしょうか?

id:witt

なるほど。分散協調システムってところが、他のサービスと基本的に違うところですね。

2008/12/10 22:55:44
id:b-wind No.5

b-wind回答回数3344ベストアンサー獲得回数4402008/12/11 00:14:18

ポイント25pt

経験上、DNSは「設定が間違っていてもそれなりに動いてしまう」あたりが一番やっかい。

しかも、クライアント側でもデータのキャッシュを持っていたりで、問題発覚が遅れやすい。


他のサーバーはたいてい「期待したとおりに動く」か「期待したとおりには動かない」の二択で済むので

確認が楽だが、DNSは「ある程度期待通りだけど副作用がある」といった状態もあり得るので

正確に理解していないとトラブルシューティングが出来ない。

つーか正確にわかっている人なんてあんまりいない。

@IT:DNS Tips:「ゾーンがLame」ってどういう意味?


それでいて名前解決は現在の Internet においては Web,Mail をはじめとするすべてのサービスの

起点になるので重要性は非常に高い。

プロトコルレベルになるともっと細かい挙動の違いなんかがあるけど、それを言い出すと書ききれないのでこの辺で。


「奥が深い」という表現か適切かどうかはわからないけど、

決められた手順を進めれば、DNSサーバは立てられる

ってのはとんだ勘違いだと思う。

id:witt

経験上、DNSは「設定が間違っていてもそれなりに動いてしまう」あたりが一番やっかい。

しかも、クライアント側でもデータのキャッシュを持っていたりで、問題発覚が遅れやすい。

これは説得力のありますね。DNSの難しさが見えてきたような気がします。

2008/12/13 12:47:51
id:goodvn No.6

goodvn回答回数228ベストアンサー獲得回数182008/12/11 04:18:05

ポイント25pt

私はネットワーク屋ですが,Apache やメイルの設定は慣れてしまえばとてもカンタンですし,トラブルなどの対応も考えた,運用まで入れても,ノウハウの有無で左右されるかもしれないけど,致命的ダウンが続くような運用はあまり想定できません(そんな致命的ダウンの経験もありません)

サーバを専門に取り扱う場合,いわゆる動かすまでのセットアップ,というのは比較するほどカンタン,難しい,というものはなく,基本的に全部カンタンです

アマチュアの方からすると,「動かすまで調べて,聞いて,一苦労だよ」と言われそうですが,自動車のプロの運転手が,セダンを動かすも,バスを動かすも,大して苦にしないのと同じようなものでしょう

さて,DNS ですが,まあ,bind だとして,これを動かす最低限の設定自体は,慣れた人なら,5分も掛からずサービスを上げられるでしょう

しかし,DNS には,冗長化のための分散構成や,キャッシングという要素が絡んできます.Apache やメイルは,全てのトラフィックが自分の設定したサーバに来るのですが,DNS の場合,設定情報があちらこちらの,自分の管理しないサーバまで伝播してしまい,そしてその情報を制御する事はできません

例えば,あるホスト名の Aレコードを変更しようとします.まず,プライマリDNS の設定を書き換えます.しかし,その情報がセカンダリDNS以降に反映されるには,設定の同期を待たないといけません

そして,インターネットに居る他のクライアントが,変更された情報を使うようになるには,世界中のキャッシュサーバに残ったキャッシュの情報が入れ替わるのを待たないといけません

また,ご自身が管理する DNS が使われるのはなぜか,というと,ルートサーバから辿る,DNS の分散構成を経てくるのです.上位の DNS の NSレコードをに,ご自身の管理される DNS の情報があるからこそ,ご自身の管理する DNS へたどり着けるのです

つまり,DNS の設定は自分だけで全て制御できず,こうした上位の DNS を管理する方との連携なども必要になってきます(独自ドメイン名の設定で,レジストラに Nameserver の登録をお願いすると思いますが,これはレジストリが管理する,そのドメイン名(例えば .jp)の DNS の変更作業をお願いすることです)

また,例えば bind では, NS レコードに CNAME を書いても動くと思います.しかし,これはマズい設定なんですね

設定が難しいというより,この辺りの運用の面で,Apache などと違うノウハウが必要とされますので,そういう意味で,奥が深い,と言われたのかもしれません

id:witt

詳しい説明ありがとうございます。

おかげで、こういう仕組みだと、トラブルが起こったとき、対処がたいへんそうというのはわかってきました。

2008/12/13 12:52:03
id:JULY No.7

JULY回答回数966ベストアンサー獲得回数2472008/12/11 12:29:31

ポイント20pt

自分で DNS をいじるようになったときに、感銘を受けた(っていう表現はちょっと変かもしれませんが)のは、逆引きの仕組み、特にネットマスク長が 24 bit 超のケース(俗に、クラスC未満のケース)でした。

@IT:キャッシュ/逆引きDNSの構築と運用(2/2)

DNS の動作原理には、実は、正引き、逆引きという厳密な区別があるわけでなく、ある「名称」に対して、その名称に関連付けられた、ある「種類」のデータを返す、となっているに過ぎません。192.168.1.1 という IP アドレスの逆引きをするときに、

  • IP アドレスをドットの区切りで反対にして、
  • その後ろに「.in-addr.arpa」というのをくっつけた「名称」に対して、
  • PTR という「種類」のデータを取得する。

という「お約束」を作っただけで、正引き用の仕組みと、逆引き用の仕組みに根本的な違いがありません。

で、上記の「お約束」だと、例えば ISP から 16 個(うち、利用できるのは 14 個)の IP アドレスの割り当てを受けているときに、割り当てを受けた側で DNS の情報(ゾーン情報)を管理したい、とした時に、あくまでも DNS はドットのある位置でしか区切れないので、16 個の IP アドレスのだけを管理するゾーンというのは作れない。

でも、動作原理はあくまでも「名称」と関連付けられる「ある種のデータ」だから、

  • 18.1.168.192.in-addr.arpa には CNAME をつけて、「18.1.168.192.in-addr.arpa の本当の名称は 18.16.1.168.192.in-addra.arpa って言うんだよ」という情報を ISP 側の DNS サーバで用意する。
  • IP を割り当てれた側は、16.1.168.192.in-addr.arpa というゾーンに対して管理するように DNS サーバをつくり、そのゾーン情報の中で「18.16.1.168.192.in-addr.arp の PTR は www.example.jp だよ」とする。

といった具合に、2つの DNS サーバの連携で、「DNS の仕組みを変えず」に対応できてしまう。この仕組みが分かったときは感動しました。

他の方も書かれていますが、DNS の場合は、個々のサーバ持つ機能はたかが知れているんだけど、内容次第で他の DNS サーバと連携して、全体としてうまく行くように出来ている、というところが、「奥深さ」じゃないでしょうか。つまり、「サーバ単体」としてではなく、「DNS」という仕組みの持つ奥深さなのだと思います。

id:witt

勉強不足ゆえに、逆引きの仕組みが、シンプルで美しいものなのか、

レガシーな仕様を引きずっているが故の苦肉の策(いわゆるバッドノウハウ)のなのか、

わからないんですが、どっちなんでしょう?

それはそれとして、分散協調システムとしての奥深さというのは、答えの一つなんでしょうね。

2008/12/13 13:01:07
id:pinkymonk No.8

pinkymonk回答回数172ベストアンサー獲得回数142008/12/11 13:20:37

ポイント20pt

DNSは単純に、

DNSは、FQDNをIPアドレスに変換するもの。

という認識だけでいいのではないでしょうか。


仕組みは簡単で単純かもしれませんが、

世界感や想定している規模を考えればDNSがTCP/IPと同じぐらい大きい。

というだけです。

MailやWEBはあくまで自分本位な世界感しかもってませんので、

規模間的には小さいと考えます。

それに、その詳しい方はDNSの運営や設定でなにかwebやmailのサーバーとは

別の苦労をされたのでしょう。

苦労して乗り越えればサーバーに対しても愛着がわいてくるものです。



DNSの勉強なんてしなくていいと思いますよ。

DNSサーバー構築の仕組みは単純なのでこうやって設定すれば、DNSはつながる。

それ以上でもそれ以下でもありません。

id:v99 No.9

v99回答回数35ベストアンサー獲得回数42008/12/14 12:45:21

ポイント19pt

「奥が深い」というのはDNSは世界的な分散データベースだから、ということだと思います。

そのデータベースに参加しデータを世界中に反映させるのに少なからず時間がかかるという要素もあり、他のサーバーソフトとは違った特性を持っています。

またドメイン名を取得しDNSに設定するという事務的な要素も加わり単に技術的な側面だけでDNSは語れません。

もう少し付け加えるとIPアドレスからの逆引き設定は順引きとは全く別のアプローチになるので初心者には理解しにくいという点も見逃せないかもしれません。

  • id:witt
    2008-12-10 21:45現在、私が聞いたネットワークに詳しい人の意見を補強するような回答はないようです。
    逆に、否定してもらってもよいです。その方がすんなりと納得できます。
    私が知りたいのは、私が不勉強ゆえに、DNSサーバのことがわかってないのか、
    それとも、私の認識はそこそこ正しいのか。
    人の意見を組みすぎて、必要以上にDNSの勉強に時間を割きたくはないからです。

    ケースバイケース的な意見がありますが、それを言い出したら、議題になりません。
    例を挙げると、一般的に、エンドユーザにとって、LinuxよりWindowsの方が使いやすいはず。
    人によるといいだしたら、きりがありません。そういう前提での質問です。

    やはり、私はDNSよりメールやWebの方が設定項目が多く、それに係る難解な概念もあいまって
    難しいと思うんですけどね。
  • id:infograve
    不勉強かどうかは、どのぐらいの作業能力を目指しているかによるので何とも言えませんが。


    サーバー50台程度のプロバイダ向けDNSの設計・運用をされるのであれば、
    DNS関連のRFC、オライリーの「DNS&BIND」、同じく「DNS&BINDクックブック」辺りは読んでおいて損は無いと思います。


    上記辺りを目指しているという前提で逆引きについて話をします。


    管理用・サーバー用には細かいPTRを、インターネットからの問い合わせにはそれなりのPTRを返したほうが、
    セキュリティ上好ましい(特に地域名等はインターネット上からは秘匿すべき)と私は思っています。


    たとえば、管理用としてはdhcp001.tokyo01.jp.example.comを返す事によって、東京第1DHCPサーバの1番目のアドレスであると信頼するサーバーのログレコードからは読み取れるべきです。管理が楽ですから。
    しかし、インターネットからの問い合わせにはuser0010101.example.comを返す事によって、一見しただけでは何処の、どのサーバの物か分からないようにという訳です。


    当然ながら、こんなことは必要ないdhcp001.tokyo01.jp.example.comを返せばいいとしている人もいますが、
    ネット上での詐欺にPTRの内容書かれた時に地域名ついてたら客ビビりますからね。

    そもそもPTRを返さない人もいますがこれは連絡のつけようがなくなるので、論外だと思います。

    まとめて同じPTRレコード。たとえば、dhcpuser.example.com を返すべきだという人もいますが、
    これだと問い合わせに対処しづらいんですよね。
    特に警察が乗り込んできたときとか、IPじゃなくdhcpuser.example.comと書かれてるログ持ってきてぎゃぁぎゃぁ喚く時があるので。


    といった経験則から、IPアドレスでPTRの返答を変えたほうが良いと思うんですよね。
    ZONEファイル更新する際には2つセットでいじんないといけませんけど。


    と、まぁPTRに何書くかだけでここまで話ができるんですからそんなに簡単なものでも無いです。
  • id:pahoo
    witt > ケースバイケース的な意見がありますが、それを言い出したら、議題になりません。

    それは間違っています。
    技術的に難しいかどうかを検討するには、かならず前提条件が必要です。

    「エンドユーザにとってLinuxよりWindowsの方が使いやすい」という論は、意味がありません。
    Linuxには様々なディストリビューションがあり、GUIの差し替えも用意です。中には、MacOS X の GUIである Aqua をテーマとして持つことができるものもあります。
    一般的に MacOS X のインターフェースは Windows のそれより使いやすいと言われています。よって、Aqua をテーマとして持つ Linux と Aero(WindowsVusta の GUI)を比べた場合、単純に Aero の方が使いやすいという結論にはならないでしょう。

    また、DNS は、ネットワークを構成する要素の1つですから、他のネットワーク構成要素との相互作用は避けて通れない問題です。その前提条件を規定せずに、構築・管理の難易度の議論をすることは無意味だと考えます。
  • id:witt
    >infograve

    現場からの意見ありがとうございます。
    やはり、DNSは世界が閉じてないという点が難しそうですね。
  • id:JULY
    > 逆引きの仕組みが、シンプルで美しいものなのか、
    > レガシーな仕様を引きずっているが故の苦肉の策
    >(いわゆるバッドノウハウ)のなのか、
    > わからないんですが、どっちなんでしょう?

    う~ん、どっちだろう(^^;。

    全体としては、「シンプルであるが故の懐の深さ」という感じがありますが、でも、例のクラス C 未満の話は「苦肉の策」という気がしますね。

    確かに「レガシーな仕様」がちょっと目立ってきたのは事実ですね。オプションはあるものの UDP:512 バイトにパケットサイズが制限されている点とか、クエリーID が 16 bit 整数であることが、セキュリティ上の問題になったり。

    インターネットの屋台骨を支える仕組みで、しかも、各サーバが連携して成り立っているものだから、問題があっても簡単には変えられない、という側面はありますね。
  • id:b-wind
    > レガシーな仕様を引きずっているが故の苦肉の策

    > 全体としては、「シンプルであるが故の懐の深さ」という感じがありますが

    たぶん感じたとおり両方の面があるのだと思う。
    「シンプルであるが故」という点では SPF の実装などおもしろいところだと思う。
    DNS だけでも MTA だけでも完結しない。
    http://ja.wikipedia.org/wiki/Sender_Policy_Framework
  • id:witt
    >JULY
    >b-wind

    コメントありがとうございます。
    すでに、私の理解を超える話となっておりますが(^^;
    現実はそんなにシンプルになれないんでしょうね。

    バッドノウハウのことを「奥深い」というつもりはさらさらないわけですが、
    それを差し引いても、奥深い世界がそこにあるのは間違いなさそうです。
  • id:goodvn
    >>
    各サーバが連携して成り立っているものだから、問題があっても簡単には変えられない、という側面はありますね。
    <<

    昔のことを思い出してみると,かつて電子メイルは 7bit ascii しか取り扱えず,サブジェクトに日本語を書こうものなら怒られたものです

    しかし今では 8bit どころか,文字コードすら UTF-8 を使うことも,珍しくなくなりました

    不正リレーの問題,送信者認証,いろいろ改善されてきました

    元の規格ではうまくいかないものは,新しい規格が提案され,ソフトウェアの実装があり,切磋琢磨があったものと思います

    DNS だって同様の変化はできたのかもしれませんが,レガシーな仕組みを引っ張ってる面は否めませんよね

    tinydns といった提案もありましたが,やはりほぼ BIND しか選択肢が無いのも,改善が進まない原因かもしれませんね

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません