｢スレーブDNSサーバのゾーンファイルが文字化けしてて読めない｣
｢どうやって確認すればいいの？｣
こんにちは、キクです。
僕は以前DNSサーバのマスター/スレーブを両方構築した際に、次のような状況に陥った経験があります。
｢スレーブ側の設定も終わったし、マスター側から転送されてきたゾーンファイルの中身が問題ないかcatコマンド確認してみよう｣
｢おっと、文字化けして読めないじゃないか･･･｣
DNSサーバに慣れ親しんでいる人にとっては一般的な内容かもしれませんが、当時の僕はそんなことを全然知りませんでした。
というわけで今回は『スレーブDNSサーバにおけるゾーンファイルの確認方法』をテーマに書いていきたいと思います！
本記事の内容
それでは、よろしくお願いします。
ゾーンファイルについて
今回の主役となる「ゾーンファイル」ですが、これは名前解決のために必要な設定ファイルになります。
ゾーンファイルにはいくつかのレコードと呼ばれるものが設定されており、最も一般的なのは「Aレコード」と呼ばれるものではないでしょうか。
Aレコードとは「ドメイン名」と「IPアドレス」の紐付けを定義するものです。
以下のようなAレコードが設定されていた場合、クライアントがブラウザから「https://test.example.com」にアクセスするとDNSサーバによって名前解決が実施され、最終的には「https://192.168.1.30」という形でアクセスすることになります。
test.example.com. IN A 192.168.1.30このようなレコード情報を設定するのがゾーンファイルになります。
BINDでDNSサーバを構築する場合、/etc/named.confという設定ファイルで、「このゾーン情報はこの設定ファイルに記載するよ」といった内容を定義します。
今回の場合は次のようになります。
zone "example.com" IN {
type master;
file "/var/named/example.com.zone";
};上記の場合、「example.comに関する情報は/var/named/example.com.zoneファイルに記載しますよ」という意味になります。
つまりexample.com.zoneというファイルに対して先ほど登場したAレコード「test.example.com. IN A 192.168.1.30」を記載するという関係性になります。
マスターとスレーブについて
続いてDNSサーバにおけるマスターとスレーブの関係について簡単に触れておきたいと思います。
先ほどDNSサーバの「名前解決」という機能についてはお話しましたが、DNSサーバが1台しかなかった場合のことを考えてみましょう。
その1台が障害で機能しなくなってしまうと「test.example.com」について答えられる人がいなくなってしまいます。
こうなると「htts://test.example.com」にアクセスしようとしても「そんな情報知りません」となってしまいます。
これでは困ってしまうので、基本的にDNSサーバは2台構成で組むことが多いです。
また、この2台は同じ情報を持っている必要があります。
なぜなら1台が機能しなくなった際にもう1台がいつもと違う回答をしてきては困るからです。
そして、この2台が「マスター」と「スレーブ」という関係性を持つようにします。
それではどのようにマスターとスレーブを設定しているのかについて見ていきましょう。
詳細な設定方法は本記事の趣旨とズレるので割愛しますが、一番明確なのは先ほど登場した「type master;」という部分でしょう。
これは「example.comというゾーンについては私がマスターですよ」という設定になります。
同様にしてスレーブ側の設定ファイル（named.conf）でも以下のようにして「私がスレーブです」という設定をしてあげます。
zone "example.com" IN {
type slave;
masters { 192.168.1.10; };
file "/var/named/slaves/example.com.zone";
};「type slave;」については既にご説明した通り「私はスレーブです」という内容ですが、その下の2行についても触れておきましょう。
「masters」では、スレーブの親となるマスターDNSサーバの情報を指定します。
これは自身がスレーブの場合には当然マスターがいるので、それが「誰なのか？」を指定する必要があるからです。
ここでは、ゾーン名「examplle.com」の情報を管理するマスターDNSサーバとして「192.168.1.10」を指定しています。
「file」ではスレーブ側に保存するゾーンファイルのパスを指定します。
マスターとスレーブの関係性を組むと、ゾーンファイルがマスターからスレーブへ「ゾーン転送」という形で連携されます。
これはマスター側で設定した「test.example.com. IN A 192.168.1.10」というAレコードを含むゾーンファイル（example.com.zone）がスレーブ側に転送されることを意味します。
そうすることでマスターとスレーブのどちらに名前解決の要求があったとしても同じ情報を返すことが可能になります。
文字化けの原因
既に触れたとおり、ゾーンファイルはマスターからスレーブに転送されます。
スレーブ側に保存されているゾーンファイル「/var/named/slaves/example.com.zone」をcatコマンドで確認してみましょう。
# cat /var/named/slaves/example.com.zone
examplecom??xamplecomexamplecomexamplecomx??%*06?-Q?
=??
examplecomv=spf1 ip4:192.168.11.10 -all7Q?
examplecom,Q?testexamplecom??c
「examplecom」「192.168.1.10」という情報から何か関係していそうなファイルであることは推測できますが、肝心のAレコードなどの情報は読み取れませんよね。
これが本記事でいう「文字化け」に該当しています。
マスターで設定したゾーンファイルを確認すると上記のようには表示されないのに、スレーブ側ではなぜ文字化けしてしまうのでしょうか？
それはマスターからスレーブにゾーンファイルが転送される段階でファイルの形式が変更されているためです。
この動きはどうやらBIND9.9系になったタイミングでの仕様変更が原因であることが分かりました。
マスター側のゾーンファイルは「text形式」、スレーブ側のゾーンファイルは「raw形式」という状態で保存されます。
なぜこのように形式の変換が行われているのかというと、DNSサーバ起動時の「ゾーン読み込み時間」に関係しています。
raw形式のファイルはすなわちバイナリ形式ですので、コンピュータが読みやすい状態になっています。
そのためraw形式の方がゾーンの読み込み時間が早くなるということに繋がっているんですね。
なるほど、それは確かに嬉しいのです。
ただ、内容を確認できないのでは困ってしまいますよね。
でも大丈夫です。
スレーブに保存されているゾーンファイルを確認する方法はもちろん存在しています。
テキスト形式への変換方法（一時対応）
スレーブに保存されているゾーンファイルを確認する方法の1つとして「named-compilezoneコマンド」を利用するという方法があります。
このコマンドの書式は次のようになっています。
# named-compilezone -f 変換前ファイル形式 -F 変換後ファイル形式 -o 出力ファイル名 ゾーン名 ゾーンファイル名
実際に使用してみると次のようになります。
# named-complezone -f raw -F text -o /var/named/slaves/example_text.com.zone example.com /var/named/slaves/example.com.zoneこれを実行することで「example_text.com.zone」というtext形式のファイルが新たに生成され、catコマンドなどで確認することができます。
1つずつ見ていきましょう。
①変換前ファイル形式
先述の通り変換前はraw形式なので、-fオプションでは「raw」を指定します。
②変換後ファイル形式
変換後はtext形式にしたいので、-Fオプションでは「text」を指定します。
③出力後ファイル名
変換後のファイル名を任意で指定します。
今回はテキスト形式であることが分かりやすいように「example_text.com.zone」というファイル名にしました。
ちなみに出力後ファイル名に「-」とすると、ファイルは作成されずに標準出力として表示されるだけになるので覚えておきましょう。
④ゾーン名
変換対象のゾーンファイルが所属するゾーン名を指定します。
今回の場合は「example.com」となります。
⑤ゾーンファイル名
text形式として表示したいゾーンファイル名を指定します。
今回の場合は「example.com.zone」となります。
テキスト形式への変換方法（恒久対応）
スレーブに保存されているゾーンファイルを確認する2つ目の方法としては、マスターからのゾーン転送をraw形式ではなくtext形式にしてしまうという方法となります。
この方法ではスレーブ側の/etc/named.confファイルのoptionsステートメントあるいは対象のzoneステートメントに「masterfile-format」という項目を記載します。
以下はoptionsステートメントに記載した場合の例を示します。
options {
・・・省略・・・
masterfile-format text;
・・・省略・・・
};これだけでマスターから転送されてくるゾーンファイルはtext形式になります。
そのため/var/named/slaves/example.com.zoneファイルをcatコマンドなどで問題なく確認することが可能です。
ただし、既に述べたとおりraw形式で転送されてくることはスレーブDNSサーバのパフォーマンスに関係しているので、text形式での転送だとスレーブとしての動作に少なからず負荷がかかってしまいます。
特別な理由がない限りは1つ目の「named-compilezoneコマンド」で都度確認するのがいいかもしれません。
おわりに
いかがだったでしょうか。
今回は『スレーブDNSサーバにおけるゾーンファイルの確認方法』について見ていきました。
何も知らずにファイル内容を確認したときに文字化けしていたらヒヤッとしてしまいますよね。
でも今回の内容を知っていればスレーブ側のゾーンファイルもテキスト形式で確認できるようになるので、覚えておいていただければと思います。
当ブログでは、他にもDNSに関する記事を書いているので、ご興味のある方は併せて読んでみてください。
関連記事：【Linux】「再帰的問い合わせ」と「非再帰的問い合わせ」の区別
本記事を最後までお読みいただきありがとうございました。
ではでは！