トップページ⇒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/
0442名無しさん＠お腹いっぱい。2010/11/27(土) 17:31:50
>>441
慌てる必要はないよ。必要になったらやればいい。
0443名無しさん＠お腹いっぱい。2010/12/02(木) 00:57:02
眺めている段階
0444名無しさん＠お腹いっぱい。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
0445名無しさん＠お腹いっぱい。2010/12/02(木) 16:37:31
http://ya.maya.st/d/201012a.html#s20101201_1
CNAME の間違った使い方

>>394-397
0446名無しさん＠お腹いっぱい。2010/12/02(木) 16:55:57
http://blog.livedoor.jp/techblog/archives/65340720.html
> ライブドアドメインではこれまでdjbdnsを使用していましたが、
> 今年の11月1日にNSDというソフトウェアにリニューアルしまして、
> 新機能と同時にこのCNAME問題に対応しました。

やっと対応したって事かな。
0447名無しさん＠お腹いっぱい。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
0448名無しさん＠お腹いっぱい。2010/12/03(金) 10:35:56
/etc/hosts に localhost がなかったり、
あっても hosts を参照せずいきなり DNS に聞く実装でも、
resolv.conf に search livedoor.jp と書いてあれば
localhost を問い合わせても 127.0.0.1 がちゃんと返ってくる。

……というメリットはあるけど、たいしたメリットでもないので
消してもいいと思う。
0449名無しさん＠お腹いっぱい。2010/12/03(金) 10:59:18
デメリットを聞いてるんだが
0450名無しさん＠お腹いっぱい。2010/12/03(金) 11:20:17
だからそういう環境で localhost の名前解決ができなくなるんだってば。

FQDN じゃなかったら勝手にドメイン名を補完してしまうものもあるので、
localhost. のゾーンを作っておけば済むという話じゃないんだな。
0451名無しさん＠お腹いっぱい。2010/12/03(金) 19:53:34
searchオプションの恩恵うける場面てそんなに多いのかな？
外の人にとっては意味ないし、中の人にしたってプログラムがsearch依存で名前解決するのも気持ち悪いだろうし。
0452名無しさん＠お腹いっぱい。2010/12/03(金) 20:19:29
>だからそういう環境で localhost の名前解決ができなくなるんだってば。

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

それならば削除する必要はないですね。
0453名無しさん＠お腹いっぱい。2010/12/03(金) 21:18:51
>>452は>>447のリンク先を日本語で解説してくれる人を釣ろうとしてるの？
0454名無しさん＠お腹いっぱい。2010/12/03(金) 21:22:34
なるほど！
0455名無しさん＠お腹いっぱい。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のような広く知られたものがあれば後半だけでいい。

こんなとこ？
0456名無しさん＠お腹いっぱい。2010/12/05(日) 13:02:44
あとはNXDOMAIN連発とか？
0457名無しさん＠お腹いっぱい。2010/12/06(月) 00:59:34
こういうの一度書いちゃうとなかなか消せないんだよね。
副作用が怖くて。
0458名無しさん＠お腹いっぱい。2010/12/06(月) 09:19:43
なくなって困るのは中の人くらいじゃないの？
中からの問い合わせからだけ名前解決するんじゃだめなん？
0459名無しさん＠お腹いっぱい。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
0460名無しさん＠お腹いっぱい。2010/12/07(火) 03:47:54
Wikileaksをホスティングしていることでもおなじみの信頼と実績だな
0461名無しさん＠お腹いっぱい。2010/12/07(火) 08:07:03
アタックされたから追放したんじゃなかったのか
0462名無しさん＠お腹いっぱい。2010/12/10(金) 00:21:00
>>459
まだこんな馬鹿がいるのか
0463名無しさん＠お腹いっぱい。2010/12/10(金) 21:27:40
>>459
-DDoSを喰らったときの課金のありよう
-名前参照が終わるまで多段*4の参照が発生する
等を考えると若干首を傾げる。
Amazonにしては詰めの甘さを感じずにいられない。

