●BINDの設定(chroot対応)
Bind 9.9.1-P1からスレーブのゾーンファイルがテキスト形式からraw形式に変更されています。
chrootに対応した設定方法を記載します。
chroot環境移行後は、/var/named/chroot以下に設定ファイルが保存されます。named.confは/var/named/chroot/etc/named.conf、ゾーンの設定ファイルは/var/named/chroot/var/named/以下となります。各設定ファイルは元の場所にも残りますがchroot 環境移行後に設定を変更する際はchroot以下のファイルを変更してください。
DNSサーバで使用するファイルを設定するため /var/named/chroot/etc/named.conf を編集します。
ルートゾーンは世界に13台しかないトップレベルドメインを管理するDNSサーバのIPアドレスを管理しているファイルで、めったに更新されることはないが、念のため最新化しておく。
●内部向け正引きゾーンデータベース作成
注意
ホスト名に使用できる文字は英数字とー(ダッシュ)のみです。
ループバックアドレス用のゾーンのTTLは一度設定すれば、以降は変更する必要がないため長めに設定しても構いません。
●内部向け逆引きゾーンデータベース作成
実際にBINDを起動する前にnamed.confやゾーンファイルが文法的に間違っていないかチェックすることが可能です。named.confのチェックの際には以下のコマンドで実行します。
●BINDの自動起動
●ファイアーウォールの除外設定
ファイアーウォールを設定してい場合は53番ポートを開ける必要があります。
●ゾーンデータベースの再読み込み
正引きまたは逆引きゾーンデータベースを書き換えた場合は、必ずシリアル番号を増やし、BINDを再起動する必要があります。
●ルートゾーン自動更新
1ヶ月に一度、ルートゾーンが最新かチェックし、更新されていればルートゾーンの最新化及び、BINDの再起動を自動的に行うようにする。
※ルートゾーンが更新されていた場合のみ、新旧ルートゾーン情報及び、新旧ルートゾーンの差分情報をroot宛にメールする
●クエリーの制限
BIND8、BIND9ともに、設定によって追加することが出きるセキュリティ設定がいくつかあります。セキュリティ設定のうち主なものをこれから解説します。
"allow-query"、"allow-transfer"、"allow-update"、"allow-recursion"が参照するIPアドレスはアドレスリスト(address list)と呼ばれている。アドレスリストを指定する方法と意味を以下に示します。
これらの書式の先頭に感嘆符"!"をつけると、パターンの反転となります。つまり"!any"は"none"と同じことになります。
BINDでは、アドレスリストに加えて、アクセスコントロールリスト(Access Control List;ACLs)を利用することも出来ます。アクセスコントロールリストを利用して、頻繁に利用するIPアドレスやネットワークに対して名前を付けることによって、IPアドレスやネットワークに関する設定をより簡単にすることが出来ます。
また、IPアドレスやネットワークに関する書き違えや、変更時に一括して変更できることによる設定の間違いを減らすことが出来ます。アクセスコントロールリストの書式を以下に示します。という名前に設定することが出来ます。IPアドレスやネットワークは続けて記述することが出来、複数のIPアドレスやネットワークを一つので指定することが出来ます。アクセスコントロールリストを利用して、クエリーを受け付けるホストを制限した例を以下に示します。
ゾーン転送を行うことによって、DNSサーバに保存されているゾーンデータベースの内容をすべて入手することが出来ます。ゾーン転送は本来セカンダリサーバに対して行われる処理であるが、手順に従えばどのホストからも行うことが可能です。しかしイントラネット環境などゾーンデータベースの内容が外部から参照できることは、セキュリティ上の弱点となる可能性がある。このような事態を防ぐために、ゾーン転送を行うことが出来ますホストを制限することが可能です。 ゾーン転送の制限に関する設定は、/etc/named.confファイルで行う。以下にゾーン転送の制限を行う例を示します。
また、"allow-transfer"をoptionsステートメント内に記述することによって、すべてのゾーンに関してゾーン転送を制限することが出来ます。また、"allow-transfer"をzoneステートメント内に記述する場合、デフォルトとして利用されるoptions ステートメントに記述された内容に上書きする形で、そのゾーンに関してのゾーン転送の制限が行われます。
通常の状態では、DNSサーバはすべてのホストからのDNS参照に対して応答します。通常の状態でもネットワーク資源の浪費となる可能性もありますが、場合によってはDNSサーバに対するDoS(Denital of Service)攻撃を受ける危険性があります。
さらに、DNSキャッシュポイズニング攻撃の標的にされる可能性もあります。クエリーを受け付けるホストを限定したい場合、以下のような書式を利用します。
ただし、そうするとlocalhostを含む全てのLAN内のクライアントからの再帰を行わなくなるので注意が必要です。
また、"allow-query"をoptionsステートメント内に記述することによって、すべてのゾーンに関してクエリーを受け付けるホストを制限することが出来ます。allow-recursionとの違いは、ネームサーバが各ゾーンに対して権限を持つサーバではない場合は、見知らぬホストからのクエリーにはいっさい応答しません。
つまり、allow-queryの方が厳しい制限となります。また、"allow-query"をzoneステートメント内に記述する場合、デフォルトとして利用されるoptionsステートメントに記述された内容に上書きする形で、そのゾーンに関してのクエリーを受け付けるホストの制限が行われます。
逆に頻繁にDoS攻撃を仕掛けてくるホストなど、クエリーを無視するホストが明らかな場合には、"blackhole"サブステートメントを利用することが出来ます。"blackhole"サブステートメントでは、"allow-query"サブステートメントとは逆に、クエリーを無視するホストやネットワークを設定することが出来ます。"blackhole"の利用は以下のような記述で行います。
前に説明したように、ゾーンデータベースに登録するリソースレコードの1つにHINFO(Host Infomation)があります。ここには通常、ホストのオペレーティングシステム(OS)やハードウェアについて記述することになりますが、場合によっては悪意のあるユーザに対してホストの弱点を教えることになってしまいます。
HINFOに関する情報は通常のDNS参照によって入手することが出来るため、前述のゾーン転送の制限では制限できません。このため、状況によってはゾーンデータベースにはHINFOに関する情報を記述しない方がよいことになります。ゾーンデータベースに記述された情報を補強するためのデータをゾーンデータベースに追加する場合には、コメント文などで追加した方が安全となります。
同様の理由から、WKS(Well-Known Service)に関しても、上記の処理が必要になる場合があります。
●BINDのバージョンを隠す方法
BINDのバージョンを調べる方法
BINDのバージョンを調べるには、バージョンを調べたいBINDが稼働しているサーバにログインしnamedコマンドを実行するか、BINDが稼働しているサーバにログインできない場合はdigコマンドを使うことで、BINDのバージョンを調べることができます。
BINDが稼働しているサーバにログインできるのであれば、namedコマンドを-vオプションを付けて実行するとバージョンが表示されます。
BINDのバージョンを隠す方法
BINDのバージョンを隠すには、named.confのoption{};に次の行を追加しnamedを再起動します。
●BINDのログ
BIND には、named.confにloggingステートメントを記述しておくことでネームサーバのログ出力をより広範に制御することができるようになります。channelで出力先を選択し、categoryで出力フォーマットとseverity(重要度)を指示します。named.confにはデフォルトではloggingステートメントが記述されていませんが、デフォルトでもloggingの機能は設定されており、categoryとchannel共にデフォルト値が存在します。
まず、named.confに何も設定しなかった時のデフォルトのログ設定を以下に記します。unmatchedは、どのviewにもマッチしなかったメッセージのことで、デフォルトでは、null(ログを出力しない)が指定されています。
●カテゴリ
●チャンネル設定の書式
ログを格納するディレクトリを作成します。BIND が出力するログを標準の/var/log/messagesではなく、専用のディレクトリを作成し、その中に格納していくこととします。
次にcategoryの設定を行います。ロギングは、channelを定義したからといってログ機能が動作するわけではなく、categoryが指定されてはじめてログ出力を行うようになります。以下の例では、"category default "(上記表参照)の出力を、channelの default-logで定義したとおりにログを出力する、という設定になっています。
ログを一括して出力する例
次に、category xfer-inとcategory xfer-outです。category xfer-inでは、他サーバーから自ホストへのゾーン転送を行った際のログを出力し、その出力場所として、channel "xfer-in-log"で指定した場所に従います。同様に、自ホストから他サーバーへのゾーン転送に関するメッセージは、channel "xfer-out-log"に従ってログが出力されます。つまり、xfer-in.logと xfer-out.logのふたつのログが作成されることになります。
category queriesは、問い合わせに関するログを出力します。これを指定することで、攻撃元を容易に特定することもできるようになります。ただし、全クエリーを出力するため、指定する場合はサーバーのリソース消費にも気を配りましょう。
category lame-serversは誤った設定がなされたサーバーに関する逆引きエラーを出力しないように、nullを指定しています。
●セキュアなnamed.conf設定例
BIND9のnamed.confの設定例を以下に示します。
●家庭内DDNSの設定
参考URL:はじめての自宅サーバ構築 - Fedora/CentOS - DHCPサーバとDNSサーバの連携
参考URL:CentOS7でdhcpとbindを連携させ家庭内DDNS
DHCPサーバの設定ファイルの編集
DHCPサーバは構築済みとします。
DHCPサーバの設定ファイルを編集します(編集した部分のみ記載)。 下記のように変更
BINDの設定ファイルの編集
DNSサーバは構築済みとします。
BINDの設定ファイルを編集します(編集した部分のみ記載)。
DNSサーバのDirectoryのアクセス権変更
DNSサーバが起動するプロセスは「named」ユーザで起動します。
しかし、DNSサーバ(bind)をインストールしたデフォルトのZONEファイル配置ディレクトリ「/var/named」のアクセス権は750 、所有者・グループはroot:namedとなっているためnamedではファイル更新ができません。
プロセスがZONE情報を更新できるように、アクセス権を変更します。
/var/named
/var/named/chroot
/var/named/chroot/var
/var/named/chroot/var/named
/var/named/chroot/var/named/ゾーンファイル
ゾーンファイル:正引き・逆引きファイル
DHCP・DNSサーバの再起動
DHCPサーバとDNSサーバを再起動します。
DNSサーバ更新テスト
nsupdateを使用してDNSサーバーを更新をテストするにはbind-utilsをインストールし、nsupdateコマンドを実行します。実行すると対話型コンソールになりますので下記のように入力します。何もエラーが出なければ問題ありません。
したがって、rndcでdumpして現在のDNSレコードを確認する必要があります。
DHCPとDNSの動作確認
LinuxをDHCPクライアントとして設定し、DHCPサーバから付与されたIPアドレスがDNSサーバに登録されるか確認します。
ジャーナルファイルも更新されていることが分かります。
●digコマンド
digの書式
基本的に、dig以降の引数の順番は関係ありません。詳細は、dig -hやman digで確認できます。
[ 書式 ]
dig [ digオプション ] [ @問い合わせ先ネームサーバ ] 検索ドメイン [ レコードタイプ ] [ 問い合わせオプション ]
[ 問い合わせオプション ]
-4 IPv4で問い合わせます(IPv6で問い合わせしない)。
-6 Pv6で問い合わせます。ただし、IPv6で接続できない場合はIPv4で問い合わせます。
-p ポート番号 デフォルトの53ではなく指定したポートへ問い合わせます。
[ @問い合わせ先ネームサーバ ]
問い合わせを行うネームサーバ名を指定します。IPアドレスでも可能。
省略した場合は、/etc/resolv.confでnameserver行で指定するネームサーバに問い合わせます。
複数のnameserver行がある場合は、最初のnameserver行を使います。
[ 検索ドメイン名 ]
問い合わせるドメイン名、またはホスト名を指定します。
IPv4の逆引きの場合はin-addra.arpaドメイン、IPv6の逆引きの場合はip6.arpaドメインを使用します。ただし、-x IPアドレスとすることもできます。
[ レコード ]
問い合わせるレコードの種類
soa、ns、mx、a、ptr、cname、txt、any、axfrなど省略時はaレコードとなります。ただし、-x IPアドレスを検索する場合のデフォルトはptrとなります。
[ digオプション ]
digオプションの順番について
digオプションは、その順番や位置によって表示内容が異なってくるので注意します。digの後にdigオプションをつけたほうがよけいな(と個人的に思う)3行が出力されないので良いと思います。
●レコードの確認
SOAレコードの確認
digでは、DNSサーバを「@」に続けて指定します。ここではローカルホストへの問い合わせになるよう、「127.0.0.1」または「localhost」を指定します。/etc/resolv.confでネームサーバを自分自身にしている場合(注)は省略可能です。
注:DNSサーバに自分自身を指定する場合は、/etc/resolv.confに次のような記述が必要です。
domain example.jp
nameserver 127.0.0.1
さらに、調べたいドメインとレコードを指定します。引数の順序に決まりはありません。
NSレコードの確認
同様に、NSレコードを確認してみます。レコードオプションに「ns」を指定してdigを実行します。
正引き情報の確認
digの引数に、調べたいドメインではなくホスト名をフルドメイン付き(FQDN)で指定します。Aレコードを調べる場合は、「a」を指定します。ちなみに、Aレコードの場合は指定を省略できます。
逆引き情報の確認
digでは通常、引数にドメイン名が来ることを期待します(つまりドメイン名指定がデフォルト)。IPアドレスを指定する場合は、「-x」オプションを使います。
Aレコードを調べる場合は、レコードオプションに「a」を指定し、これは省略可能だと説明しました。しかし、ここでは意図的に省略します。レコードオプション「a」を指定したときとそうでないときの挙動の違いを一度自分で確認してみましょう。どうしてそのような違いが生じるのかは、次回で説明します。
キャッシュサーバの動作確認
最後にキャッシュサーバの動作を確認します。外部のドメインを指定して、DNSが引けているかを確認します。
●逆引きの問い合わせについて
-x オプションを使用すると楽
IPv4アドレス
例) 124.83.179.227( = f10.top.vip.ogk.yahoo.co.jp )のPTRレコードを問い合わせる
[ 使用例 ]
-xオプションを使用しない場合
-xオプションを使用する場合
IPv6アドレス
例) 2001:dc2:1000:2006::cafe( = www.nic.ad.jp )のPTRレコードを問い合わせる
[ 使用例 ]
-xオプションを使用しない場合
-xオプションを使用する場合
●TCPによる問い合わせ
通常、DNSの問い合わせはUDP53番宛に対して行われ、TC=1のビットが返ってきた場合は改めてTCP53番宛に問い合わせるようになっています(TCPフォールバック)。
しかし、digの+vcオプションを使用すると、いきなりTCP53番で問い合わせることができます。
問い合わせ先DNSサーバ(またはその手前にあるFWなど)がTCP53番を許可しているかどうかを調べるのによく利用します。TCP53番は、DNS問い合わせ以外にもゾーン転送でも利用しているので、ゾーン転送不可の原因を調べるのに役立ちます。
[ 使用例 ]
●EDNS0による問い合わせ
EDNS0とは、応答サイズが512バイトを超えてもUDPで回答できるようにした拡張機能のことです。EDNS0での最大UDPサイズは4096バイトで、これを超える場合はTCPフォールバックによりTCPで再問い合わせが行われます。digの+bufsizeオプション、または+dnssecオプションを使うと、EDNS0を有効にすることができます。
[ 使用例 ]
●DNSSECによる問い合わせ
DNSSECで問い合わせる場合は、+dnssecオプションを付加します。+dnssecオプションを付加すると、自動的にEDNS0も有効になります(最大サイズ4096バイトに設定)。+bufsizeも併用してEDNS0の最大受信サイズを指定することもできます。
[ 使用例 ]
●BINDのバージョンの確認
digを使ってBINDのバージョンの確認ができます。
●ルートDNSのトラストアンカーを取得する
DNSSEC対応の設定に必要なトラストアンカー(KSK公開鍵)を取得します。
●権威DNSサーバのDNSSEC対応
参照
第4回 権威DNSサーバのDNSSEC対応
また、DS(Delegation Signer)はKSK公開鍵から求められる情報です。
実運用時には定期的にKSK、ZSKを更新し再署名、DSの再登録が必要となります。KSK、ZSKそれぞれについて事前公開法/二重署名法のどちらかを選択して行うなど複雑な作業になります。
また、注意深く行わないと最悪すべてのレコードの署名が不正となってしまいます。
では、KSK及びZSKを作成します。
「key-signing key」と記載があるのががKSK鍵、「key-signing key」と記載があるのがZSK鍵になります。
管理しているゾーンに対して署名します。/var/named/keys以下に鍵が複数ある場合は、その数だけ署名されることになります。
署名されたゾーンファイルを利用するように「named.conf」を変更します。
DNSSECが有効になっているか、digコマンドにより確認します。
権威DNSサーバの準備完了後、上位ゾーンと連携させ必要がありますこれは契約しているレジストラ(や指定事業者)に依頼することが多いと思われます。
DSレコードは、dnssec-signzoneコマンド実行後に、/var/named/zoneの下に「dsset-bigbang.mydns.jp.」というファイルとして出力されています。
なお、DSレコードは、dnssec-dsfromkeyコマンドを使ってKSK公開鍵ファイルからも生成できます。
詳細な設定は下記を参照してください。
Authoritative Service
●権威DNSサーバの運用
前項の作業で権威DNSサーバの構築が完了し、DNSSECに対応した状態となりました。
しかし、権威DNSサーバではそれ以降も、DNSSECに関連して定期的なメンテナンスが必要となってきます。基本的には下記3つの作業が定常的に発生することになります。
【1】再署名
署名の有効期間を定期的に再設定するために、再署名を実施します。
また、レコード追加などゾーンの内容に変更があった場合も、再署名を行う必要がある。再署名については、署名を行う場合と同様にdnssec-signzoneコマンドを用いればよいです。
【2】ZSKの作成・更新
ZSKやKSKは定期的に作成および更新する必要があります。鍵の作成手順については、初回の鍵生成とほぼ同様ですが、2回目以降の鍵の作成については事前公開の日付、署名に使い始める日付を、鍵の更新サイクルに合わせた形にする必要があります。
例えば、事前公開法によってZSKを運用し、初回のZSK生成から3週間後の時点で新しいZSKを事前公開するとしよう。その場合は下記のようなコマンドで新しいZSKを作成できる。
作成したZSKは3週間後の2011年12月22日00時00分00秒から事前公開され、2012年1月1日00時00分00秒から署名に使われることを表しています。
これらは再署名の時点で反映されるため、2011年12月20日00時00分00秒以降と2012年1月1日00時00分00秒以降に、再署名およびゾーン情報の再読み込みを行うとよいでしょう。
【3】KSKの作成・更新
ZSKと同様に、KSKも定期的に作成・更新する必要があります。こちらも作成作業自体は、基本的にはZSKの2回目の作成と同様です。
ただし、KSKは対応するDSレコードを上位ゾーンに登録しているため、KSKの更新とともにDSレコードの更新申請が必要となります。二重署名法を使ってKSKを運用する場合、DSレコードの再申請は、二重署名がされている期間中にする必要があります。
キーロールオーバー中には複数のZSKやKSKが存在するため、鍵を取り違えることのないよう、鍵タグを用いてきちんと区別するなどの注意が必要です。
●ゾーンサーバ
自身が所有するドメイン名をインターネットに広報するために必要なサーバです。「広報」という言葉を用いると、外部に対して能動的に働き掛けるように考えてしまいますが、実際には自ドメイン名に対する問い合わせ要求にこたえるもので、動作としては受動的です。「DNSの仕組みと運用(1)」をお読みいただければ、ルートサーバからドメインツリーをたどって手元のゾーンサーバに問い合わせが到達するか理解できると思います。
手元でサーバを立ち上げるにしろ、どこかに委譲するにせよ、ドメイン名を取得してそのドメインを自組織内外のインターネットで引けるようにするにはゾーンサーバが必要です。
また、ドメイン名解決を行う際に用いられるゾーンデータの出所によって、ゾーンサーバはさらに2つに大別されます。
●キャッシュサーバ
キャッシュサーバはクライアントから来る名前解決要求にこたえるもので、目的のドメインをリゾルブできるまで、外部のDNSをドメインツリーをたどって再帰検索します。
BIND 9の場合はゾーンサーバの機能も内包しているため、「自身のゾーンデータに該当しなかった場合」という条件が付きます。可能であれば、ゾーンサーバ用のBINDとキャッシュサーバ用のBINDは区別して運用することをお勧めします。
ゾーンサーバが外部からの問い合わせに対する受動的処理だったのに対し、キャッシュサーバは外部のDNSを参照する能動的なものになります。キャッシュサーバは一度問い合わせた情報をサーバ内のキャッシュに保存し、次に同じ問い合わせが来たときに高速に返答することができます。
また、BIND 9では単に問い合わせに成功した情報だけでなく、名前解決できなかったという情報をキャッシュする「否定キャッシュ」(ネガティブキャッシュ)も備えています。これらの問い合わせキャッシュがどれくらいの期間有効なのかも運用には大事な要素になってきますが、そちらについては「TTL」というキーワードとともに紹介します。
named.confの編集
キャッシュサーバに特化した設定項目を見ていきます。
アクセス制御用センテンス。宣言名「bigbang-net」は適当に変更可能
プライベートネットワーク内からのみアクセスを許可
自分自身からの問い合わせを許可
キャッシュサーバという用途を考えると、この指定は必須です。キャッシュサーバが外部のネットワークから使用されるのは不本意です。もしファイアウォールやNATボックス内にDNSキャッシュサーバを設置できるのであれば、外部からのアクセスは一切不要にしても構いません。キャッシュサーバ自身が外部に問い合わせることがあっても、外部からキャッシュサーバに対する何らかの接続が発生することはありません。
②は「yes」にすることで、ドメインツリーの再帰問い合わせを有効にします。つまり、外部のさまざまなドメインに対して返答が可能になります。もしゾーンサーバの機能だけを提供するDNSであればここは「no」とし、自身で管理している(権威を持っている)ドメイン以外の応答には答えないようにすべきです。
bigbang.mydns.jpの順引きや192.168.10.0/24の逆引きの設定は、キャッシュサーバには不要です。
なお、localhost(127.0.0.1)に関する指定とルートサーバに関する情報はどの場合も必要となります。
キャッシュデータの確認
上記の場合なら、named.ca、local.zone、local.rev、named.pidを準備します。後は、namedを起動あるいは再起動するのみです。
キャッシュサーバに有効な設定
キャッシュサーバには、「recursion yes」以外にも有効な設定がいくつか用意されています。先ほど Windows 2000/XPのDNSキャッシュ機能に触れた際、TTL/ネガティブキャッシュTTLともに、Windows内であらかじめ決められた値で上限を切ることができると説明しました。BIND 9で同じことができないわけがありません。BIND 9では以下のようにnamed.confファイル中のoptionsステートメントで指定します。
(1)はネガティブキャッシュの最大TTLを指定しています。指定がない場合は10800秒(3時間)になります。通常、キャッシュのTTLの最大値は(2)のように指定します。指定がない場合のデフォルト値は604800秒(1週間)です。(3)のLame TTLについては次回以降Lameキーワードとともに説明します。
設定を変更したらnamedを再起動し、再度digコマンドでキャッシュデータのTTL値を確認してみましょう。
●DNS関係の用語
●TTLとネガティブキャッシュ
TTLはデフォルトのキャッシュ有効期限(Time To Live:TTL)を指定するものです。SOAレコードの中にもTTLの値を見つけることができます。これを理解するには、キャッシュの機能を理解する必要があります。
通常、キャッシュサーバはDNS問い合わせに成功したもの、すなわち「www.hoge.co.jp→172.17.100.1(または172.17.100.1→www.hoge.co.jp)」の結果をー時的に蓄えます。その一方で、「dummy.hoge.co.jp→NXDOMAIN(ドメインが存在しない)」といった、失敗した結果をキャッシュする「ネガティブキャッシュ」も併せ持っています。
2つのキャッシュの性質を考えると、同じTTLの値を使用するのはあまり有効ではありません。そこで、RFC 2308(http://www.ietf.org/rfc/rfc2308.txt?number=2308)で新たにネガティブキャッシュが定義されました。
これを受けて、BIND 8.2以降ではいままでのSOAレコードにあるデフォルトTTLの値をネガティブキャッシュ用のTTLとし、新たに$TTL行を設けてゾーンデータのデフォルトTTLの値を指定するようにしました。また、ゾーン全体に対してTTLを設定する以外に、レコードごとの指定もできます。これにより、変更を予定しているホストのレコードは個別にTTLを短くする、といったことが可能になります。
●クラスC未満での逆引き設定
逆引きドメインツリーでは、IPアドレスの第3オクテット以下を分割することはできません。1(または0)から255までを1つのゾーンファイルに収める必要があります。しかし、これではクラスC未満でIPアドレスを割り当てられた場合は、割り当てIPをクラスC単位で管理するネットワーク事業者にいちいち修正依頼することになります。
そこで、クラスCの逆引きを管理するネットワーク事業者側の逆引きゾーン情報にサブドメインとCNAMEを用いることで、見かけ上はクラスC未満で割り振られた各契約者側で逆引き情報を管理できます。
まず、ネットワーク事業者側のnamed.confファイルおよびゾーンファイルから見ていきましょう。
named.confは、一般的なクラスCでの逆引き定義と変わりません。「file」には、それぞれのルールに合わせて任意のファイル名を指定します。
ここで指定されたゾーンファイルexample.revを見てみると、IPアドレスに対するホスト名の指定に用いられるPTRの行があり、各顧客に割り当てているIPレンジにはCNAMEが使われています。そのCNAMEで指定された先に、IPアドレスの第4オクテット目「.sub-a.20.168.192.in-addr.arpa.」が指定されています。通常のin-addr.arpa.の使い方ではクラスCまでしか指定できないため、独自にサブドメインを設け、見かけ上クラスC未満のアドレスをそれぞれのIP割り当て先(この場合は顧客Aや顧客B、C)のDNSに委譲しています。その際、サブドメインに対する「NS」をそれぞれ顧客のDNSに向けているわけです。
named.confのゾーンの指定は、ネットワーク事業者が決めたサブドメイン(sub-a)付きのもので指定されています。逆引き用のゾーンファイル(example-a.rev)は至って一般的なものです。ここにきて、ようやく192.168.20.1のIPアドレスに対するホスト名が解決されるわけです。
digコマンドを使って確認してみましょう。1.sub-a.20.168.192.in-addr.arpa.を経てsv1.example-a.jp.に到着することが分かります。
●サブドメインの運用と委任
大規模なサイトでは、「サブドメイン」によって実組織を模したドメイン構成をとることがあります。その際、サブドメインの管理を「委任」することが可能です。
DNSは、「ドメインツリー」と呼ばれるトップダウンの木構造を成しています。example.jpドメインを取得した場合、example.jpゾーン情報を持つDNSサーバのアドレスやホスト名を、jpゾーンを管理する上位DNSサーバに登録する必要があります。
ゾーン情報(例ではexample.jp)を持つDNSサーバのアドレスやホスト名を、その上位ドメイン(例ではjp)のゾーン情報を管理するDNSサーバに登録する手順こそが「委任」(delegation)です。
上位ドメインを管理する側(以降「親」)は、その下位ドメイン(以下「子」)のゾーン情報をすべて持たず、子のゾーン情報が得られるDNSサーバのみを把握しています。つまり、「子ゾーンに関する情報は××DNSサーバに聞いてくれ」と、権限を委譲するわけです。これにより、親サーバが子ゾーンの情報であふれることなく、また子サーバはゾーン情報の変更のたびに親に変更を依頼する必要から解放されます。
親と子は相対的な関係です。取得した自ドメインを親とし、独自に子ドメインを作成することも可能です。この場合は、「サブドメイン」といった方が一般的でしょう。会社や団体などの組織であれば、部署や部門でサブドメインを分割するのが一般的ですが、まずサブドメイン導入の是非を確認するといいでしょう。
個人や小規模のコミュニティであれば、サブドメインの必要性はほとんどないでしょう。サブドメイン化し、ゾーン情報を分散化させなければならないほどホストを抱えているわけでもなく、各部門で管理できるドメインが必要になるという事態になる可能性もまれです。サブドメインが必要になるのは、ゾーン情報を分散化させる必要が生じるほどホスト情報がある場合や、組織的なしがらみで自由度の高いドメインを各内部組織に渡す必要がある場合です。サブドメイン化すれば、管理対象のホストはサブドメイン側で管理されるので、ホスト情報の更新頻度も軽減されます。また、親のゾーン情報も小規模になります。
注意しなければならないのは、サーバ側の負荷は削減されても、親ドメインの管理者にはより厳格な運用が要求されるということです。親ドメインの管理者はサブドメインのゾーン情報をケアしなくてもいい分、サブドメインが正しく運用されているか、各サブドメイン管理者に対して十分に周知する必要があります。ホスト名の命名規則を作成・徹底するのもいいでしょう。
委任しないサブドメイン運用
サブドメインの運用に当たって、すべてのサブドメインに委任先となるDNSを立てる必要はありません。組織の規模や管理手法によっては委任を利用せず、親ドメイン内で完結させることもできます。サブドメインが管理するゾーン情報の更新頻度が比較的低い場合や、サブドメインを運用できる担当者やサーバなどの資源に恵まれない場合は、この方法が有効的です。
例として、example.jpドメインにサブドメインとして「secretary.example.jp」を新設してみましょう。secretary.example.jpに属するホスト情報は次のとおりです。
基本的なサブドメインの設定
最も簡単な方法は、親(example.jp)のゾーンファイルに子(secretary.example.jp)のホスト情報を持たせることです。
ホスト名の最後の「.」を省略すると、ゾーンファイルの起点名が補完されます。例ではnamed.confで「example.jp」を起点名に指定(注)しているため、下記のようにFQDNで指定した場合と同じように振る舞います。特に、MXレコードの指定ではドメイン名そのものをレコードの左辺に指定しています。
設定は、親ゾーン(example.jp)のNSとして登録されている全DNSサーバ(図3のA、B)に必要です。ゾーン転送やゾーンファイルの自動更新を用いてゾーン情報の同期を行っているのでなければ、ここで紹介した設定を全サーバに施します。設定完了後、BINDを再起動して変更を有効化し、digなどで動作を確認します。
$ORIGINを使用したサブドメインの設定
named.confで指定したデフォルトの起点名を意図的に変更するには、$ORIGINステートメントを用います。$ORIGINステートメント以降は、ホスト名の最後の「.」を省略した際に補完されるドメイン名が、$ORIGINの右辺(secretary.example.jp.)に変更されます。ただし、MXはFQDNを指定する必要があります。
また、$ORIGINで起点名を変更すると、再度$ORIGINで起点名を定義し直さない限り、行末まで指定した起点名が有効になります。
$ORIGINに$INCLUDEを併用した設定
$INCLUDEステートメントを利用することで、サブドメイン「secretary.example.jp」の情報を別ファイルに分離し、親のゾーンファイルに挿入させることができます。サブドメインのゾーンファイルはexample.zoneと同じディレクトリ(ここでは/var/named)に保存し、記述する内容は「$ORIGINを使用したサブドメインの設定」と同じにします。サブドメイン情報を別ファイルとすることで、ゾーンファイルの編集中に親ドメインとサブドメインの整理がつかなくなるなどの煩わしさがなくなります。
$INCLUDEで起点名を変更した設定
$INCLUDEの2番目の引数に起点名を指定することで、記述をさらに簡潔にできます。簡素化とともに、起点名の変更がその1行(読み込むファイルに対してのみ)に限定できるため、$INCLUDEの次の行はデフォルトの起点名(例ではexample.jp)のままにすることが可能です。
専用のゾーンファイルを用意する方法
BIND 9では、サブドメイン専用のゾーンファイルを定義できます。これまでの方法は、親のSOAをそのまま引き継ぎますが、専用のゾーンファイルを用意すればサブドメイン専用のSOAを定義できます。
●あるサーバが倒れてから名前解決が遅くなった
原因は、名前解決が遅くなったマシンで障害のため存在していないサーバのIPアドレスを/etc/resolev.confの最初のレコードに設定していたためだった。
この行を削除し、別ネームサーバに変更したところ正常な状態に戻りました。
●プライマリDNS、セカンダリDNSを設定しているにもかかわらずSSH接続が遅い
デフォルトゲートウェイが変わったためによるものだった。デフォルトゲートウェイを修正。
●named-sdbによる高負荷
2012年12月初旬、Cactiのグラフを確認していたところ、あるPCがいつの間にか高負荷の状態になっていることが分かりました。
topコマンドで確認してみると、「named-sdb」が該当しています。
これで高負荷が改善されました。
●It's world writable or writable by group which is not "root"が出力された場合の対処方法
crondの動作時に正常に動作しなかった場合root宛にメールが送られてきます。いつからかnamedのログローテションが正常に動作していない内容のメールが送信されてくるようになりました。
この時のログローテションの内容は下記のとおりです。
●isc_stdio_open '/var/log/named/queries.log' failed: file not foundが出力される
namedを再起動すると/var/log/messagesに下記のようなエラーが記録されていることに気が付きました。
●slaveのzoneファイルの内容をチェックする方法
raw形式のzoneファイルの内容をチェックする方法は下記のとおりです。
逆引きのZONE_NAMEは「0.168.192」、ZONE_FILE_NAMEは「0.168.192.in-addr.arpa.slave」
となります。これらを確認するには下記のコマンドを実行します。
●セカンダリのゾーンファイルをtext形式にする方法
named.conf内のzone{};内にmasterfile-format text;を記述すればtext形式になります。text形式にすると、起動パフォーマンスが低下するようです。多くのゾーンを管理しているDNSサーバではraw形式方がいいのかもしれません。
下記がサンプルです。
●validatingと言うログ
参考URL:BINDのログで溢れてた。
以前DNSSECを試用していた設定が残っていたため下記のようなログがたまに記録されていました。
named.confを下記のように変更しました。
●unexpected RCODE REFUSEDというログを記録させないようにする方法
参考URL:Bind - lame server resolving をログから消すには
lame-servers.logに下記のようなログが記録されていました。
●dumping master file
セカンダリDNSサーバ構築時に下記のような転送エラーが記録されていました。
Bind 9.9.1-P1からスレーブのゾーンファイルがテキスト形式からraw形式に変更されています。
chrootに対応した設定方法を記載します。
# yum -y install bind bind-utils bind-chroot # /usr/libexec/setup-named-chroot.sh /var/named/chroot on ← chroot環境対応でない場合に実施 # systemctl stop named ← chroot環境対応でない場合に実施 # systemctl disable named ← chroot環境対応でない場合に実施 # systemctl start named-chroot # systemctl enable named-chrootnamed-chrootが正常に起動できない場合は、bind、bind-utils、bind-chrootを削除し、その後/var/named/chroot以下のファイルを全て削除したほうが良いでしょう。
chroot環境移行後は、/var/named/chroot以下に設定ファイルが保存されます。named.confは/var/named/chroot/etc/named.conf、ゾーンの設定ファイルは/var/named/chroot/var/named/以下となります。各設定ファイルは元の場所にも残りますがchroot 環境移行後に設定を変更する際はchroot以下のファイルを変更してください。
# ls -l /var/named/chroot/etc 合計 24 -rw-r--r-- 1 root root 333 8月 18 13:40 localtime drwxr-x--- 2 root named 6 7月 29 10:05 named -rw-r----- 1 root named 1582 10月 30 2013 named.conf -rw-r--r-- 1 root named 2389 7月 29 10:05 named.iscdlv.key -rw-r----- 1 root named 931 6月 21 2007 named.rfc1912.zones -rw-r--r-- 1 root named 487 7月 19 2010 named.root.key drwxr-x--- 3 root named 24 8月 18 13:40 pki -rw-r----- 1 root named 77 8月 18 10:42 rndc.key # ls -l /var/named/chroot/var/named 合計 16 drwxr-x--- 7 root named 56 8月 18 13:40 chroot drwxrwx--- 2 named named 22 8月 18 13:47 data drwxrwx--- 2 named named 58 8月 18 13:48 dynamic -rw-r----- 1 root named 2076 1月 28 2013 named.ca -rw-r----- 1 root named 152 12月 15 2009 named.empty -rw-r----- 1 root named 152 6月 21 2007 named.localhost -rw-r----- 1 root named 168 12月 15 2009 named.loopback drwxrwx--- 2 named named 6 7月 29 10:05 slaves●BINDの設定(non-chroot)
DNSサーバで使用するファイルを設定するため /var/named/chroot/etc/named.conf を編集します。
# vi /var/named/chroot/etc/named.conf options { #listen-on port 53 { 127.0.0.1; }; ← コメントアウトする #listen-on-v6 port 53 { ::1; }; ← コメントアウトする directory "/var/named"; ↑ 下のzoneセンテンス中に出てくる設定ファイルの位置や namedのワークディレクトリを指定 dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; localnets; }; 変更−−−−↑●ルートゾーン最新化
(サーバ及び、サーバと同じネットワーク内のホストからの問合せのみ許可) recursion yes; version "UNKNOWN"; ← BINDのバージョンを隠す forwarders{ 192.168.0.254; ← ルーター経由接続環境の場合はルーターのIPアドレスを指定 }; dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; // managed-keys-directory "/var/named/dynamic"; managed-keys-directory "/var/na/ed/dynamic"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; 追加(ここから) include "/etc/named.bigbang.mydns.jp.zone"; 追加(ここまで)
ルートゾーンは世界に13台しかないトップレベルドメインを管理するDNSサーバのIPアドレスを管理しているファイルで、めったに更新されることはないが、念のため最新化しておく。
# dig @a.root-servers.net . ns > /var/named/chroot/var/named/named.ca●内部向けゾーンファイルの作成
# vi /var/named/chroot/etc/named.bigbang.mydns.jp.zones zone "bigbang.mydns.jp" { type master; file "bigbang.mydns.jp.zone"; }; zone "0.168.192.in-addr.arpa" { type master; file "0.168.192.in-addr.arpa"; };
●内部向け正引きゾーンデータベース作成
注意
ホスト名に使用できる文字は英数字とー(ダッシュ)のみです。
# vi /var/named/chroot/var/named/bigbang.mydns.jp.zone $TTL 86400 @ IN SOA bigbang.mydns.jp. root.bigbang.mydns.jp.( 2008010101 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS ns1.bigbang.mydns.jp. IN MX 10 mail1.bigbang.mydns.jp. @ IN A 192.168.0.2 ↑ サーバのプライベートIPアドレスを指定(bigbang.mydns.jp用) * IN A 192.168.0.2 ↑ サーバのプライベートIPアドレスを指定(*.bigbang.mydns.jp用) ns1 IN A 192.168.0.2 mail1 IN A 192.168.0.2 ← CNAMEで定義しない1行目に記述されている「$TTL」に注目します。TTLは、外部のDNSがあなたのドメイン情報を参照してキャッシュする際に、どれくらいの期間情報を保持するかを指定するものです。しかし、2行目から始まるSOAレコードと呼ばれるブロックにもTTLの記述があります。一見無駄な設定のように思えるかもしれませんが、大変重要な意味を持っています。これについては、後述の「 TTLとネガティブキャッシュ」を参照してください。
ループバックアドレス用のゾーンのTTLは一度設定すれば、以降は変更する必要がないため長めに設定しても構いません。
●内部向け逆引きゾーンデータベース作成
# vi /var/named/chroot/var/named/0.168.192.in-addr.arpa
$TTL 86400
@ IN SOA bigbang.mydns.jp. bigbang.mydns.jp.(
2008010101 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS ns1.bigbang.mydns.jp.
2 IN PTR ns1.bigbang.mydns.jp.
2 IN PTR mail1.bigbang.mydns.jp.
↑ サーバIPアドレス最下位部(192.168.0.2)とドメイン名を指定
●起動前のチェック
実際にBINDを起動する前にnamed.confやゾーンファイルが文法的に間違っていないかチェックすることが可能です。named.confのチェックの際には以下のコマンドで実行します。
# named-checkconf -t /var/named/chroot -z /etc/named.conf zone bigbang.mydns.jp/IN: loaded serial 2015081703 zone 0.168.192.in-addr.arpa/IN: loaded serial 2015081802 zone localhost.localdomain/IN: loaded serial 0 zone localhost/IN: loaded serial 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 zone 0.in-addr.arpa/IN: loaded serial 0 # named-checkzone "bigbang.mydns.jp" /var/named/bigbang.mydns.jp.zone zone bigbang.mydns.jp/IN: loaded serial 2015081703 OK # named-checkzone "192.168.0" /var/named/0.168.192.in-addr.arpa zone 192.168.0/IN: loaded serial 2015081801 OK問題がなければOKが出力されます。
●BINDの自動起動
(CentOS 6の場合) # chkconfig --level 2345 named on (Fedora 21以降、CentOS 7以降の場合) # systemctl enable named (Fedora 21以降、CentOS 7以降の場合、chroot環境) # systemctl enable named-chrootこれで、サーバを再起動してもBINDは自動起動されるようになります。
●ファイアーウォールの除外設定
ファイアーウォールを設定してい場合は53番ポートを開ける必要があります。
# vi /etc/sysconfig/iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT -A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT # service iptables restart # service iptables save53番ポートでも、UDPの設定し忘れが多いので注意してください。
●ゾーンデータベースの再読み込み
正引きまたは逆引きゾーンデータベースを書き換えた場合は、必ずシリアル番号を増やし、BINDを再起動する必要があります。
(CentOS 6の場合) # service named reload (または restart) (Fedora 21以降、CentOS 7以降の場合) # systemctl reload named (Fedora 21以降、CentOS 7以降の場合、chroot環境) # systemctl stop named ← chroot環境対応でない場合に実施 # systemctl disable named ← chroot環境対応でない場合に実施 # systemctl reload named-chroot問題なく稼働しているかどうかは、/var/log/messagesを確認してください。
●ルートゾーン自動更新
1ヶ月に一度、ルートゾーンが最新かチェックし、更新されていればルートゾーンの最新化及び、BINDの再起動を自動的に行うようにする。
※ルートゾーンが更新されていた場合のみ、新旧ルートゾーン情報及び、新旧ルートゾーンの差分情報をroot宛にメールする
# vi named.root_update ← ルートゾーン最新化スクリプト作成 #!/bin/bash new=`mktemp` errors=`mktemp` dig . ns @198.41.0.4 +bufsize=1024 > $new 2> $errors if [ $? -eq 0 ]; then sort_new=`mktemp` sort_old=`mktemp` diff_out=`mktemp` sort $new > $sort_new sort /var/named/chroot/var/named/named.ca > $sort_old diff --ignore-matching-lines=^\; $sort_new $sort_old > $diff_out if [ $? -ne 0 ]; then ( echo '-------------------- old named.root --------------------' cat /var/named/chroot/var/named/named.ca echo echo '-------------------- new named.root --------------------' cat $new echo '---------------------- difference ----------------------' cat $diff_out ) | mail -s 'named.root updated' root cp -f $new /var/named/chroot/var/named/named.ca chown named. /var/named/chroot/var/named/named.ca chmod 644 /var/named/chroot/var/named/named.ca which systemctl > /dev/null 2>&1 if [ $? -eq 0 ]; then systemctl restart named-chroot > /dev/null else /etc/rc.d/init.d/named restart > /dev/null fi fi rm -f $sort_new $sort_old $diff_out else cat $errors | mail -s 'named.root update check error' root fi rm -f $new $errors # chmod 700 named.root_update ↑ ルートゾーン最新化スクリプトへ実行権限付加 # mv named.root_update /etc/cron.monthly/ ↑ ルートゾーン最新化スクリプトを毎月自動実行されるディレクトリへ移動
●クエリーの制限
BIND8、BIND9ともに、設定によって追加することが出きるセキュリティ設定がいくつかあります。セキュリティ設定のうち主なものをこれから解説します。
"allow-query"、"allow-transfer"、"allow-update"、"allow-recursion"が参照するIPアドレスはアドレスリスト(address list)と呼ばれている。アドレスリストを指定する方法と意味を以下に示します。
パターン | 意味 |
---|---|
any | すべてのホスト |
none | なし |
localhost | 自ホスト |
localnet | 自ホストが所属しているネットワーク |
a.b.c.d[/m] | IPアドレスとネットマスクによる指定 |
これらの書式の先頭に感嘆符"!"をつけると、パターンの反転となります。つまり"!any"は"none"と同じことになります。
BINDでは、アドレスリストに加えて、アクセスコントロールリスト(Access Control List;ACLs)を利用することも出来ます。アクセスコントロールリストを利用して、頻繁に利用するIPアドレスやネットワークに対して名前を付けることによって、IPアドレスやネットワークに関する設定をより簡単にすることが出来ます。
また、IPアドレスやネットワークに関する書き違えや、変更時に一括して変更できることによる設定の間違いを減らすことが出来ます。アクセスコントロールリストの書式を以下に示します。
acl <acl name> { a.b.c.d/m1; [e.f.g.h/m2]; ....};指定したIPアドレスやネットワークを、
★ クエリー制限の例 # vi /etc/named.conf acl private-net { 192.168.0.0/24; }; options { 中略 allow-query { private-net; }; 中略 };アクセスコントロールとアドレスリストのパターンを、混在して利用することも可能です。
ゾーン転送を行うことによって、DNSサーバに保存されているゾーンデータベースの内容をすべて入手することが出来ます。ゾーン転送は本来セカンダリサーバに対して行われる処理であるが、手順に従えばどのホストからも行うことが可能です。しかしイントラネット環境などゾーンデータベースの内容が外部から参照できることは、セキュリティ上の弱点となる可能性がある。このような事態を防ぐために、ゾーン転送を行うことが出来ますホストを制限することが可能です。 ゾーン転送の制限に関する設定は、/etc/named.confファイルで行う。以下にゾーン転送の制限を行う例を示します。
# vi /etc/named.conf options { 中略 allow-transfer { 192.168.0.2; }; 中略 };以上のように記述することによって、ゾーン転送を行うホストを192.168.0.2 のみに制限することが出来ます。ゾーン転送に関する制限が設定されない場合、すべてのホストからのゾーン要求を受け付けることになるため、出来るだけ設定することが望ましい。
また、"allow-transfer"をoptionsステートメント内に記述することによって、すべてのゾーンに関してゾーン転送を制限することが出来ます。また、"allow-transfer"をzoneステートメント内に記述する場合、デフォルトとして利用されるoptions ステートメントに記述された内容に上書きする形で、そのゾーンに関してのゾーン転送の制限が行われます。
通常の状態では、DNSサーバはすべてのホストからのDNS参照に対して応答します。通常の状態でもネットワーク資源の浪費となる可能性もありますが、場合によってはDNSサーバに対するDoS(Denital of Service)攻撃を受ける危険性があります。
さらに、DNSキャッシュポイズニング攻撃の標的にされる可能性もあります。クエリーを受け付けるホストを限定したい場合、以下のような書式を利用します。
# vi /etc/named.conf options { 中略 allow-recursion { 192.168.0.0/24; }; 中略 };allow-recursionは、再帰(DNSサーバは各レベルを検索し、サーバからサーバへ移動して得られた情報を全てキャシュする)を完全に無効にするのではなく、LAN側だけに制限します。再帰を全面的に禁止したい場合は、セキュリティ的にもnamed.confのoptionsに、
recursion no;と書く方がベストです。
ただし、そうするとlocalhostを含む全てのLAN内のクライアントからの再帰を行わなくなるので注意が必要です。
# vi /etc/named.conf options { 中略 allow-query { 192.168.0.0/24; }; 中略 };クエリーを受け付けるホストを192.168.0.0/24で表されるIPアドレスを持ったホストに限定することが出来ます。このような設定をすることによって、クエリーを受け付けるホストを組織内のホストだけに限定するなどの設定を行うことが出来ます。
また、"allow-query"をoptionsステートメント内に記述することによって、すべてのゾーンに関してクエリーを受け付けるホストを制限することが出来ます。allow-recursionとの違いは、ネームサーバが各ゾーンに対して権限を持つサーバではない場合は、見知らぬホストからのクエリーにはいっさい応答しません。
つまり、allow-queryの方が厳しい制限となります。また、"allow-query"をzoneステートメント内に記述する場合、デフォルトとして利用されるoptionsステートメントに記述された内容に上書きする形で、そのゾーンに関してのクエリーを受け付けるホストの制限が行われます。
逆に頻繁にDoS攻撃を仕掛けてくるホストなど、クエリーを無視するホストが明らかな場合には、"blackhole"サブステートメントを利用することが出来ます。"blackhole"サブステートメントでは、"allow-query"サブステートメントとは逆に、クエリーを無視するホストやネットワークを設定することが出来ます。"blackhole"の利用は以下のような記述で行います。
# vi /etc/named.conf options { 中略 blackhole { 172.16.0.0/24; 中略 }; };以上のように記述することによって、IPアドレス172.16.0.0/24を持ったホストすべてからのクエリーを無視する設定となります。なお、"blackhole"はzoneステートメント内に記述することは出来ず、設定された"blackhole"はすべてのゾーンに対して適用されます。
前に説明したように、ゾーンデータベースに登録するリソースレコードの1つにHINFO(Host Infomation)があります。ここには通常、ホストのオペレーティングシステム(OS)やハードウェアについて記述することになりますが、場合によっては悪意のあるユーザに対してホストの弱点を教えることになってしまいます。
HINFOに関する情報は通常のDNS参照によって入手することが出来るため、前述のゾーン転送の制限では制限できません。このため、状況によってはゾーンデータベースにはHINFOに関する情報を記述しない方がよいことになります。ゾーンデータベースに記述された情報を補強するためのデータをゾーンデータベースに追加する場合には、コメント文などで追加した方が安全となります。
同様の理由から、WKS(Well-Known Service)に関しても、上記の処理が必要になる場合があります。
●BINDのバージョンを隠す方法
BINDのバージョンを調べる方法
BINDのバージョンを調べるには、バージョンを調べたいBINDが稼働しているサーバにログインしnamedコマンドを実行するか、BINDが稼働しているサーバにログインできない場合はdigコマンドを使うことで、BINDのバージョンを調べることができます。
BINDが稼働しているサーバにログインできるのであれば、namedコマンドを-vオプションを付けて実行するとバージョンが表示されます。
$ named -v BIND 9.3.4-P1BINDが稼働しているサーバにログインできなくても、digコマンドに次のようなオプションを付けて実行するとBINDのバージョンが表示できます。
$ dig @ネームサーバのアドレス chaos txt version.bindコマンドの例と、表示される内容の例
$ dig @192.168.1.1 chaos txt version.bind ; <<>> DiG 9.3.4-P1 <<>> @192.168.1.1 chaos txt version.bind ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52347 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT "9.3.2" ;; AUTHORITY SECTION: version.bind. 0 CH NS version.bind. ;; Query time: 1 msecANSWER SECTION:の部分にバージョンが表示される。この例だとバージョンは9.3.2になります。
BINDのバージョンを隠す方法
BINDのバージョンを隠すには、named.confのoption{};に次の行を追加しnamedを再起動します。
options { version "表示させたい文字列"; };例えば、次のようにします。(version ""; のように何も書かない設定でもよし。)
options { version "Unknown"; };実際にdigコマンドを使ってどのように表示されるか確認すると、ANSWER SECTION:に"Unknown"を表示されるのが確認できます。(version ""; とした場合は、""と表示されます。)
$ dig @192.168.1.1 chaos txt version.bind ; <<>> DiG 9.3.4-P1 <<>> @192.168.1.1 chaos txt version.bind ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12725 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT "Unknown" ;; AUTHORITY SECTION: version.bind. 0 CH NS version.bind. ;; Query time: 1 msec
●BINDのログ
BIND には、named.confにloggingステートメントを記述しておくことでネームサーバのログ出力をより広範に制御することができるようになります。channelで出力先を選択し、categoryで出力フォーマットとseverity(重要度)を指示します。named.confにはデフォルトではloggingステートメントが記述されていませんが、デフォルトでもloggingの機能は設定されており、categoryとchannel共にデフォルト値が存在します。
まず、named.confに何も設定しなかった時のデフォルトのログ設定を以下に記します。unmatchedは、どのviewにもマッチしなかったメッセージのことで、デフォルトでは、null(ログを出力しない)が指定されています。
logging category "unmatched" { "null"; }; category "default" { "default_syslog"; "default_debug"; }; };以下は、標準で用意されているデフォルトのchannel設定です。channel指定には、file、syslog、stderr、nullのいずれかの指定が必要です。fileは指定したファイルにログを出力し、syslogはsyslogに、stderrは標準エラー出力にそれぞれ出力します。
//syslogデーモンに出力する channel "default_syslog" { syslog daemon; severity info; }; //named.runへ出力する channel "default_debug" { file "named.run"; severity dynamic; }; //標準エラーに出力する channel "default_stderr" { stderr; severity info; }; //ログを出力しない channel "null" { null; };
●カテゴリ
カテゴリ名 | 説明 |
---|---|
default | チャンネルが割り当てられていない全てのカテゴリ。 |
general | 以下のカテゴリに分類されない、その他全てのメッセージ |
database | namedの内部データベースに関するメッセージ。 |
security | 要求の承認と拒否に関するメッセージ。 |
config | 設定ファイルの処理に関するメッセージ。 |
resolver | 名前解決に関するメッセージ。再帰的に問い合わせへの応答も含む。 |
xfer-in | 他サーバーから自ホストへのゾーン転送に関するメッセージ。 |
xfer-out | 自ホストから他サーバーへのゾーン転送に関するメッセージ。 |
notify | 非同期びゾーン更新通知に関するメッセージ。 |
client | クライアントからの要求に関するメッセージ。 |
unmatched | どのview にもマッチしなかったメッセージ。 |
network | ネットワークに関するメッセージ。 |
upadate | 動的更新に関するメッセージ。 |
queries | 問い合わせのログ。 |
dnssec | DNSSECとTSIGの処理に関するメッセージ。 |
lame-servers | 名前解決を試みようとして発見した、間違った設定のサーバーに関するメッセージ。 |
●チャンネル設定の書式
file <ファイル名> [ versions <バージョン番号> ] [ size <サイズ指定> ] ; syslog <機能分類>; stderr; null; [ severity <重要度>;] [ print-category <真偽値>;] [ print-severity <真偽値>;] [ print-time <真偽値>;] <機能分類> = kern、user、mail、daemon、auth、syslog、lpr、news、uucp、cron、 authpriv、ftp、local0~local7 <重要度> = critical、error、warning、notice、info、debug、dynamic <真偽値> = yes | no <サイズ指定> = <数値> [ K | M | G }
ログを格納するディレクトリを作成します。BIND が出力するログを標準の/var/log/messagesではなく、専用のディレクトリを作成し、その中に格納していくこととします。
# mkdir /var/named/log # chown named.named /var/named/log以下では、BINDに関するログを全て同一ファイルに記録するような設定をしてみます。まず、channelでチャネル名を任意に定義します。ここでは、"default-log"という名前をつけ、そのファイルを、/var/named/log/default.logに出力するように指定しています。"version"は、指定した数字の数だけログを保存するという意味で、namedを再起動したり、リロードしたりすることによってログファイルを自動的にローテーションします。ここでは、5 と指定しているのでログ数5つの中でローテーションされます。ログのサイズを指定した場合、ログサイズが最大サイズに達した時点でログの出力を停止します。注意したいのは、指定したサイズに達してもログのローテーションを行わないということです。
次にcategoryの設定を行います。ロギングは、channelを定義したからといってログ機能が動作するわけではなく、categoryが指定されてはじめてログ出力を行うようになります。以下の例では、"category default "(上記表参照)の出力を、channelの default-logで定義したとおりにログを出力する、という設定になっています。
ログを一括して出力する例
logging { channel "default-log" { file "/var/named/log/default.log" versions 5 size 10M; severity debug; print-time yes; print-severity yes; print-category yes; }; category default { "default-log"; }; };最後に、printについて解説します。print-timeは、時刻を、severityは重要度を出力し、categoryはログカテゴリの表示・非表示を切り替えます。
Jun 12 05:29:32.291 general: debug 1: zone_timer: zone version.bind/CH: enterロギングの応用例
logging { channel "default-log" { file "/var/named/log/default.log" versions 3 size 5M; severity debug; print-time yes; print-severity yes; print-category yes; }; channel "xfer-in-log" { file "/var/named/log/xfer-in.log" versions 3 size 5M; severity debug; print-time yes; print-severity yes; print-category yes; }; channel "xfer-out-log" { file "/var/named/log/xfer-out.log" versions 3 size 5M; severity debug; print-time yes; print-severity yes; print-category yes; }; channel "queries-log" { file "/var/named/log/queries.log" versions 3 size 5M; severity info; print-time yes; print-severity yes; print-category yes; }; category default { "default-log"; "default_syslog"; "default_debug"; "default_stderr"; }; category xfer-in { "xfer-in-log"; }; category xfer-out { "xfer-out-log"; }; category queries { "queries-log"; }; category lame-servers { null; }; };channelやcategoryは複数指定できるため、上記のような設定にして、ログを役割ごとに分散させることもできます。まず、category default では、同じデフォルトでも、ログレベル(severity)の異なるログを出力しています。ひとつめとして、ログレベルがdebugのdefault-allを指定し、channel "default-log"で定義したログ出力方法に従います。default_syslogとdefault_debug、default_stderrでは、BINDの標準出力場所へ出力します。default_syslogならば、/var/log/messagesに出力されます。けれども、default-allよりは詳細なログを出力しません。
次に、category xfer-inとcategory xfer-outです。category xfer-inでは、他サーバーから自ホストへのゾーン転送を行った際のログを出力し、その出力場所として、channel "xfer-in-log"で指定した場所に従います。同様に、自ホストから他サーバーへのゾーン転送に関するメッセージは、channel "xfer-out-log"に従ってログが出力されます。つまり、xfer-in.logと xfer-out.logのふたつのログが作成されることになります。
category queriesは、問い合わせに関するログを出力します。これを指定することで、攻撃元を容易に特定することもできるようになります。ただし、全クエリーを出力するため、指定する場合はサーバーのリソース消費にも気を配りましょう。
category lame-serversは誤った設定がなされたサーバーに関する逆引きエラーを出力しないように、nullを指定しています。
●セキュアなnamed.conf設定例
BIND9のnamed.confの設定例を以下に示します。
acl localnet { ← aclでアクセスコントロールリストを作る 192.168.0.0/24; 127.0.0.1; }; logging { ← loggingでlogにはかれるlame serverの煩わしい文字列をはじく category lame-servers { null; }; }; options { directory "/var/named"; auth-nxdomain yes; allow-recursion { 192.168.0.0/24; }; allow-query { ← クエリーの利用するホストを定義 localnet; }; allow-transfer { ← ゾーン転送の制限を定義 localnet; ***.***.***.***; }; version "Unknown"; lame-ttl 1800; ← lame-server logの保存期間 }; zone "." { type hint; file "named.ca"; }; zone "0.0.127.in-addr.arpa"{ type master; file "named.local"; }; zone "example.com"{ type master; file "example.com.zone"; allow-query { any; }; ← クエリーによる名前解決を許可 }; zone "***.***.***.in-addr.arpa"{ type master; file "named.rev"; allow-query { any; }; ← クエリーによる名前解決を許可 };これは、named.confの外向き設定例です。
●家庭内DDNSの設定
参考URL:はじめての自宅サーバ構築 - Fedora/CentOS - DHCPサーバとDNSサーバの連携
参考URL:CentOS7でdhcpとbindを連携させ家庭内DDNS
DHCPサーバの設定ファイルの編集
DHCPサーバは構築済みとします。
DHCPサーバの設定ファイルを編集します(編集した部分のみ記載)。 下記のように変更
ddns-update-style none; ↓ ddns-update-style interim; 下記11行を追加。 # Dynamic DNSのための追加設定(DNSサーバの設定ファイル「ZONE名」と合わせること。) # 正引きゾーン zone bigbang.mydns.jp { # DNSサーバのアドレスを設定 primary 192.168.0.1; } # 逆引きゾーン zone 0.168.192.in-addr.arpa { # DNSサーバのアドレスを設定 primary 192.168.0.1; }
BINDの設定ファイルの編集
DNSサーバは構築済みとします。
BINDの設定ファイルを編集します(編集した部分のみ記載)。
zone "bigbang.mydns.jp" { type master; file "bigbang.mydns.jp.zone"; }; ↓ zone "bigbang.mydns.jp" { type master; file "bigbang.mydns.jp.zone"; # Dynamic DNS機能を付加(更新するサーバのIPアドレスを指定) allow-update { localhost; localnets; }; }; zone "0.168.192.in-addr.arpa" { type master; file "0.168.192.in-addr.arpa"; }; zone "0.168.192.in-addr.arpa" { type master; file "0.168.192.in-addr.arpa"; # Dynamic DNS機能を付加(更新するサーバのIPアドレスを指定) allow-update { localhost; localnets; }; };
DNSサーバのDirectoryのアクセス権変更
DNSサーバが起動するプロセスは「named」ユーザで起動します。
しかし、DNSサーバ(bind)をインストールしたデフォルトのZONEファイル配置ディレクトリ「/var/named」のアクセス権は750 、所有者・グループはroot:namedとなっているためnamedではファイル更新ができません。
プロセスがZONE情報を更新できるように、アクセス権を変更します。
# chmod -R g+w /var/named/chrootを使用している場合は、以下のパスとファイルが「named」で書き込み出来るようにアクセス権を変更してください。
/var/named
/var/named/chroot
/var/named/chroot/var
/var/named/chroot/var/named
/var/named/chroot/var/named/ゾーンファイル
ゾーンファイル:正引き・逆引きファイル
DHCP・DNSサーバの再起動
DHCPサーバとDNSサーバを再起動します。
# systemctl restart dhpcd # systemctl restart named-chroot
DNSサーバ更新テスト
nsupdateを使用してDNSサーバーを更新をテストするにはbind-utilsをインストールし、nsupdateコマンドを実行します。実行すると対話型コンソールになりますので下記のように入力します。何もエラーが出なければ問題ありません。
>server 127.0.0.1 >update add test.bigbang.mydns.jp. 3600 A 192.168.0.22 >send >server 127.0.0.1 >update delete test.bigbang.mydns.jp. >sendBIND9でDynamic DNSを実行させると動的に更新されたレコードはジャーナル (*.jnl) に記録されます。そのため、ゾーンファイルを確認しても現在のゾーン情報を確認できません。
したがって、rndcでdumpして現在のDNSレコードを確認する必要があります。
# rndc dumpdb -zones # cat /var/named/data/cache_dump.db | grep test.bigbang.mydns.jp.
DHCPとDNSの動作確認
LinuxをDHCPクライアントとして設定し、DHCPサーバから付与されたIPアドレスがDNSサーバに登録されるか確認します。
# less /var/log/messages Dec 13 13:30:17 server1 dhcpd: DHCPREQUEST for 192.168.0.31 from 00:**:**:**:**:** via eth1 Dec 13 13:30:17 server1 dhcpd: DHCPACK on 192.168.0.31 to 00:**:**:**:**:** (fedora30-3) via eth1 Dec 13 13:30:17 server1 named[29278]: zone bigbang.dyndns.org/IN: sending notifies (serial 201912130010) Dec 13 13:30:17 server1 dhcpd: Added new forward map from test.bigbang.mydns.jp to 192.168.0.31 Dec 13 13:30:17 server1 named[29278]: zone 0.0.1.in-addr.arpa/IN: sending notifies (serial 201912130010) Dec 13 13:30:17 server1 dhcpd: Added reverse map from 31.0.168.192.in-addr.arpa. to test.bigbang.mydns.jp # rndc dumpdb -zones # cat /var/named/data/cache_dump.db | grep test.bigbang.mydns.jp. 31.0.0.1.in-addr.arpa. 3600 IN PTR test.bigbang.mydns.jp. test.bigbang.mydns.jp. 3600 IN A 192.168.0.31正引き、逆引きゾーンともに登録されています。
ジャーナルファイルも更新されていることが分かります。
# ls -l /var/named/ -rw-r--r-- 1 named named 1316 12月 13 13:30 0.168.192.in-addr.arpa.jnl -rw-r--r-- 1 named named 1739 12月 13 13:30 bigbang.mydns.jp.zone.jnl
●digコマンド
digの書式
基本的に、dig以降の引数の順番は関係ありません。詳細は、dig -hやman digで確認できます。
[ 書式 ]
dig [ digオプション ] [ @問い合わせ先ネームサーバ ] 検索ドメイン [ レコードタイプ ] [ 問い合わせオプション ]
[ 問い合わせオプション ]
-4 IPv4で問い合わせます(IPv6で問い合わせしない)。
-6 Pv6で問い合わせます。ただし、IPv6で接続できない場合はIPv4で問い合わせます。
-p ポート番号 デフォルトの53ではなく指定したポートへ問い合わせます。
[ @問い合わせ先ネームサーバ ]
問い合わせを行うネームサーバ名を指定します。IPアドレスでも可能。
省略した場合は、/etc/resolv.confでnameserver行で指定するネームサーバに問い合わせます。
複数のnameserver行がある場合は、最初のnameserver行を使います。
[ 検索ドメイン名 ]
問い合わせるドメイン名、またはホスト名を指定します。
IPv4の逆引きの場合はin-addra.arpaドメイン、IPv6の逆引きの場合はip6.arpaドメインを使用します。ただし、-x IPアドレスとすることもできます。
[ レコード ]
問い合わせるレコードの種類
soa、ns、mx、a、ptr、cname、txt、any、axfrなど省略時はaレコードとなります。ただし、-x IPアドレスを検索する場合のデフォルトはptrとなります。
[ digオプション ]
オプション | 説明 |
---|---|
+norec | 問い合わせ先ネームサーバに対して、再帰問い合わせはしないように指示 |
+vc | 最初からTCPで問い合わせる |
+tcp | +vcと同様 |
+ignore | TC=1ビットが返ってきてもTCPで再度問い合わせずに終わる(つまり、TCPフォールバックしない) |
+bufsize=数値 | EDNS0を有効にし、こちら側の最大受信UDPサイズを指定する |
+dnssec | EDNS0を有効とするとともに、DNSSECで問い合わせる |
+multiline | 出力結果を整えてくれる (+dnssecと一緒につけると良いかも) |
+trace | ルートDNSから問い合わせて、結果を順番に出力 |
+short | 回答のあったレコードのうち、右辺部分だけを表示 |
<+nottlid/td> | レコードのTTLの部分を表示しない |
+noall | 何も表示しない |
+answer | +noallがあるとき、ANSWER SECTIONを表示 (+all +answerは意味がない) +anや+ansの省略形も可 |
+authority | +noallがあるとき、AUTHORITY SECTIONを表示(同上) +authや+auの省略形も可 |
+additional | +noallがあるとき、ADDITIONAL SECTIONを表示(同上) +addの省略形も可 |
digオプションの順番について
digオプションは、その順番や位置によって表示内容が異なってくるので注意します。digの後にdigオプションをつけたほうがよけいな(と個人的に思う)3行が出力されないので良いと思います。
# dig +noall @127.0.0.1 www.yahoo.co.jp | +noallを最初につけた場合 noallが評価されて何も表示しない |
# dig @127.0.0.1 www.yahoo.co.jp +noall ; <<>> DiG 9.7.3-P3 <<>> @127.0.0.1 www.yahoo.co.jp +noall ; (1 server found) ;; global options: +cmd |
+noallを最後につけた場合、左記の3行だけ表示され、そのほかはnoallが評価されて何も表示しない |
# dig +noall +answer @127.0.0.1 www.yahoo.co.jp www.yahoo.co.jp. 875 IN CNAME www.ya.gl.yahoo.co.jp. www.ya.gl.yahoo.co.jp. 35 IN A 124.83.187.140 |
+noall +answerにした場合、noallの後でanswerが適用されるので、回答節だけ表示される → いったん全部非表示、でもanswerだけ表示 |
# dig +answer +noall @127.0.0.1 www.yahoo.co.jp | +answer +noallにした場合、answerの後でnoallが適用されるので、何も表示されない → answer表示、でも全部非表示 |
# dig @127.0.0.1 www.yahoo.co.jp +noall +answer ; <<>> DiG 9.7.3-P3 <<>> @127.0.0.1 www.yahoo.co.jp +noall +answer ; (1 server found) ;; global options: +cmd www.yahoo.co.jp. 864 IN CNAME www.ya.gl.yahoo.co.jp. www.ya.gl.yahoo.co.jp. 24 IN A 124.83.187.140 |
+noall +answerを最後につけた場合、左記の3行のあと、その他はnoallの後でanswerが適用される |
●レコードの確認
SOAレコードの確認
digでは、DNSサーバを「@」に続けて指定します。ここではローカルホストへの問い合わせになるよう、「127.0.0.1」または「localhost」を指定します。/etc/resolv.confでネームサーバを自分自身にしている場合(注)は省略可能です。
domain example.jp
nameserver 127.0.0.1
さらに、調べたいドメインとレコードを指定します。引数の順序に決まりはありません。
$ /usr/local/bin/dig @127.0.0.1 example.jp soa ; <<>> DiG 9.2.1 <<>> @127.0.0.1 example.jp soa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11327 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;example.jp. IN SOA ;; ANSWER SECTION: example.jp. 86400 IN SOA dns.example.jp. root.example.jp. 2002122001 3600 900 604800 86400 ;; AUTHORITY SECTION: example.jp. 86400 IN NS dns.example.jp. ;; ADDITIONAL SECTION: dns.example.jp. 86400 IN A 192.168.10.1 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 22 20:16:30 2002 ;; MSG SIZE rcvd: 103
NSレコードの確認
同様に、NSレコードを確認してみます。レコードオプションに「ns」を指定してdigを実行します。
$ /usr/local/bin/dig @127.0.0.1 example.jp ns ;; QUESTION SECTION: ;example.jp. IN NS ;; ANSWER SECTION: example.jp. 86400 IN NS dns.example.jp. ;; ADDITIONAL SECTION: dns.example.jp. 86400 IN A 192.168.10.1
正引き情報の確認
digの引数に、調べたいドメインではなくホスト名をフルドメイン付き(FQDN)で指定します。Aレコードを調べる場合は、「a」を指定します。ちなみに、Aレコードの場合は指定を省略できます。
$ /usr/local/bin/dig @127.0.0.1 dns.example.jp a ;; QUESTION SECTION: ;dns.example.jp. IN A ;; ANSWER SECTION: dns.example.jp. 86400 IN A 192.168.10.1 ;; AUTHORITY SECTION: example.jp. 86400 IN NS dns.example.jp.
逆引き情報の確認
digでは通常、引数にドメイン名が来ることを期待します(つまりドメイン名指定がデフォルト)。IPアドレスを指定する場合は、「-x」オプションを使います。
Aレコードを調べる場合は、レコードオプションに「a」を指定し、これは省略可能だと説明しました。しかし、ここでは意図的に省略します。レコードオプション「a」を指定したときとそうでないときの挙動の違いを一度自分で確認してみましょう。どうしてそのような違いが生じるのかは、次回で説明します。
$ dig @127.0.0.1 -x 192.168.10.1 ;; QUESTION SECTION: ;1.10.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.10.168.192.in-addr.arpa. 86400 IN PTR dns.example.jp. ;; AUTHORITY SECTION: 10.168.192.in-addr.arpa. 86400 IN NS dns.example.jp. ;; ADDITIONAL SECTION: dns.example.jp. 86400 IN A 192.168.10.1
キャッシュサーバの動作確認
最後にキャッシュサーバの動作を確認します。外部のドメインを指定して、DNSが引けているかを確認します。
$ dig @127.0.0.1 www.hoge.co.jp ;; QUESTION SECTION: ;www.hoge.co.jp. IN A ;; ANSWER SECTION: www.hoge.co.jp. 85877 IN CNAME www.hoge.co.jp. www.hoge.co.jp. 85877 IN A 192.168.0.100 ;; AUTHORITY SECTION: hoge.co.jp. 85877 IN NS ns1.kokosu.ne.jp. hoge.co.jp. 85877 IN NS dns1.kokosu.ne.jp. hoge.co.jp. 85877 IN NS dns2.kokosu.ne.jp.
●逆引きの問い合わせについて
-x オプションを使用すると楽
IPv4アドレス
例) 124.83.179.227( = f10.top.vip.ogk.yahoo.co.jp )のPTRレコードを問い合わせる
[ 使用例 ]
-xオプションを使用しない場合
# dig 227.179.83.124.in-addr.arpa ptr ;; QUESTION SECTION: ;227.179.83.124.in-addr.arpa. IN PTR : ;; ANSWER SECTION: 227.179.83.124.in-addr.arpa. 675 IN PTR f10.top.vip.ogk.yahoo.co.jp. |
in-addr.arpaドメインでかつPTRを指定して問い合わせる PTRを省くとAレコードを問い合わせる |
-xオプションを使用する場合
# dig -x 124.83.179.227 ;; QUESTION SECTION: ;227.179.83.124.in-addr.arpa. IN PTR : ;; ANSWER SECTION: 227.179.83.124.in-addr.arpa. 900 IN PTR f10.top.vip.ogk.yahoo.co.jp. |
そのままアドレスをつけて問い合わせる デフォルトでPTRを問い合わせる |
IPv6アドレス
例) 2001:dc2:1000:2006::cafe( = www.nic.ad.jp )のPTRレコードを問い合わせる
[ 使用例 ]
-xオプションを使用しない場合
# dig @ns5.nic.ad.jp e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.2.0.0.0.1.2.c.d.0.192.168.0.2.ip6.arpa ptr ;; QUESTION SECTION: ;e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.2.0.0.0.1.2.c.d.0.192.168.0.2.ip6.arpa. IN PTR : ;; ANSWER SECTION: e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.2.0.0.0.1.2.c.d.0.192.168.0.2.ip6.arpa. 86400 IN PTR www.nic.ad.jp. |
ip6.arpaドメインでかつPTRを指定して問い合わせる アドレスは完全形式で指定 |
-xオプションを使用する場合
# dig @ns5.nic.ad.jp -x 2001:dc2:1000:2006::cafe ;; QUESTION SECTION: ;e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.2.0.0.0.1.2.c.d.0.192.168.0.2.ip6.arpa. IN PTR : ;; ANSWER SECTION: e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.6.0.0.2.0.0.0.1.2.c.d.0.192.168.0.2.ip6.arpa. 86400 IN PTR www.nic.ad.jp. |
デフォルトでPTRを問い合わせる アドレスは省略形式でも良い |
●TCPによる問い合わせ
通常、DNSの問い合わせはUDP53番宛に対して行われ、TC=1のビットが返ってきた場合は改めてTCP53番宛に問い合わせるようになっています(TCPフォールバック)。
しかし、digの+vcオプションを使用すると、いきなりTCP53番で問い合わせることができます。
問い合わせ先DNSサーバ(またはその手前にあるFWなど)がTCP53番を許可しているかどうかを調べるのによく利用します。TCP53番は、DNS問い合わせ以外にもゾーン転送でも利用しているので、ゾーン転送不可の原因を調べるのに役立ちます。
[ 使用例 ]
# dig @192.36.144.107 se. any ;; Truncated, retrying in TCP mode. : ;; MSG SIZE rcvd: 2716 |
通常はUDPで問い合わせ、応答サイズが512バイトを超えるとTCPに切り替わる 「;; Truncated, retrying in TCP mode.」は、TCPに切り替わったことを意味する |
# dig @192.36.144.107 se. any +vc : ;; MSG SIZE rcvd: 2716 |
+vcを付加すると、最初からTCPで問い合わせる サイズとEDNS0に関するコメントがないことから、UDPではなくTCPだとわかる +vcなしで応答があり、+vc付きでtime outになる場合は、サーバ側でTCP53番の着信を許可していない可能性有り |
# dig @192.168.24.60 example.co.jp axfr : ;; XFR size: 518 records (messages 1, bytes 8384) |
axfr(ゾーン転送)オプションでもTCP接続となる |
# dig @192.168.24.60 example.co.jp axfr : ;; connection timed out; no servers could be reached |
192.168.24.60のほうで、named.confではゾーン転送を許可しているが、iptablesで外部からのTCP53を許可していない場合しばらくたってからtime outになる |
●EDNS0による問い合わせ
EDNS0とは、応答サイズが512バイトを超えてもUDPで回答できるようにした拡張機能のことです。EDNS0での最大UDPサイズは4096バイトで、これを超える場合はTCPフォールバックによりTCPで再問い合わせが行われます。digの+bufsizeオプション、または+dnssecオプションを使うと、EDNS0を有効にすることができます。
[ 使用例 ]
# dig @192.36.144.107 se. any +bufsize=4096 : ; EDNS: version: 0, flags:; udp: 4096 : ;; MSG SIZE rcvd: 2727 |
+bufsize=数値は、相手のサーバにこちら側の受信可能サイズを通知する。相手サーバは、自分自身の最大送信サイズと比較して小さいほうを採用し、応答結果がそのサイズ内に収まる場合はUDPで返す。それを超える場合はTC=1をつけた上でUDPで返し、TCPフォールバックされる。 |
# dig @192.36.144.107 se. any +bufsize=2000 ;; Truncated, retrying in TCP mode. : ; EDNS: version: 0, flags:; udp: 4096 : ;; MSG SIZE rcvd: 2727 |
応答サイズが2727バイトに対して、こちら側の受信サイズを2000バイトとして実行した場合、受信サイズを超過してるので、TCPフォールバックが起こる |
# dig @192.36.144.107 se. any +dnssec : ; EDNS: version: 0, flags: do; udp: 4096 : ;; MSG SIZE rcvd: 4023 |
+dnssecをつけてもEDNS0が有効になる。+dnssecだけの場合は、+bufsize=4096がデフォルト |
●DNSSECによる問い合わせ
DNSSECで問い合わせる場合は、+dnssecオプションを付加します。+dnssecオプションを付加すると、自動的にEDNS0も有効になります(最大サイズ4096バイトに設定)。+bufsizeも併用してEDNS0の最大受信サイズを指定することもできます。
[ 使用例 ]
# dig @localhost se. any +dnssec : ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 26, AUTHORITY: 11, ADDITIONAL: 20 : ; EDNS: version: 0, flags: do; udp: 4096 : ;; MSG SIZE rcvd: 4094 |
+dnssecを付加するとEDNS0も有効になる。DNSSECによる検証に成功した場合は、adフラグが立つ。ローカルDNSに設定されているトラストアンカーはルートサーバで、ルートサーバから辿ってDNSSEC認証ができたことを示す。 |
# dig @192.36.144.107 se. any +dnssec : ;; flags: qr aa rd; QUERY: 1, ANSWER: 23, AUTHORITY: 0, ADDITIONAL: 23 : ; EDNS: version: 0, flags: do; udp: 4096 : ;; MSG SIZE rcvd: 4023 |
ローカルDNSが設定しているトラストアンカーはルートサーバのみなので、直接seを管理するDNSサーバに問い合わせてもDNSSEC検証ができないのでadフラグは立たない。 |
# dig @localhost se. any +dnssec +bufsize=2000 ;; Truncated, retrying in TCP mode. : ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 26, AUTHORITY: 11, ADDITIONAL: 17 : ; EDNS: version: 0, flags: do; udp: 4096 : ;; MSG SIZE rcvd: 4448 |
+bufsizeで2000バイトに制限した場合DNSSEC問い合わせでも、指定したEDNS0の受信サイズを超えればTCPフォールバックされる。 |
●BINDのバージョンの確認
digを使ってBINDのバージョンの確認ができます。
# dig @192.168.24.60 chaos version.bind txt : ;; QUESTION SECTION: ;version.bind. CH TXT : ;; ANSWER SECTION: version.bind. 0 CH TXT "9.7.3-P3" |
バージョンの問い合わせ<。named.confでversionの設定がされていない場合は、BINDのバージョンを返す |
# dig @192.168.24.60 chaos version.bind txt : ;; QUESTION SECTION: ;version.bind. CH TXT : ;; ANSWER SECTION: version.bind. 0 CH TXT "Not available." |
options { version "Not available."; };のように、named.confで設定されている場合は、digではバージョンの確認ができない。 |
# rndc status version: 9.7.3-P3 (Not available.) CPUs found: 1 worker threads: 1 number of zones: 20 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON recursive clients: 0/2900/3000 tcp clients: 0/100 server is up and running |
rndcコマンドであれば、named.confでバージョンを隠してもきちんと表示される |
●ルートDNSのトラストアンカーを取得する
DNSSEC対応の設定に必要なトラストアンカー(KSK公開鍵)を取得します。
# dig +noall +answer @a.root-servers.net . dnskey > /tmp/trust-key.txt # more /tmp/trust-key.txt . 172800 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= . 172800 IN DNSKEY 256 3 8 AwEAAcy4Eo1P5B3ut9Vm9ZP92JnCFSALJqdhO5fOq1UsseYaiMFqgDH6 Y40iqDw6JmpkmhiJLW6HGj//JLQXAJ+k4EcQ9tlDJqumEe7OJMU6KpcK s6qI4lugy8j/v6DxDlZdAPASbKmoGx1oceRKzr/UdwyB1G5aIEtwK7/D QFrn3zRj | ルートDNSからDNSKEYレコードを取得。トラストアンカーはKSK公開鍵のほうなので、DNSKY 257のほうを使う。 |
●権威DNSサーバのDNSSEC対応
参照
第4回 権威DNSサーバのDNSSEC対応
- キャッシュサーバのDNSSEC対応
- KSKの作成
- ZSKの作成
- ゾーンの署名
- 権威サーバのDNSSEC対応
- DSの上位サーバへの登録依頼
また、DS(Delegation Signer)はKSK公開鍵から求められる情報です。
実運用時には定期的にKSK、ZSKを更新し再署名、DSの再登録が必要となります。KSK、ZSKそれぞれについて事前公開法/二重署名法のどちらかを選択して行うなど複雑な作業になります。
また、注意深く行わないと最悪すべてのレコードの署名が不正となってしまいます。
では、KSK及びZSKを作成します。
# mkdir /var/named/keys
# chown named:named /var/named/keys
# chmod 770 /var/named/keys
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 2048 -r /dev/urandom -f KSK -P 20121220000000 -A 20121220000000 -I 20171231000000 bigbang.mydns.jp
Generating key pair.................................................+++ ..........+++
Kbigbnag.dyndns.org.+008+44500
ZSKの作成は下記のとおり
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20121220000000 -A 20121220000000 -I 20171231000000 bigbang.mydns.jp
Generating key pair........++++++ .........................++++++
Kbigbang.mydns.jp.+008+46530
# chown named:named /var/named/keys
# chmod 770 /var/named/keys
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 2048 -r /dev/urandom -f KSK -P 20121220000000 -A 20121220000000 -I 20171231000000 bigbang.mydns.jp
Generating key pair.................................................+++ ..........+++
Kbigbnag.dyndns.org.+008+44500
ZSKの作成は下記のとおり
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20121220000000 -A 20121220000000 -I 20171231000000 bigbang.mydns.jp
Generating key pair........++++++ .........................++++++
Kbigbang.mydns.jp.+008+46530
「key-signing key」と記載があるのががKSK鍵、「key-signing key」と記載があるのがZSK鍵になります。
管理しているゾーンに対して署名します。/var/named/keys以下に鍵が複数ある場合は、その数だけ署名されることになります。
# mkdir /var/named/zone
# chown named:named /var/named/zone
# chmod 770 /var/named/zone
# dnssec-signzone -a -S -x -K /var/named/keys -z -d /var/named/zone -3 1234567890 -e +5y -r /dev/urandom -N unixtime -o bigbang.mydns.jp /var/named/chroot/var/named/(署名したいファイル名)
Fetching KSK/ZSK 49804/RSASHA256 from key repository.
dnssec-signzone: warning: Serial number not advanced, zone may not transfer
Verifying the zone using the following algorithms: RSASHA256.
Zone signing complete:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 present, 0 revoked
/var/named/chroot/var/named/(署名したいファイル名).signed
# chgrp named /var/named/chroot/var/named/(署名したいファイル名).signed
# chown named:named /var/named/zone
# chmod 770 /var/named/zone
# dnssec-signzone -a -S -x -K /var/named/keys -z -d /var/named/zone -3 1234567890 -e +5y -r /dev/urandom -N unixtime -o bigbang.mydns.jp /var/named/chroot/var/named/(署名したいファイル名)
Fetching KSK/ZSK 49804/RSASHA256 from key repository.
dnssec-signzone: warning: Serial number not advanced, zone may not transfer
Verifying the zone using the following algorithms: RSASHA256.
Zone signing complete:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 present, 0 revoked
/var/named/chroot/var/named/(署名したいファイル名).signed
# chgrp named /var/named/chroot/var/named/(署名したいファイル名).signed
署名されたゾーンファイルを利用するように「named.conf」を変更します。
マスタDNSサーバのゾーンファイルの変更 zone "bigbang.mydns.jp" { type master; file "bigbang.mydns.jp.zone"; }; ↓ 変更 zone "bigbang.mydns.jp" { type master; file "bigbang.mydns.jp.zone.signed"; ← 変更 };設定完了後、namedを再起動します。この時、下記コマンドを実行しておかないとnamedサービスが起動しませんので注意してください。
# chgrp named /var/named/chroot/var/named/bigbang.mydns.jp.zone.signedセカンダリDNSサーバがある場合は、そちらの「named.conf」も変更します。
セカンダリDNSサーバのゾーンファイルの変更 zone "bigbang.mydns.jp" { type slave; file "slaves/bigbang.mydns.jp"; masters { 192.168.0.100; } ; }; ↓ 変更 zone "bigbang.mydns.jp" { type slave; file "slaves/bigbang.mydns.jp.signed"; ← 変更 masters { 192.168.0.100; } ; };設定完了後、namedを再起動します。
DNSSECが有効になっているか、digコマンドにより確認します。
# dig bigbang.mydns.jp -t NS +dnssec
; <<>> DiG 9.8.4-RedHat-9.8.4-2.fc16 <<>> bigbang.mydns.jp -t NS +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53345
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bigbang.mydns.jp. IN NS
;; ANSWER SECTION:
bigbang.mydns.jp. 86400 IN NS tree.bigbang.mydns.jp.
bigbang.mydns.jp. 86400 IN NS rock.bigbang.mydns.jp.
bigbang.mydns.jp. 86400 IN RRSIG NS 8 3 86400 20171219073318 20121220073318 49804
bigbang.mydns.jp. GekzDUZWIJRQrYmLjESN3MG9KbgE9g/ANswTO3nXlaPS9XR9ZGFHE4wz
WUT4ZZCd1k8IYW67sDvTm2fQBpG7Vb1Ips7F249IBH2B2TTGITSxao4S iPeEdME2p
(以下、省略)
; <<>> DiG 9.8.4-RedHat-9.8.4-2.fc16 <<>> bigbang.mydns.jp -t NS +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53345
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bigbang.mydns.jp. IN NS
;; ANSWER SECTION:
bigbang.mydns.jp. 86400 IN NS tree.bigbang.mydns.jp.
bigbang.mydns.jp. 86400 IN NS rock.bigbang.mydns.jp.
bigbang.mydns.jp. 86400 IN RRSIG NS 8 3 86400 20171219073318 20121220073318 49804
bigbang.mydns.jp. GekzDUZWIJRQrYmLjESN3MG9KbgE9g/ANswTO3nXlaPS9XR9ZGFHE4wz
WUT4ZZCd1k8IYW67sDvTm2fQBpG7Vb1Ips7F249IBH2B2TTGITSxao4S iPeEdME2p
(以下、省略)
権威DNSサーバの準備完了後、上位ゾーンと連携させ必要がありますこれは契約しているレジストラ(や指定事業者)に依頼することが多いと思われます。
DSレコードは、dnssec-signzoneコマンド実行後に、/var/named/zoneの下に「dsset-bigbang.mydns.jp.」というファイルとして出力されています。
bigbang.mydns.jp. IN DS 49804 8 1 DD5EAE8C5FE6B637D7644935A4A1D4F3704B9D95 bigbang.mydns.jp. IN DS 49804 8 2 95040CC79A7BB35F3750192F3BFCBBC6DDE1C245724517FD639857C3 9E5E01451行目は、ダイジェストアルゴリズムとしてSHA-1を使って生成されたDSレコードを、同様に2行目はSHA-256を使って生成されたDSレコードを表しています。信頼の連鎖を構築するためにレジストラ経由でこれらのレコードを登録することになります。
なお、DSレコードは、dnssec-dsfromkeyコマンドを使ってKSK公開鍵ファイルからも生成できます。
# dnssec-dsfromkey /var/named/keys/Kbigbang.mydns.jp.+008+49804.key bigbang.mydns.jp. IN DS 49804 8 1 DD5EAE8C5FE6B637D7644935A4A1D4F3704B9D95 bigbang.mydns.jp. IN DS 49804 8 2 95040CC79A7BB35F3750192F3BFCBBC6DDE1C245724517FD639857C3 9E5E0145レジストラに登録を依頼し、最終的に上位ゾーンにDSレコードが登録されると、上位ゾーンからの信頼の連鎖が構築され、そのゾーンが信頼されたものとなります。
詳細な設定は下記を参照してください。
Authoritative Service
●権威DNSサーバの運用
前項の作業で権威DNSサーバの構築が完了し、DNSSECに対応した状態となりました。
しかし、権威DNSサーバではそれ以降も、DNSSECに関連して定期的なメンテナンスが必要となってきます。基本的には下記3つの作業が定常的に発生することになります。
【1】再署名
署名の有効期間を定期的に再設定するために、再署名を実施します。
また、レコード追加などゾーンの内容に変更があった場合も、再署名を行う必要がある。再署名については、署名を行う場合と同様にdnssec-signzoneコマンドを用いればよいです。
# dnssec-signzone -a -S -x -K /var/named/keys -z -d /var/named/zone -3 1234567890 -e +5y -r /dev/urandom -N unixtime -o bigbang.mydns.jp /var/named/chroot/var/named/bigbang.mydns.jp.zone
【2】ZSKの作成・更新
ZSKやKSKは定期的に作成および更新する必要があります。鍵の作成手順については、初回の鍵生成とほぼ同様ですが、2回目以降の鍵の作成については事前公開の日付、署名に使い始める日付を、鍵の更新サイクルに合わせた形にする必要があります。
例えば、事前公開法によってZSKを運用し、初回のZSK生成から3週間後の時点で新しいZSKを事前公開するとしよう。その場合は下記のようなコマンドで新しいZSKを作成できる。
最初に作成
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20111201000000 -A 20111201000000 -I 20111231235959 bigbang.mydns.jp
更新時
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20111222000000 -A 20120101000000 -I 20120131235959 bigbang.mydns.jp
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20111201000000 -A 20111201000000 -I 20111231235959 bigbang.mydns.jp
更新時
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 1024 -r /dev/urandom -P 20111222000000 -A 20120101000000 -I 20120131235959 bigbang.mydns.jp
作成したZSKは3週間後の2011年12月22日00時00分00秒から事前公開され、2012年1月1日00時00分00秒から署名に使われることを表しています。
これらは再署名の時点で反映されるため、2011年12月20日00時00分00秒以降と2012年1月1日00時00分00秒以降に、再署名およびゾーン情報の再読み込みを行うとよいでしょう。

