BIND 10 1.0.0ベータ版レビュー前編：BIND 10の紹介
BIND 10の開発プロジェクトは終了しました。（注記: 2014年9月） BINDの次世代バージョンBIND 10 1.0.0のベータ版がISC（Internet Systems Consortium）から2012年12月20日にリリースされました。正式リリースは来年の1月か2月になると思われますが、現時点での状況を探ってみましょう。 なお、本記事は2回に分けて紹介します。 前編: BIND 10の紹介 （今回） 後編: BIND 10のインストール BIND 10の概要 まず、次の画面を見てください。BIND 10を権威サーバとして動かしているときのpsコマンドの出力結果です。 $ ps axf PID TTY STAT TIME COMMAND 21071 ? Ss 0:00 /usr/local/sbin/bind10 21072 ? S 0:00 \_ b10-sockcreat
livedoor Techブログ : CNAMEの間違った使い方
情報環境技術研究室の永井です。 今日はDNSのCNAMEの間違った使い方のお話です。 その間違った使い方がうちのサービスで使用されているかもっ!? DNSって? Domain Name System（ドメイン ネーム システム、DNS）はインターネットを使った階層的な分散型データベースシステムである。 1983年に情報科学研究所 (ISI) のポール・モカペトリスとジョン・ポステルにより開発された。 Wikipediaより一部抜粋 http://ja.wikipedia.org/wiki/Domain_Name_System 例えば、ライブドアのポータルサイトといえば「http://www.livedoor.com/」ですが、実際には「http://125.6.172.15/」というIPアドレスがインターネット上の住所になります。でも、こんな数字の羅列を一々覚えていられないので、DNSとい
（緊急）BIND 9の否定応答受信時のRRSIGレコードの取り扱いの不具合を利用したDoS攻撃について
--------------------------------------------------------------------- ■BIND 9の否定応答受信時のRRSIGレコードの取り扱いの不具合を利用した DoS攻撃について - 緊急のパッチ適用を強く推奨 - 株式会社日本レジストリサービス（JPRS） 2010/12/15（Wed） （脆弱性対象バージョンの拡大と対応方法を追記） --------------------------------------------------------------------- ▼概要 9.7.2-P2以前のBIND 9には、DNSSEC署名された否定応答を受信した際のキャッ シュ済みRRSIGレコードの取り扱いに不具合があり、リモートからのサービ ス不能（DoS）攻撃が可能になる脆弱性が存在することが、開発元のISCより 発表されま
named.conf の設定
### /etc/named.conf root:root 644 ### acl "internal-acl" { 127/8; 192.168.0/24; }; include "/etc/rndc.key"; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; }; }; include "/etc/host1.key"; logging { channel "default_syslog" { syslog daemon; severity info; }; channel "default_debug" { file "named.run"; severity dynamic; }; channel "null" { null; }; category "unmatched" { "nu
BIND 9の脆弱性を利用したサービス不能(DoS)攻撃について
--------------------------------------------------------------------- ■BIND 9の脆弱性を利用したサービス不能(DoS)攻撃について - パッチ適用を推奨 - 2010/01/20(Thu) --------------------------------------------------------------------- ▼概要 BIND 9のDNSSEC検証機能の実装にリモートからのサービス不能(DoS)攻撃が 可能になる脆弱性が発見され、開発元のISCより対応のためのパッチがリリー スされました。該当するBIND 9を利用しているユーザは関連情報の収集やパッ チの適用等、適切な対応を取ることを推奨します。 ▼詳細 BIND 9のDNSSEC検証機能の実装上の不具合により、DNSSEC検証機能を有効に 設定
Stray Penguin - Linux Memo (BIND9)
このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 方針： インストールは、rpm でまったく問題ないので、ここでは触れない。 ローカルネットワーク (192.168.0.0/24) 内で参照するための、キャッシュ DNS サーバとして構築する。独自ドメイン "hoge.cxm" を取得済みと仮定し、ドメイン内ホストの名前解決を主目的とする。 外の世界の名前解決も必要だが、その役目はプロバイダの DNS サーバに委任 (forward) する。 まず最初に基本的なファイルレイアウトで正常動作を確認し、その後、セキュリティ強化のため chroot環境 に移行する。 BIND は DNS サーバのデファクトスタンダードではあるが、安定性やセキュリティの面で信頼性に問題
LPICを楽しむblog: [LPIC2]第2回「BIND9のrndc」
BIND9では、BIND8のndcコマンドに替わってrndcコマンドが使われる。rndcはネットワーク経由でBIND9の操作ができるようになっており、共通鍵を使って安全性を高めている。秘密鍵は以下の場所に配置する。 ・/etc/named.conf内 ・管理端末の/etc/rndc.conf たとえローカルでの操作であってもrndcの操作には上記の設定が必要である。/etc/rndc.confを作成するには、次のようにする。 # rndc-confgen -b 512 -r /dev/urandom -k lpic.jp.key > /etc/rndc.conf -kで鍵の名前を指定する（ここでは「lpic.jp.key」）。作成されたファイルの後半部分はコメントになっているが、この部分を/etc/named.confにコピーし（もちろんコメントを外して）、controlsステートメント
スレーブ・サーバのゾーン転送とセキュリティ
マスター／スレーブの同期 ゾーン転送の強制実行（DNS NOTIFYの使用） ここまでに紹介したゾーン転送の方法では、スレーブがきっかけを作る必要があります。つまり、マスター・サーバのデータを更新しても、スレーブからゾーン転送要求が行われるまでタイムラグが発生してしまいます。 更新頻度によってはSOA中の「リフレッシュ間隔」で調整できますが、ゾーンファイルが頻繁に更新される場合は、タイムラグを最小限に抑えられる別の手法が必要です。それがBIND 9の「DNS NOTIFY」です。DNS NOTIFYは、マスターのゾーンファイルが更新されたことを検知すると、スレーブ・サーバに更新通知を送ります。スレーブは更新通知元がマスター・サーバか否かを確認し、ゾーン転送を開始します。 DNS NOTIFYを実装する前に、BIND管理コマンドrndcについて触れておきます。 rndcはBIND 8のndc
redhat updateマニュアル
Planning Important planning recommendations and guidance to review before deploying. Considerations in adopting RHEL 10Key differences between RHEL 9 and RHEL 10 Package manifestPackage listing for Red Hat Enterprise Linux 10 Dynamically creating a digital roadmap to manage RHEL systemsUse Red Hat Insights for RHEL planning to dynamically create tailored information to analyse and manage your RHEL
BIND+MyDNS 構成 再考 – nodoka.org
何年も前の記事で、BINDとMyDNSの連携についてまとめたことがあった。その記事が未だに参照される事が多いので、今回は現在のDNS周りの考え方を整理しておく。結論から言うと、以前と考え方は大分変わり、BIND+MyDNSの構成は既にやめて、BIND単体での運用に切り替えている。MyDNSをコンポーネントから外した理由は幾つかあるのだが、最も大きな理由がオープンリゾルバの問題だ。数年前にオープンリゾルバの脆弱性を利用して悪質な攻撃の踏み台にされてしまう問題が起きた。それ以降リゾルバの利用に対し制限をかけて最低限の範囲でのみ使える設定に変更した。 BINDでオープンリゾルバの問題を回避するには、自ゾーンのみはどこからでも無制限に引けて、それ以外のゾーンは任意の接続元のみ引けるような設定にしたい。しかし、前段BINDで自ゾーンのみ後段MyDNSにforwardする構成の場合はそういう設定が出来
名前解決の仕組みとゾーンファイルの設定
今回は、BINDの設定を行う。ゾーンファイルの編集を行って正引き・逆引きが行えるようにするほか、MX、CNAMEなど各種レコードの使い方を紹介する。また、名前解決の仕組みについてもここで理解しておいてほしい。 BINDの基本的な動作 前回、DNSサーバの代表的な実装であるBINDをインストールしました。今回は設定を行います。 しかしその前に、BINDの動作を簡単に理解しておく必要があります。そうせずに、単に資料の引き写しの設定ファイルを使う方法もありますが、予期せぬ動作をしたときに対処できなくなってしまいます。 前回、「DNSは分散型データベースである」と述べました。つまり、どこかにすべてのデータを持ったサーバがあるわけではなく、あちらこちらにサーバが分散しているわけです。問題は、どうやって目的のデータを持ったサーバを見つけだすかです。 さすがに手掛かりゼロではどうしようもないので、最初の
＠IT：DNS Tips：逆引きの設定方法とは
逆引きを設定する前に、DNSツリーにおける逆引きというゾーンがどのような位置にあるのかを知っておく必要があります。 IPアドレスの表記は 202.11.16.1 のように、1オクテットごとに「.」（ピリオド）で区切られています。そこで逆引きでは、この1オクテットをDNSにおける1つのサブドメイン名とし、IPアドレスとは反対の順番に並べ（1.16.11.202）、先頭に逆引きのゾーンを表すサブドメイン名（in-addr.arpa）を付けて表記します。 リスト1：DNSにおける逆引きの表記とDNSツリー IPアドレス 逆引きにおける表記 202.11.16.1 1.16.11.202.in-addr.arpa. このように逆引きは、見た目は反対に並べているように見えますが、DNSツリー的には上から順番にたどっていくことで、正引きと同じように名前解決をすることが可能になります。 では実際にBIN
キャッシュ／逆引きDNSの構築と運用
名前解決の速度向上に有効なのがキャッシュサーバ。だが、クライアントにもキャッシュ機能があるため、どこにどのようにキャッシュされるのかを理解していないと問題解決に手間取ることになる。（編集局） 第1回で、DNSには2種の働きがあるとお話ししました。1つは前回紹介したゾーンサーバ、もう1つは今回紹介するキャッシュサーバです。 外向きの仕事をするゾーンサーバに対し、内向きに名前解決の手段を提供するキャッシュサーバは、ユーザーにとって最も身近なDNSです。クライアントがDHCPでIPアドレスを取得する際は、同じようにDNSサーバのアドレスを取得します。 /etc/resolv.confにはプロバイダや自組織のDNSサーバを指定しますが、そこに指定するのはキャッシュサーバ機能を提供するDNSのアドレスです。あらかじめ指定されたドメインの問い合わせにしか応えない（「そのドメインに権威を持っている」と表
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