Amazonがわのメンテナンスの都合でネームサーバのIPアドレスを
任意につけかえられるように設計するとこうなるのはわかるけれど。
0464名無しさん＠お腹いっぱい。2011/01/07(金) 02:19:48
2010年はBIND9の脆弱性が多くて嫌になった
でもUnboundとかnsdに移行する勇気がないヘタレ
0465名無しさん＠お腹いっぱい。2011/01/07(金) 10:07:11
数としてはたしかに多かったけど、dnssec を有効にしてなければ
放置しても問題ないものがほとんどだった気が。
dnssec はまだ本格的に使われてないからコードが枯れてないんだよね。
とはいえ、nsd/unbound は問題を起こしてないからそれを言い訳にはできないけど。
0466名無しさん＠お腹いっぱい。2011/01/07(金) 10:11:13
見つかってないだけかも。
0467名無しさん＠お腹いっぱい。2011/01/07(金) 16:09:39
Unboundはキャッシュとして使う限りはBIND9と遜色ない
機能はあると思う。DNSSEC validatorとしては最新の仕様に
追従してるし、ローカルデータもフォワーディングゾーンも設定できる。
Unboundに無い機能ってviewくらい？
0468名無しさん＠お腹いっぱい。2011/01/07(金) 21:21:11
>>467
Unboundはラウンドロビンを無視してTTLが切れるまで常に同じアドレスを返す
というちょっと切ない仕様があったけどアレはその後どうなったのかな
0469名無しさん＠お腹いっぱい。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
0470名無しさん＠お腹いっぱい。2011/01/07(金) 22:17:59
権威サーバから得たデータは変にいじらずにそのまま
クライアントに返すべきだ、DNSの仕様にもラウンドロビンなんて
定義されてない、というのがUnbound側としての立場だったはず。

とはいえ、ラウンドロビンは必要な機能なんだろうなぁ
Windows Vista は複数Aレコードを得ると
RFC 3484 Rule 9 にしたがって特定のIPを選択
するのでラウンドロビンが効かないんだけど、
Win7 はラウンドロビンが効くように変更されたりしてるし
0471名無しさん＠お腹いっぱい。2011/01/07(金) 22:21:23
UNIXの getaddrinfo()もラウンドロビンが効くように変更してください！
0472名無しさん＠お腹いっぱい。2011/01/14(金) 01:17:03
BSDやglibc派生のスマフォンは
DNSラウンドロビン的にどう動くんだろ？
0473anonymous2011/01/18(火) 23:57:00
いよいよjpドメインでもDNSSEC使えるようになりましたが、
おまえらDNSSEC使いますか？
0474名無しさん＠お腹いっぱい。2011/01/19(水) 18:03:47
いやべつに
0475名無しさん＠お腹いっぱい。2011/01/19(水) 19:35:29
そのうち対応しないととは思っているが検証が面倒くさい
今のところキャッシュDNS鯖の負荷が無駄にあがってるだけだな
0476anonymous2011/01/19(水) 19:56:58
DNSSECは効果の割に苦労が大きすぎるから普及は難しいんじゃないか
キャッシュはともかく、権威サーバの運用がとっても面倒だからなー

だいたいDNSSECなしのDNSだってちゃんと運用できてねーし
DNSSECがまともに運用できるとはおもえない
0477名無しさん＠お腹いっぱい。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 みたいにすれば、署名の連鎖とか考えなくてすむんだけどどうでしょう。
0478anonymous2011/01/19(水) 20:35:41
とりあえずはTXIDを128ビットとかに
増やすだけでよかったんじゃね
source port randomizationや0x20のやってることの本質は
それだし
0479名無しさん＠お腹いっぱい。2011/01/19(水) 20:54:39
>>477
それをやると証明書屋さんばっかり儲かっちゃうのよね。
SSL って netscape の独自規格が元になってるので、
政治的な話とは無関係に仕様が決まっちゃったけど、
インターネットのガバナンスってそういう特定の誰かに
集中/依存する仕組みを嫌うんだよね。

そうはいってもすべてを分散管理できる仕組みなんて作れないので、
IANA とか ICANN とかの組織にそういうのまかせるようにしてあるんだけど、
それでもなお不満がある人も多いわけで。
これが営利の私企業だったらどうなっていたことか、と。
SSL 証明書ってインターネットにおいては営利企業が牛耳ってる数少ない例外なんですよ。
0480名無しさん＠お腹いっぱい。2011/01/19(水) 21:16:02
>>476
DNSSEC は付け焼き刃の勉強ではすぐにボロが出て失敗するので、
よほど自信あるかよほどの物好きでなければはじめから手を出さない方がいい。
概要だけ理解して、必要だと思えば信頼できる業者にアウトソースする、
つまり手間はかけずに金をかけるのが正しい道だと思う。

もっとも、信頼できる業者がどれだけ存在するのかはなはだ疑問ではあるが。
0481名無しさん＠お腹いっぱい。2011/01/19(水) 21:22:08
>>479
PKIの維持ってコストがかかるから儲からないとやってられんでしょう
DNSSECのコストをエンドユーザに転嫁しないモデルで、
本当にやっていけるのかねぇ
0482名無しさん＠お腹いっぱい。2011/01/20(木) 12:24:39
下のはフィッシング用？のコピーサイトなんだけど
正引きしても本家のウォルマートのIP返す

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

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

