マスター/スレーブの同期 ゾーン転送の強制実行(DNS NOTIFYの使用) ここまでに紹介したゾーン転送の方法では、スレーブがきっかけを作る必要があります。つまり、マスター・サーバのデータを更新しても、スレーブからゾーン転送要求が行われるまでタイムラグが発生してしまいます。 更新頻度によってはSOA中の「リフレッシュ間隔」で調整できますが、ゾーンファイルが頻繁に更新される場合は、タイムラグを最小限に抑えられる別の手法が必要です。それがBIND 9の「DNS NOTIFY」です。DNS NOTIFYは、マスターのゾーンファイルが更新されたことを検知すると、スレーブ・サーバに更新通知を送ります。スレーブは更新通知元がマスター・サーバか否かを確認し、ゾーン転送を開始します。 DNS NOTIFYを実装する前に、BIND管理コマンドrndcについて触れておきます。 rndcはBIND 8のndc
NSレコードはDNSのツリー構造の中で、ドメインの委任を行うときに必要となるリソースレコードです。委任するドメインの情報を持つコンテンツサーバの名前を指定します。 NSレコードは、委任先のネームサーバをホスト名で指定しており、直接IPアドレスで指定するものではないことに注意してください。また、指定するホスト名はAやAAAAレコードを持つものである必要があります。CNAMEによる別名を指定してはいけません。DNSではこのNSレコードによって、ツリー構造の分散管理を実現しており、非常に重要な意味を持ちます。 あるドメイン名に対して、NSレコードはコンテンツサーバの数だけ指定します。プライマリ、セカンダリを含めてコンテンツサーバが6台ある場合は6個のNSレコードを指定します。 NSレコードは、委任元のゾーンファイルと委任先のゾーンファイルという2つのゾーンファイルの両方に記載される、珍しいレコー
ネームサーバの設定が不適切な状態のままにしておくと、ネームサーバが属するドメイン名の管理権限を第三者が取得することにより、本来のサイトと異な るサイトに誘導できるという危険性が指摘されています。 このようなことは、適切なDNS設定を行っている場合は特に問題は発生しませんが、ご登録いただいているドメイン名を安全に運用するためにご一読いただき、登録されているドメイン名のネームサーバ設定の状況をご確認くださいますようお願いいたします。 目次 不適切な設定の確認方法 代表的な問題のケース 不適切な設定の発生する原因 最後に ご注意 ネームサーバを運用されている事業者の皆様へ ドメイン名の廃止や変更、ネームサーバの設定を変更する際には、旧設定を適切なタイミングで削除するなど、不適切となる設定を残さないような形で変更の計画を立てていただくように願いいたします。 不適切な設定の確認方法 ここではネームサ
D. J. Bernstein [Translated into Japanese by MAENO Toshinori] Internet publication djbdns DNS キャッシュを DNS サーバから分離することの重要性 DNS キャッシュ には常に DNS サーバとは別の IP アドレスを もたせるべきです。 言いかえると、 /etc/resolv.conf に書かれている IP アドレスは NS レコードに表われる IP アドレスとはけして一致してはいけないのです。 このように分離することは DNS を運用する上での正しい方法だと 広く知られています。 ``DNS and BIND'' 本の第三版でも以下のように書かれています。 ``Securing Your Name Server,'' page 255: Some of your name servers an
# /usr/local/sbin/rndc stats +++ Statistics Dump +++ (1062085004) #出力開始時間はUNIX System Time(1970年1月1日から経過した秒数)で表示される success 264 #問い合わせに成功したクエリー数 referral 0 #問い合わせに対し参照となったクエリー数 nxrrset 0 #問い合わせに対するレコード型が存在しなかったクエリー数 nxdomain 5 #問い合わせに対するドメイン名やホスト名が存在しなかったクエリー数 recursion 6 #再帰問い合わせを行ったクエリー数 failure 0 #エラーとなったクエリー数 --- Statistics Dump --- (1062085004) 出力される情報を一見しただけで
このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 方針: インストールは、rpm でまったく問題ないので、ここでは触れない。 ローカルネットワーク (192.168.0.0/24) 内で参照するための、キャッシュ DNS サーバとして構築する。独自ドメイン "hoge.cxm" を取得済みと仮定し、ドメイン内ホストの名前解決を主目的とする。 外の世界の名前解決も必要だが、その役目はプロバイダの DNS サーバに委任 (forward) する。 まず最初に基本的なファイルレイアウトで正常動作を確認し、その後、セキュリティ強化のため chroot環境 に移行する。 BIND は DNS サーバのデファクトスタンダードではあるが、安定性やセキュリティの面で信頼性に問題
by D. J. Bernstein djbdns は安全、確実、高速、簡潔、設定も簡単なDNS サーバとツール群です。 qmail, daemontools, ucspi-tcp の作者である D. J. Bernsteinさんの作品です。 (歴史) DNS キャッシュを DNS サーバから分離することの重要性 説明文書(日本語訳) djbdns-1.05.tar.gz 特徴 BINDとの使い易さの比較 DNS ソフトウエアの調査 Bernsteinさんのページの 複製、翻訳に関しての許可 djbdns 入門 tinydns/djbdns 利用状況 誤解集 djbdnsでみられる設定の間違い 自己診断リスト(作成中) djbdnsの性能測定 Introduction to DJBDNS Life With djbdns djbdns.faqts.com Python extension
Planning Important planning recommendations and guidance to review before deploying. Considerations in adopting RHEL 9Key differences between RHEL 8 and RHEL 9 Getting the most from your Support experienceGathering troubleshooting information from RHEL servers with the sos utility Package manifestPackage listing for Red Hat Enterprise Linux 9 Interactively installing RHEL from installation mediaIn
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く