【3】KSKの作成・更新
ZSKと同様に、KSKも定期的に作成・更新する必要があります。こちらも作成作業自体は、基本的にはZSKの2回目の作成と同様です。
ただし、KSKは対応するDSレコードを上位ゾーンに登録しているため、KSKの更新とともにDSレコードの更新申請が必要となります。二重署名法を使ってKSKを運用する場合、DSレコードの再申請は、二重署名がされている期間中にする必要があります。
$ dnssec-keygen -K /var/named/keys -a RSASHA256 -b 2048 -r /dev/urandom -f KSK -P 20131201000000 -A 20131201000000 -I 201412310000 bigbang.mydns.jp

キーロールオーバー中には複数のZSKやKSKが存在するため、鍵を取り違えることのないよう、鍵タグを用いてきちんと区別するなどの注意が必要です。
●ゾーンサーバ
自身が所有するドメイン名をインターネットに広報するために必要なサーバです。「広報」という言葉を用いると、外部に対して能動的に働き掛けるように考えてしまいますが、実際には自ドメイン名に対する問い合わせ要求にこたえるもので、動作としては受動的です。「DNSの仕組みと運用(1)」をお読みいただければ、ルートサーバからドメインツリーをたどって手元のゾーンサーバに問い合わせが到達するか理解できると思います。
手元でサーバを立ち上げるにしろ、どこかに委譲するにせよ、ドメイン名を取得してそのドメインを自組織内外のインターネットで引けるようにするにはゾーンサーバが必要です。
また、ドメイン名解決を行う際に用いられるゾーンデータの出所によって、ゾーンサーバはさらに2つに大別されます。
-
マスター・ゾーンサーバ(またはマスターサーバ)
オリジナルとなるゾーンデータを所有するサーバです。オリジナルドメインを運用する際には必ず1つ用意します。ゾーンデータは、通常ローカルファイルを基にします。
- スレーブ・ゾーンサーバ(またはスレーブサーバ)
ゾーンデータをマスターサーバから複製して使用します。マスターサーバが停止しているときなどは、ローカルのゾーンファイルを読み込むことも可能ですが、通常はゾーン転送(zone transfer)と呼ばれる手法でゾーンデータを最新なものに保ちます。
●キャッシュサーバ
キャッシュサーバはクライアントから来る名前解決要求にこたえるもので、目的のドメインをリゾルブできるまで、外部のDNSをドメインツリーをたどって再帰検索します。
BIND 9の場合はゾーンサーバの機能も内包しているため、「自身のゾーンデータに該当しなかった場合」という条件が付きます。可能であれば、ゾーンサーバ用のBINDとキャッシュサーバ用のBINDは区別して運用することをお勧めします。
ゾーンサーバが外部からの問い合わせに対する受動的処理だったのに対し、キャッシュサーバは外部のDNSを参照する能動的なものになります。キャッシュサーバは一度問い合わせた情報をサーバ内のキャッシュに保存し、次に同じ問い合わせが来たときに高速に返答することができます。
また、BIND 9では単に問い合わせに成功した情報だけでなく、名前解決できなかったという情報をキャッシュする「否定キャッシュ」(ネガティブキャッシュ)も備えています。これらの問い合わせキャッシュがどれくらいの期間有効なのかも運用には大事な要素になってきますが、そちらについては「TTL」というキーワードとともに紹介します。
named.confの編集
キャッシュサーバに特化した設定項目を見ていきます。
# vi /etc/named.conf acl bigbang-net { ① 192.168.0.0/27; 127.0.0.1; }; options { directory "/var/named"; pid-file "/var/run/named/named.pid"; recursion yes; ② }; zone "." { type hint; file "named.ca"; }; zone "localhost" { type master; file "local.zone"; }; zone "0.0.127.in-addr.arpa" { type master; file "local.rev"; };①はネットワーク環境に合わせて指定するアドレスレンジを変更してください。
アクセス制御用センテンス。宣言名「bigbang-net」は適当に変更可能
プライベートネットワーク内からのみアクセスを許可
自分自身からの問い合わせを許可
キャッシュサーバという用途を考えると、この指定は必須です。キャッシュサーバが外部のネットワークから使用されるのは不本意です。もしファイアウォールやNATボックス内にDNSキャッシュサーバを設置できるのであれば、外部からのアクセスは一切不要にしても構いません。キャッシュサーバ自身が外部に問い合わせることがあっても、外部からキャッシュサーバに対する何らかの接続が発生することはありません。
②は「yes」にすることで、ドメインツリーの再帰問い合わせを有効にします。つまり、外部のさまざまなドメインに対して返答が可能になります。もしゾーンサーバの機能だけを提供するDNSであればここは「no」とし、自身で管理している(権威を持っている)ドメイン以外の応答には答えないようにすべきです。
bigbang.mydns.jpの順引きや192.168.10.0/24の逆引きの設定は、キャッシュサーバには不要です。
なお、localhost(127.0.0.1)に関する指定とルートサーバに関する情報はどの場合も必要となります。
キャッシュデータの確認
上記の場合なら、named.ca、local.zone、local.rev、named.pidを準備します。後は、namedを起動あるいは再起動するのみです。
# service named restart次に、digコマンドを使ってキャッシュデータを確認します。
$ dig @127.0.0.1 www.bigbang.mydns.jp ;; QUESTION SECTION: ;www.bigbang.mydns.jp. IN A ;; ANSWER SECTION: www.bigbang.mydns.jp. 86400 IN CNAME www2.bigbang.mydns.jp. www2.bigbang.mydns.jp. 86400 IN A 192.168.0.100 ;; AUTHORITY SECTION: bigbang.mydns.jp. 86400 IN NS dns1.kokosu.ne.jp. bigbang.mydns.jp. 86400 IN NS dns2.kokosu.ne.jp. bigbang.mydns.jp. 86400 IN NS ns1.kokosu.ne.jp.数秒待ってから、同じようにdigコマンドを発行します。
$ dig @127.0.0.1 www.bigbang.mydns.jp ;; QUESTION SECTION: ;www.bigbang.mydns.jp. IN A ;; ANSWER SECTION: www.bigbang.mydns.jp. 86373 IN CNAME www2.bigbang.mydns.jp. www2.bigbang.mydns.jp. 86373 IN A 192.168.0.100 ;; AUTHORITY SECTION: bigbang.mydns.jp. 86373 IN NS dns2.kokosu.ne.jp. bigbang.mydns.jp. 86373 IN NS ns1.kokosu.ne.jp. bigbang.mydns.jp. 86373 IN NS dns1.kokosu.ne.jp.TTLの値が減っていることが分かります。この値が0になるまで、キャッシュデータが参照されます。
キャッシュサーバに有効な設定
キャッシュサーバには、「recursion yes」以外にも有効な設定がいくつか用意されています。先ほど Windows 2000/XPのDNSキャッシュ機能に触れた際、TTL/ネガティブキャッシュTTLともに、Windows内であらかじめ決められた値で上限を切ることができると説明しました。BIND 9で同じことができないわけがありません。BIND 9では以下のようにnamed.confファイル中のoptionsステートメントで指定します。
options { directory "/var/named"; pid-file "/var/run/named/named.pid"; recursion yes; max-ncache-ttl 300; (1) max-cache-ttl 3600; (2) lame-ttl 600; (3) };注:(2)の値はdigコマンドによるTTL値の検証のために極端に小さくしています。
(1)はネガティブキャッシュの最大TTLを指定しています。指定がない場合は10800秒(3時間)になります。通常、キャッシュのTTLの最大値は(2)のように指定します。指定がない場合のデフォルト値は604800秒(1週間)です。(3)のLame TTLについては次回以降Lameキーワードとともに説明します。
設定を変更したらnamedを再起動し、再度digコマンドでキャッシュデータのTTL値を確認してみましょう。
# dig @127.0.0.1 www.bigbang.mydns.jp
;; QUESTION SECTION:
;www.bigbang.mydns.jp. IN A
;; ANSWER SECTION:
www.bigbang.mydns.jp. 3600 IN CNAME www2.bigbang.mydns.jp.
www2.bigbang.mydns.jp. 3600 IN A 192.168.0.100
;; AUTHORITY SECTION:
bigbang.mydns.jp. 3600 IN NS ns1.kokosu.ne.jp.
bigbang.mydns.jp. 3600 IN NS dns1.kokosu.ne.jp.
bigbang.mydns.jp. 3600 IN NS dns2.kokosu.ne.jp.
●DNS関係の用語
-
リゾルバ
名前解決と同じ意味で使用しています。
-
ルートサーバ
ネームサーバの総元締。現在13拠点で稼働しており、変更される場合もあります。ルートサーバを起点としてドメインツリーが展開されます。ルートサーバ一覧の入手方法は次回で解説します。
-
正引き
ドメイン名からIPアドレスやネームサーバ、メールサーバのドメイン付きホスト名を検索する手順を指します(例:www.hoge.co.jp → 192.168.0.1)。本連載では、ホスト名をフルドメイン付きで表現することをFQDN(Fully Qualified Domain Name)と表記します。
-
逆引き
IPアドレスからドメイン名を検索する手順を指します(例:192.168.0.1 → www.hoge.co.jp)。
●TTLとネガティブキャッシュ
TTLはデフォルトのキャッシュ有効期限(Time To Live:TTL)を指定するものです。SOAレコードの中にもTTLの値を見つけることができます。これを理解するには、キャッシュの機能を理解する必要があります。
通常、キャッシュサーバはDNS問い合わせに成功したもの、すなわち「www.hoge.co.jp→172.17.100.1(または172.17.100.1→www.hoge.co.jp)」の結果をー時的に蓄えます。その一方で、「dummy.hoge.co.jp→NXDOMAIN(ドメインが存在しない)」といった、失敗した結果をキャッシュする「ネガティブキャッシュ」も併せ持っています。
2つのキャッシュの性質を考えると、同じTTLの値を使用するのはあまり有効ではありません。そこで、RFC 2308(http://www.ietf.org/rfc/rfc2308.txt?number=2308)で新たにネガティブキャッシュが定義されました。
これを受けて、BIND 8.2以降ではいままでのSOAレコードにあるデフォルトTTLの値をネガティブキャッシュ用のTTLとし、新たに$TTL行を設けてゾーンデータのデフォルトTTLの値を指定するようにしました。また、ゾーン全体に対してTTLを設定する以外に、レコードごとの指定もできます。これにより、変更を予定しているホストのレコードは個別にTTLを短くする、といったことが可能になります。
;通常 hoge.example.jp IN A 192.168.0.23 ;TTLに3時間を指定した場合 hoge.example.jp 10800 IN A 192.168.0.23
●クラスC未満での逆引き設定
逆引きドメインツリーでは、IPアドレスの第3オクテット以下を分割することはできません。1(または0)から255までを1つのゾーンファイルに収める必要があります。しかし、これではクラスC未満でIPアドレスを割り当てられた場合は、割り当てIPをクラスC単位で管理するネットワーク事業者にいちいち修正依頼することになります。

そこで、クラスCの逆引きを管理するネットワーク事業者側の逆引きゾーン情報にサブドメインとCNAMEを用いることで、見かけ上はクラスC未満で割り振られた各契約者側で逆引き情報を管理できます。
まず、ネットワーク事業者側のnamed.confファイルおよびゾーンファイルから見ていきましょう。
zone "20.168.192.in-addr.arpa" { type master; file "example.rev"; ← ファイル名は何でも構わない }; ネットワーク事業者のnamed.confに追加される記述
$TTL 86400 @ IN SOA ns1.example.jp. root.example.jp. ( 2002122001 ; serial 3600 ; refresh 1hr 900 ; retry 15min 604800 ; expire 1w 86400 ; min 24hr ) IN NS ns1.example.jp. IN NS ns2.example.or.jp. ; ; 一般的な逆引きの場合 101 IN PTR pc1.example.jp. 102 IN PTR pc2.example.jp. 103 IN PTR pc3.example.jp. 104 IN PTR pc4.example.jp. 105 IN PTR pc5.example.jp ; ; ; 顧客Aのための設定 sub-a IN NS ns.example-a.jp. ← 「sub-a」はそれぞれのネットワーク事業者で決められる 1 IN CNAME 1.sub-a.20.168.192.in-addr.arpa. 2 IN CNAME 2.sub-a.20.168.192.in-addr.arpa. 3 IN CNAME 3.sub-a.20.168.192.in-addr.arpa. ; ; 顧客Bのための設定 sub-b IN NS ns.example-b.jp. 8 IN CNAME 8.sub-b.20.168.192.in-addr.arpa. 9 IN CNAME 9.sub-b.20.168.192.in-addr.arpa. ネットワーク事業者のexample.rev
named.confは、一般的なクラスCでの逆引き定義と変わりません。「file」には、それぞれのルールに合わせて任意のファイル名を指定します。
ここで指定されたゾーンファイルexample.revを見てみると、IPアドレスに対するホスト名の指定に用いられるPTRの行があり、各顧客に割り当てているIPレンジにはCNAMEが使われています。そのCNAMEで指定された先に、IPアドレスの第4オクテット目「.sub-a.20.168.192.in-addr.arpa.」が指定されています。通常のin-addr.arpa.の使い方ではクラスCまでしか指定できないため、独自にサブドメインを設け、見かけ上クラスC未満のアドレスをそれぞれのIP割り当て先(この場合は顧客Aや顧客B、C)のDNSに委譲しています。その際、サブドメインに対する「NS」をそれぞれ顧客のDNSに向けているわけです。

zone "sub-a.20.168.192.in-addr.arpa" { type master; file "example-a.rev"; ← ファイル名は何でも構わない }; 顧客Aのnamed.conf
$TTL 86400
@ IN SOA ns.example-a.jp. root.example-a.jp. (
2002122001 ; serial
3600 ; refresh 1hr
900 ; retry 15min
604800 ; expire 1w
86400 ; min 24hr
)
IN NS ns.example-a.jp.
;
; 一般的な逆引き
1 IN PTR sv1.example-a.jp.
2 IN PTR sv2.example-a.jp.
顧客Aのexample-a.rev
named.confのゾーンの指定は、ネットワーク事業者が決めたサブドメイン(sub-a)付きのもので指定されています。逆引き用のゾーンファイル(example-a.rev)は至って一般的なものです。ここにきて、ようやく192.168.20.1のIPアドレスに対するホスト名が解決されるわけです。
digコマンドを使って確認してみましょう。1.sub-a.20.168.192.in-addr.arpa.を経てsv1.example-a.jp.に到着することが分かります。
$ dig @127.0.0.1 -x 192.168.20.1 ;; QUESTION SECTION: ;1.20.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.20.168.192.in-addr.arpa. 86400 IN CNAME 1.sub-a.20.168.192.in-addr.arpa. 1.sub-a.20.168.192.in-addr.arpa. 86400 IN PTR sv1.example-a.jp.皆さんが固定IPアドレスをレンジで取得する際は、ネットワーク事業者(ほとんどがプロバイダですが)から割り当てられるIPを使用し、逆引きDNSの作成方法もそれぞれのネットワーク事業者に従うことになります。とはいえ、多くはここで紹介した方法が取られています。サブドメインの命名規則が独特のものになっているため、ネットワーク事業者ごとにさまざまなルールが存在しているように見えますが、事業者側でどのようにやっているかが分かれば、理解が早くなると思います。
●サブドメインの運用と委任
大規模なサイトでは、「サブドメイン」によって実組織を模したドメイン構成をとることがあります。その際、サブドメインの管理を「委任」することが可能です。
DNSは、「ドメインツリー」と呼ばれるトップダウンの木構造を成しています。example.jpドメインを取得した場合、example.jpゾーン情報を持つDNSサーバのアドレスやホスト名を、jpゾーンを管理する上位DNSサーバに登録する必要があります。
ゾーン情報(例ではexample.jp)を持つDNSサーバのアドレスやホスト名を、その上位ドメイン(例ではjp)のゾーン情報を管理するDNSサーバに登録する手順こそが「委任」(delegation)です。
上位ドメインを管理する側(以降「親」)は、その下位ドメイン(以下「子」)のゾーン情報をすべて持たず、子のゾーン情報が得られるDNSサーバのみを把握しています。つまり、「子ゾーンに関する情報は××DNSサーバに聞いてくれ」と、権限を委譲するわけです。これにより、親サーバが子ゾーンの情報であふれることなく、また子サーバはゾーン情報の変更のたびに親に変更を依頼する必要から解放されます。
親と子は相対的な関係です。取得した自ドメインを親とし、独自に子ドメインを作成することも可能です。この場合は、「サブドメイン」といった方が一般的でしょう。会社や団体などの組織であれば、部署や部門でサブドメインを分割するのが一般的ですが、まずサブドメイン導入の是非を確認するといいでしょう。
個人や小規模のコミュニティであれば、サブドメインの必要性はほとんどないでしょう。サブドメイン化し、ゾーン情報を分散化させなければならないほどホストを抱えているわけでもなく、各部門で管理できるドメインが必要になるという事態になる可能性もまれです。サブドメインが必要になるのは、ゾーン情報を分散化させる必要が生じるほどホスト情報がある場合や、組織的なしがらみで自由度の高いドメインを各内部組織に渡す必要がある場合です。サブドメイン化すれば、管理対象のホストはサブドメイン側で管理されるので、ホスト情報の更新頻度も軽減されます。また、親のゾーン情報も小規模になります。
注意しなければならないのは、サーバ側の負荷は削減されても、親ドメインの管理者にはより厳格な運用が要求されるということです。親ドメインの管理者はサブドメインのゾーン情報をケアしなくてもいい分、サブドメインが正しく運用されているか、各サブドメイン管理者に対して十分に周知する必要があります。ホスト名の命名規則を作成・徹底するのもいいでしょう。
委任しないサブドメイン運用
サブドメインの運用に当たって、すべてのサブドメインに委任先となるDNSを立てる必要はありません。組織の規模や管理手法によっては委任を利用せず、親ドメイン内で完結させることもできます。サブドメインが管理するゾーン情報の更新頻度が比較的低い場合や、サブドメインを運用できる担当者やサーバなどの資源に恵まれない場合は、この方法が有効的です。
例として、example.jpドメインにサブドメインとして「secretary.example.jp」を新設してみましょう。secretary.example.jpに属するホスト情報は次のとおりです。
pc1.secretary.example.jp | 192.168.10.50 | |
pc2.secretary.example.jp | 192.168.10.51 | |
mail.secretary.example.jp | 192.168.10.52 | secretary.example.jpドメインのメールサーバ |
www.secretary.example.jp | pc1.secretary.example.jpの別名 | secretary.example.jpドメインのwwwサーバ |
基本的なサブドメインの設定
最も簡単な方法は、親(example.jp)のゾーンファイルに子(secretary.example.jp)のホスト情報を持たせることです。
$TTL 86400
@ IN SOA dns.example.jp. root.example.jp. (
2003052001 ; serial
3600 ; refresh 1hr
900 ; retry 15min
604800 ; expire 1w
86400 ; min 24hr
)
IN NS dns.example.jp.
dns IN A 192.168.10.1
pc1 IN A 192.168.10.11
pc2 IN A 192.168.10.12
pc3 IN A 192.168.10.13
pc4 IN A 192.168.10.14
pc5 IN A 192.168.10.15
(ここから追加分)
pc1.secretary IN A 192.168.10.50
pc2.secretary IN A 192.168.10.51
mail.secretary IN A 192.168.10.52
secretary IN MX 10 mail.secretary
www.secretary IN CNAME pc1.secretary
親のexample.zoneファイル
ホスト名の最後の「.」を省略すると、ゾーンファイルの起点名が補完されます。例ではnamed.confで「example.jp」を起点名に指定(注)しているため、下記のようにFQDNで指定した場合と同じように振る舞います。特に、MXレコードの指定ではドメイン名そのものをレコードの左辺に指定しています。
pc4.example.jp. IN A 192.168.10.14 pc5.example.jp. IN A 192.168.10.15 (ここから変更分) pc1.secretary.example.jp. IN A 192.168.10.50 pc2.secretary.example.jp. IN A 192.168.10.51 mail.secretary.example.jp. IN A 192.168.10.52 secretary.example.jp. IN MX 10 mail.secretary.example.jp. www.secretary.example.jp. IN CNAME pc1.secretary.example.jp. 親の/var/named/example.zoneファイル
注:/etc/named.confで、 zone "example.jp" { type master; file "example.zone"; }; と指定されています。
$ dig www.secretary.example.jp (省略) ;; ANSWER SECTION: www.secretary.example.jp. 86400 IN CNAME pc1.secretary.example.jp. pc1.secretary.example.jp. 86400 IN A 192.168.10.50同様の手順で、MXやNSレコードの確認も行います。うまくいかないときは、/var/log/messagesのエラーを参考に、ゾーンファイルに問題がないか確認します。
$ORIGINを使用したサブドメインの設定
named.confで指定したデフォルトの起点名を意図的に変更するには、$ORIGINステートメントを用います。$ORIGINステートメント以降は、ホスト名の最後の「.」を省略した際に補完されるドメイン名が、$ORIGINの右辺(secretary.example.jp.)に変更されます。ただし、MXはFQDNを指定する必要があります。
また、$ORIGINで起点名を変更すると、再度$ORIGINで起点名を定義し直さない限り、行末まで指定した起点名が有効になります。
pc4 IN A 192.168.10.14 pc5 IN A 192.168.10.15 (ここから変更分) $ORIGIN secretary.example.jp. pc1 IN A 192.168.10.50 pc2 IN A 192.168.10.51 mail IN A 192.168.10.52 secretary.example.jp. IN MX 10 mail (注) www IN CNAME pc1 親のexample.zoneファイル
注:@表記を用いて、 @ IN MX 10 mail とすることもできます。FQDNと起点名が同じ場合は「@」で代替します。
$ORIGINに$INCLUDEを併用した設定
$INCLUDEステートメントを利用することで、サブドメイン「secretary.example.jp」の情報を別ファイルに分離し、親のゾーンファイルに挿入させることができます。サブドメインのゾーンファイルはexample.zoneと同じディレクトリ(ここでは/var/named)に保存し、記述する内容は「$ORIGINを使用したサブドメインの設定」と同じにします。サブドメイン情報を別ファイルとすることで、ゾーンファイルの編集中に親ドメインとサブドメインの整理がつかなくなるなどの煩わしさがなくなります。
pc4 IN A 192.168.10.14 pc5 IN A 192.168.10.15 (ここから変更分) $ORIGIN secretary.example.jp. $INCLUDE secretary.example.zone 親の/var/named/example.zoneファイル pc1 IN A 192.168.10.50 pc2 IN A 192.168.10.51 mail IN A 192.168.10.52 secretary.example.jp. IN MX 10 mail (注) www IN CNAME pc1 親のsecretary.example.zoneファイル
注:@表記を用いた、 @ IN MX 10 mail と同等です。
$INCLUDEの2番目の引数に起点名を指定することで、記述をさらに簡潔にできます。簡素化とともに、起点名の変更がその1行(読み込むファイルに対してのみ)に限定できるため、$INCLUDEの次の行はデフォルトの起点名(例ではexample.jp)のままにすることが可能です。
pc4 IN A 192.168.10.14 pc5 IN A 192.168.10.15 (ここから変更分) s$INCLUDE secretary.example.zone ecretary.example.jp.注:/var/named/secretary.example.zoneは「$ORIGINに$INCLUDEを併用した設定」と同じように用意しておきます。
専用のゾーンファイルを用意する方法
BIND 9では、サブドメイン専用のゾーンファイルを定義できます。これまでの方法は、親のSOAをそのまま引き継ぎますが、専用のゾーンファイルを用意すればサブドメイン専用のSOAを定義できます。
zone "secretary.example.jp" { type master; file "secretary.example.zone"; }; 親の/etc/named.confに追加 $ttl 38400 @ IN SOA dns01.secretary.example.jp. root.secretary. example.jp. ( 2003052001 10800 3600 604800 38400 ) IN NS dns01.example.jp. IN NS dns02.example.jp. IN MX 10 mail.secretary.example.jp. pc1 IN A 192.168.10.50 pc2 IN A 192.168.10.51 mail IN A 192.168.10.52 www IN CNAME pc1.secretary.example.jp. 親に/var/named/secretary.example.zoneファイルを用意ゾーン転送やゾーンファイルの自動更新でゾーン情報を同期している場合、サブドメイン専用にゾーンファイルを定義すると、サブドメイン分はスレーブ側に反映されません。ゾーン転送を使用している場合は、スレーブサーバ側に以下のような設定を追加します。
zone "secretary.example.jp" {
type slave;
masters {
マスター・サーバのIPアドレス;
};
file "secretary.example.zone.bak";
};
親(スレーブ)の/etc/named.confに追加
以上が、委任せずに親ドメイン内でサブドメインの設定を完結させる手法です。ここでは正引きのみ説明しましたが、逆引きも通常どおり行いましょう。
$TTL 86400
@ IN SOA dns.example.jp. root.example.jp. (
2003052001 ; Serial
3600 ; Refresh
900 ; Retry
604800 ; Expire
3600 ) ; Minimum
IN NS dns.example.jp.
1 IN PTR dns.example.jp.
11 IN PTR pc1.example.jp.
12 IN PTR pc2.example.jp.
13 IN PTR pc3.example.jp.
14 IN PTR pc4.example.jp.
15 IN PTR pc5.example.jp.
(追加分)
50 IN PTR pc1.secretary.example.jp.
51 IN PTR pc2.secretary.example.jp.
52 IN PTR mail.secretary.example.jp.
●あるサーバが倒れてから名前解決が遅くなった
原因は、名前解決が遅くなったマシンで障害のため存在していないサーバのIPアドレスを/etc/resolev.confの最初のレコードに設定していたためだった。
この行を削除し、別ネームサーバに変更したところ正常な状態に戻りました。
●プライマリDNS、セカンダリDNSを設定しているにもかかわらずSSH接続が遅い
デフォルトゲートウェイが変わったためによるものだった。デフォルトゲートウェイを修正。
●named-sdbによる高負荷
2012年12月初旬、Cactiのグラフを確認していたところ、あるPCがいつの間にか高負荷の状態になっていることが分かりました。

topコマンドで確認してみると、「named-sdb」が該当しています。
# top top - 13:29:24 up 9 days, 4:05, 2 users, load average: 1.25, 1.13, 1.08 Tasks: 219 total, 1 running, 218 sleeping, 0 stopped, 0 zombie Cpu(s): 21.7%us, 44.0%sy, 0.0%ni, 33.9%id, 0.0%wa, 0.2%hi, 0.2%si, 0.0%st Mem: 3087884k total, 2614728k used, 473156k free, 358432k buffers Swap: 5177340k total, 0k used, 5177340k free, 1431148k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7741 named 20 0 63732 14m 3116 S 141.5 0.5 324:41.17 named-sdb 1 root 20 0 6804 3892 2068 S 0.0 0.1 0:05.08 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.04 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 1:14.21 ksoftirqd/0 6 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 7 root RT 0 0 0 0 S 0.0 0.0 0:00.23 watchdog/0 8 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/1 10 root 20 0 0 0 0 S 0.0 0.0 1:15.73 ksoftirqd/1ログを確認します。
Dec 5 09:38:04 neko named-sdb[7741]: managed-keys.bind.jnl: create: permission denied Dec 5 09:38:04 neko named-sdb[7741]: managed-keys-zone ./IN: sync_keyzone:dns_journal_open -> unexpected errorインターネットで検索したところ、下記の作業をすれば良いことが分かりました。
# vi /etc/named.conf
(途中省略)
dnssec-enable yes;
managed-keys-directory "/var/named/dnssec";
dnssec-validation yes;
dnssec-lookaside auto;
(途中省略)
DNSSECのキーファイルの保存フォルダを作成します。
# cd /var/named/chroot/var/named # mkdir dnssec # chown named:named dnssec # chmod 700 dnssec # service named restart
これで高負荷が改善されました。
●It's world writable or writable by group which is not "root"が出力された場合の対処方法
crondの動作時に正常に動作しなかった場合root宛にメールが送られてきます。いつからかnamedのログローテションが正常に動作していない内容のメールが送信されてくるようになりました。
/etc/cron.daily/logrotate:
error: skipping "/var/named/data/named.run" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/xfer.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/queries.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/update.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/lame-servers.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/data/named.run" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/xfer.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/queries.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/update.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
error: skipping "/var/named/chroot/var/log/lame-servers.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.
この時のログローテションの内容は下記のとおりです。
# cat /etc/logrotate.d/named /var/named/data/named.run { missingok create 0644 named named postrotate /sbin/service named reload 2> /dev/null > /dev/null || true endscript }エラーが表示されるかどうか確認します。
# logrotate -v /etc/logrotate.d/named
reading config file /etc/logrotate.d/named
Handling 1 logs
rotating pattern: /var/named/data/named.run 1048576 bytes (no old logs will be kept)
empty log files are rotated, old logs are removed
considering log /var/named/data/named.run
error: skipping "/var/named/data/named.run" because parent directory has insecure permissions \
(It's world writable or writable by group which is not "root") \
Set "su" directive in config file to tell logrotate which user/group should be used for rotation.\
not running postrotate script, since no logs were rotated
これを下記のように変更しました。
# cat /etc/logrotate.d/named /var/named/data/named.run { missingok su named named create 0644 named named postrotate /sbin/service named reload 2> /dev/null > /dev/null || true endscript }確認しています。
# logrotate -v /etc/logrotate.d/named reading config file /etc/logrotate.d/named Handling 1 logs rotating pattern: /var/named/data/named.run 1048576 bytes (no old logs will be kept) empty log files are rotated, old logs are removed switching euid to 25 and egid to 25 considering log /var/named/data/named.run log /var/named/data/named.run does not exist -- skipping not running postrotate script, since no logs were rotated switching euid to 0 and egid to 0エラーが表示されていないので大丈夫なようです。
●isc_stdio_open '/var/log/named/queries.log' failed: file not foundが出力される
namedを再起動すると/var/log/messagesに下記のようなエラーが記録されていることに気が付きました。
Aug 17 13:37:03 nezumi named-sdb[18752]: isc_stdio_open '/var/log/xfer.log' failed: file not found Aug 17 13:37:03 nezumi named-sdb[18752]: isc_stdio_open '/var/log/update.log' failed: file not found Aug 17 13:37:03 nezumi named-sdb[18752]: isc_stdio_open '/var/log/queries.log' failed: file not found Aug 17 13:37:03 nezumi named-sdb[18752]: isc_stdio_open '/var/log/lame-servers.log' failed: file not found出力先のログファイルを作成し、権限を与えました。
# cd /var/named/chroot/var/log # touch xfer.log update.log queries.log lame-servers.log # chgrp named xfer.log update.log queries.log lame-servers.log # chmod g+w xfer.log update.log queries.log lame-servers.log
●slaveのzoneファイルの内容をチェックする方法
raw形式のzoneファイルの内容をチェックする方法は下記のとおりです。
# named-checkzone -D -f raw <ZONE_NAME> <ZONE_FILE_NAME>例えばnamed.confに下記のように記載されている場合
zone "bigbang.mydns.jp" { type slave; file "slaves/bigbang.mydns.jp.slave"; masters { 192.168.0.1; } ; }; zone "0.168.192" { type slave; file "slaves/0.168.192.in-addr.arpa.slave"; masters { 192.168.0.1; } ; };正引きのZONE_NAMEは「bigbang.mydns.jp」、ZONE_FILE_NAMEは「bigbang.mydns.jp.slave」
逆引きのZONE_NAMEは「0.168.192」、ZONE_FILE_NAMEは「0.168.192.in-addr.arpa.slave」
となります。これらを確認するには下記のコマンドを実行します。
正引きの場合 # named-checkzone -D -f raw bigbang.mydns.jp /var/named/chroot/var/named/slaves/bigbang.mydns.jp.slave 逆引きの場合 # named-checkzone -D -f raw 0.168.192 /var/named/chroot/var/named/slaves/0.168.192.in-addr.arpa.slave
●セカンダリのゾーンファイルをtext形式にする方法
named.conf内のzone{};内にmasterfile-format text;を記述すればtext形式になります。text形式にすると、起動パフォーマンスが低下するようです。多くのゾーンを管理しているDNSサーバではraw形式方がいいのかもしれません。
下記がサンプルです。
// We are a slave server for hoge.com zone “hoge.com” { type slave; masterfile-format text; file “hoge.com.zone”; // IP address of hoge.com master server masters { 192.168.0.1; }; };全てのゾーンファイルをtext形式にしたい場合は、zone{};の中ではなく、named.confやnamed.conf.optionsに「masterfile-format text;」を記載します。
●validatingと言うログ
参考URL:BINDのログで溢れてた。
以前DNSSECを試用していた設定が残っていたため下記のようなログがたまに記録されていました。
Sep 6 09:16:37 neko named[2890]: validating @0x7f0da4b89190: com.cn SOA: no valid signature found
Sep 6 09:16:37 neko named[2890]: validating @0x7f0dac367b30: GICE14DNTMDN31G43AUGVRKTKALVB8QC.com.cn NSEC3: no valid signature found
Sep 6 09:16:37 neko named[2890]: validating @0x7f0dac367b30: MI2OUBFA49Q47917BR600DOL1QGRP79T.com.cn NSEC3: no valid signature found
Sep 6 09:16:37 neko named[2890]: validating @0x7f0dac367b30: UQROTQK62NOIM5U43DMF7AMC8JJFRM7T.com.cn NSEC3: no valid signature found
Sep 6 09:16:37 neko named[2890]: validating @0x7f0dac367b30: GICE14DNTMDN31G43AUGVRKTKALVB8QC.com.cn NSEC3: no valid signature found
Sep 6 09:16:37 neko named[2890]: validating @0x7f0dac367b30: MI2OUBFA49Q47917BR600DOL1QGRP79T.com.cn NSEC3: no valid signature found
Sep 6 09:16:37 neko named[2890]: validating @0x7f0dac367b30: UQROTQK62NOIM5U43DMF7AMC8JJFRM7T.com.cn NSEC3: no valid signature found
named.confを下記のように変更しました。
# vi /var/named/chroot/etc/named.conf
dnssec-validation no;
# systemctl reloal named-chroot
●unexpected RCODE REFUSEDというログを記録させないようにする方法
参考URL:Bind - lame server resolving をログから消すには
lame-servers.logに下記のようなログが記録されていました。
lame-servers: info: error (unexpected RCODE REFUSED) resolving '62.227.159.115.in-addr.arpa/PTR/IN': 123.206.229.89#53このようなログを記録しないよう下記の対処を施しました。
# vi /var/named/chroot/etc/named.conf logging { category lame-servers { null; }; }; # systemctl named-chroot restartただし、「攻撃の意思を持つアクセスを特定するためにBINDのログを監視する」という意味でログを記録している場合もありますので、せっていには注意する必要があります。
●dumping master file
セカンダリDNSサーバ構築時に下記のような転送エラーが記録されていました。
Dec 17 16:31:42 tori named[87894]: dumping master file: slave/tmp-JQPspLEEaV: open: file not found Dec 17 16:31:42 tori named[87894]: dumping master file: slave/tmp-zYcOgmp0rA: open: file not found Dec 17 16:31:42 tori named[87894]: dumping master file: slave/tmp-nagHqCW2ON: open: file not foundnamed.confを確認したところ、3箇所記載間違いがありました。
zone "bigbang.mydns.jp" {
type slave;
file "slave/bigbang.mydns.jp";
masters { 192.168.0.1; };
};
slaveをslavesに修正後、restartし正常に転送されるようになりました。