http://walmart.f8f8.us/
0483名無しさん＠お腹いっぱい。2011/01/22(土) 16:11:45
http://www.google.co.jp/search?q=site:arpa

arpaにAレコード作ると何か便利なことでもあるの？
0484名無しさん＠お腹いっぱい。2011/01/22(土) 23:02:12
ただの設定ミスのような気がする
0485名無しさん＠お腹いっぱい。2011/01/23(日) 17:27:29
walldnsみたいなことができる。
0486名無しさん＠お腹いっぱい。2011/01/24(月) 07:58:25
ネームサーバがin-bailiwickにできるから、逆引きにかかる手間が減ったりする
0487名無しさん＠お腹いっぱい。2011/01/24(月) 21:45:56
なるほど、わからん。
0488名無しさん＠お腹いっぱい。2011/01/24(月) 23:52:17
http://www.e-ontap.com/internet/nagoya-u/img46.html
に書いてある、コンテンツサーバがキャッシュサーバを兼ねていると
DDos に弱い、ということについて質問です。

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

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

上記の資料では、DNS への DDos 攻撃はキャッシュサーバへ行われることが多い
という前提がある?
0489名無しさん＠お腹いっぱい。2011/01/25(火) 01:23:06
キャッシュサーバの足回りは動的IPで済む
コンテンツサーバはどうしても固定IPでないと運営が辛い
0490名無しさん＠お腹いっぱい。2011/01/25(火) 08:32:08
djb教の教えが微妙に混ざっていると思う。経典にあたれば考えがわかると思うよ。
04914882011/01/25(火) 10:04:09
>>489-490
レスどうもありがとうございます。
教典とは以下のことでしょうか?
http://djbdns.qmail.jp/djbdns/separation.html
ここに書いてあることは感覚的には納得がいきます。

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

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

こんな感じでしょうか。
0492名無しさん＠お腹いっぱい。2011/01/25(火) 10:24:35
DDoS 攻撃を受ける、というよりも、
DDos 攻撃の踏み台に使われることがあるんでやめた方がいい。
# 詳細は dns amp でぐぐれ

allow-recursive で再帰検索の acl をかければ防げるけど、
権威サーバと共用してるようなところではどうせそんなことしてないだろう。
04934882011/01/25(火) 10:43:30
>>492
dns amp でググってヒットした記事をいくつか読みました。
なるほど、自分で管理しているDNSサーバのレスポンスよりも、
誰でも使えてしまうキャッシュサーバをインターネット上に置いてしまうことが問題ですね。
(http での open proxy を、インターネット上に置くな、というのと同じか)。

どうもありがとうございました。
0494名無しさん＠お腹いっぱい。2011/01/26(水) 00:18:44
そろそろBINDも再帰検索受付不可をデフォルトとして
ACL書いた先だけ可能にするという設定になっていいと思うんだよな
9.8あたりでそうしていただきたい
0495名無しさん＠お腹いっぱい。2011/01/26(水) 01:16:06
>>494
9.4.あたりからそうなってますが。
allow-queryなどのオプションと連動するので中途半端に設定してると意味がないですが。
0496名無しさん＠お腹いっぱい。2011/01/28(金) 00:10:26
BIND9 のクエリ制限の設定って
allow-query
allow-query-cache
allow-recursion
っていう3つの項目あるけど、この3つの相互作用は
とても分かりづらいよね
9.7.2-P2のallow-queryが効かないバグとか見てると開発者さえ
理解してるか怪しいんじゃないか
0497名無しさん＠お腹いっぱい。2011/01/28(金) 00:37:41
セキュリティホールもいつになっても止まらないし、
もう BIND の時代は終わりだと思う

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

MyDNS、maraDNS ってどうなの？
0498名無しさん＠お腹いっぱい。2011/01/28(金) 01:28:35
>>497
そこで、BIND X・・・じゃなくてBIND 10ですよ。
0499名無しさん＠お腹いっぱい。2011/01/28(金) 02:18:20
売店
0500名無しさん＠お腹いっぱい。2011/01/30(日) 21:44:27
PowerDNSは?
0501名無しさん＠お腹いっぱい。2011/01/30(日) 22:41:55
え?
0502名無しさん＠お腹いっぱい。2011/01/31(月) 14:00:59
え?
0503名無しさん＠お腹いっぱい。2011/02/02(水) 21:13:27
>>500
フルリゾルバの PowerDNS recursor は2年くらい前から使っているが問題なく動いている
hosts に書いた情報も一緒に混ぜてクライアントに返してくれる機能がなにげに便利

ゾーンサーバ側(PowerDNS Authoritative Server)は使ってないのでわからん

DNSSEC関係については、ゾーンサーバ側が試験中、フルリゾルバ側はまだ


0504名無しさん＠お腹いっぱい。2011/02/04(金) 03:37:28
PowerDNSよさげだなぁ
いまさらながら評価してみるか
0505名無しさん＠お腹いっぱい。2011/03/04(金) 13:06:12.13
運用方法について聞きたいんだけど、
例えば2台のDNS(dns1とdns2)と、2台のwwwサーバ(www1とwww2)を用意して、
dns1に問い合わせが来たときはwww1を返す
dns2に問い合わせが来たときはwww2を返す
ということは普通にやってもいいことですか。
0506名無しさん＠お腹いっぱい。2011/03/04(金) 13:30:44.57
dns1はwww IN CNAME www1
dns2はwww IN CNAME www2
みたいに。
0507名無しさん＠お腹いっぱい。2011/03/04(金) 14:01:55.88
>>505
普通はやらない。
0508名無しさん＠お腹いっぱい。2011/03/04(金) 14:05:57.46
>>505
普通にAレコード2つ書くんじゃだめなの？
0509名無しさん＠お腹いっぱい。2011/03/04(金) 14:20:42.81
>>505
負荷分散とリダンダント両立できないからやめとけ。
0510名無しさん＠お腹いっぱい。2011/03/04(金) 14:21:04.06
だな
両方のDNS鯖で

www IN CNAME www1
www IN CNAME www2

って書いとけばラウンドロビンする
0511名無しさん＠お腹いっぱい。2011/03/04(金) 14:59:11.03
CNAMEはさむ必要ないと思うけどな。
直接Aでいいじゃん。
0512名無しさん＠お腹いっぱい。2011/03/04(金) 15:39:33.87
DNSって鯖の死活なんて分からないよね？
仮にwww1が死んでもそのままアドレスは返すってことかな。
0513名無しさん＠お腹いっぱい。2011/03/04(金) 15:47:04.73
そうだよ。
0514名無しさん＠お腹いっぱい。2011/03/04(金) 18:52:10.35
名前解決するだけ
0515名無しさん＠お腹いっぱい。2011/03/04(金) 20:17:53.27
>>510
CNAMEの多重指定はRFC違反じゃ？
書くならAを2行書くべきだろう。

クライアントの地理情報によって返すアドレスを変えるという手法ならどこかの会社が特許取ってたな。
8.8.8.8とか使われるとアウトだが。
0516名無しさん＠お腹いっぱい。2011/03/04(金) 20:23:11.04
え、あれ特許なの？
どこの会社？
0517名無しさん＠お腹いっぱい。2011/03/04(金) 21:31:22.95
HTTP限定でいいならredirect使ってふりわけた方がいいと思う。
0518名無しさん＠お腹いっぱい。2011/03/05(土) 02:57:53.56
>>517
詳しく
0519名無しさん＠お腹いっぱい。2011/03/05(土) 08:23:05.12
DNSで負荷分散を解決するんじゃなくて、HTTPフロントエンドで解決するということだろう
0520名無しさん＠お腹いっぱい。2011/03/05(土) 18:15:55.95
webサーバを二重化したいのにそれをwebサーバにやらせてもしょうがなくね。
リダイレクタが落ちたら終わりじゃん。
0521名無しさん＠お腹いっぱい。2011/03/05(土) 18:56:09.72
ではリダイレクタも二重化するということで
0522名無しさん＠お腹いっぱい。2011/03/05(土) 19:00:32.90
大元の人の話は全然二重化の話じゃないんだけど
0523名無しさん＠お腹いっぱい。2011/03/05(土) 20:02:40.65
なら何がしたかったんだろう。
0524名無しさん＠お腹いっぱい。2011/03/05(土) 21:09:43.50
開発環境向け、イントラ向け、または、フィッシング詐欺
0525名無しさん＠お腹いっぱい。2011/03/06(日) 11:50:38.39
>>505
CNAMEじゃなくてAならやったことあるよ。
DNSラウンドロビンの負荷分散が効かないクライアント
向けに負荷分散したかったので（冗長性は別のしくみで確保）
CNAMEだとダメな理由は思いつかない

DNSラウンドロビン効かないクライアント向けに負荷分散して、
かつ冗長性を持たせたいなら、www1とwww2でDNSサーバ動かす
というテクニックもあるぞ
0526名無しさん＠お腹いっぱい。2011/03/07(月) 10:37:01.48
>CNAMEだとダメな理由は思いつかない

CNAMEは1個だけ、ってRFCに明記されてるから。
そうするとうまく動かないとかそういうことじゃなく。
0527名無しさん＠お腹いっぱい。2011/03/07(月) 11:08:15.00
DNSサーバそれぞれに1個だけ書くんでしょ。
05285052011/03/07(月) 12:47:08.59
dns1とwww1、dns2とwww2をそれぞれセットにして、
2台の仮想サーバーに入れようと考えたのですが、
片側の仮想がダウンしたときでも、この方法ならサービスが継続できるかと思いまして。
0529名無しさん＠お腹いっぱい。2011/03/07(月) 13:29:13.46
レコードがキャッシュされちゃってたら意味なくね？
それともダウンしたイベント契機とかでちゃんとシリアル上げるようにするの？
0530名無しさん＠お腹いっぱい。2011/03/07(月) 13:33:31.63
TTLを短くしとけばいける気もするな。
シリアルは別に上げなくてもいい。

まぁ、普通のやり方ではないけど。
0531名無しさん＠お腹いっぱい。2011/03/07(月) 20:11:09.20
TTL無視するクライアントあるからね。Internet ExplorerはDNSレコードを引いた結果を
TTLにかかわらず1800秒キャッシュするし（一度IE落とせばOK）、某携帯電話屋の
プロクシサーバは3600秒だった。某サーバソフトは起動時にDNS引いて
その結果を死ぬまで保持する。

それでもOKな用途なら、

> dns1とwww1、dns2とwww2をそれぞれセットにして、
> 2台の仮想サーバーに入れようと考えたのですが、
> 片側の仮想がダウンしたときでも、この方法ならサービスが継続できるかと思いまして。

同じようなようなことをやってるところは知ってる。
そこでは仮想サーバを分離せずに、ApacheとBIND を同時に動かす
サーバを2台用意して、
・どっちかのサーバのネットワークが落ちれば、そのサーバのBINDには
　到達できなくなるので、そのサーバのApacheのアクセスは無くなる。
・Webサーバプロセスの応答を自分自身で監視して、応答に異常があればBINDも停止させることで
　そのサーバのApacheへのアクセスを無くす。
・メンテで片方のサーバ止めたい時はBINDを止めるだけでいい。
ということをやってた。今でも動いてるけど、問題が起きたという話は聞いてないです。
0532名無しさん＠お腹いっぱい。2011/03/08(火) 10:19:19.62
ちょっと教えて。
ゾーンファイルを変更した後に適用させるのは、
/etc/init.d/bind9 restart でいいかな。
0533名無しさん＠お腹いっぱい。2011/03/08(火) 10:53:26.13
reload でいいんじゃないの。
その /etc/init.d/bind9 ってスクリプト読んでみ。
0534名無しさん＠お腹いっぱい。2011/03/08(火) 11:00:05.70
ごめん、reloadあった。
どうもです。
0535名無しさん＠お腹いっぱい。2011/03/08(火) 11:18:09.59
rndc reload example.com の方がよい。
ゾーンを指定しないと全ゾーンが読み直されるので、
大量のドメインを収容してる場合は非常に重くなる。
数ゾーン程度ならたいして変わらんけどさ。
0536名無しさん＠お腹いっぱい。2011/03/08(火) 12:08:53.36
ありがとう。覚えとく。
0537名無しさん＠お腹いっぱい。2011/03/08(火) 12:26:24.23
ああ、
viewで内外を分けたとき、外ゾーンの転送が使えないことがいま分かったよ...
0538名無しさん＠お腹いっぱい。2011/03/09(水) 00:57:18.88
>>531
それいいな！
dns1とdns2に持たせるレコードのTTLを違うようにすれば
不等負荷分散もできそうだ
0539名無しさん＠お腹いっぱい。2011/03/09(水) 16:44:19.87
メンテで片方のサーバ止めたい時はBINDを止め
た瞬間からlame delegationです
0540名無しさん＠お腹いっぱい。2011/03/09(水) 16:52:57.11
>>539
わかってないな。NSレコードは両方書いておくんだよ。
ってかやってることはGSLBと変わらん。
0541名無しさん＠お腹いっぱい。2011/03/09(水) 18:02:54.65
lameっちゃlameだけど、ゾーンに複数ある権威サーバのどれかが故障で
止まってる状態に過ぎないわな。
普通にあり。
■ このスレッドは過去ログ倉庫に格納されています