いますぐ実践! Linuxシステム管理

[バックナンバーのトップへ] [Linux システム管理のトップへ]


いますぐ実践! Linux システム管理 / Vol.205 / 読者数:1887名

こんばんは、うすだです。

今週末より、1週間の、つまり連続9日間の夏休みです。
ということは、これを書いている時点で、すでに2日間を費やしている、 ということになります。

今までの経験上、何も決めないか、 もしくはあれもこれもといろいろやることをリストアップし過ぎると、 何もできない(しない)という結果になることが、わかっております。

過去の失敗を繰り返さないよう、今回の休みも、 やるべきことを2〜3個に限定しようと思っています。

ただ、我が家的にマストな事柄として、1泊2日の旅行に行くこと、 資源のゴミを出すこと、部屋の整理、がすでに挙げられています。

ということは、技術的なことが一切できないということになりそうです。
6年前の黄金週間にブログパーツを作り上げたのが、直近のプチ成功体験なのですが、 今回も更新できそうにありません…。

予測したくないことを予測してしまいましたが、そんなことは気にせず、 今回もはりきってまいりたいと思います。

今回のお題 - DNSSEC を体験してみる

前々回、前回と、DNS に関するネタを取り上げさせていただきました。

Vol.203 - DNSサーバの動作を確認する
http://www.usupi.org/sysad/203.html
Vol.204 - BIND のアクセス制限について考える
http://www.usupi.org/sysad/204.html

ものすごくざっくりとしたご紹介でしたが、 大雑把にはだいたい網羅したと言えるのではないかと思います。

…なんて思っていたのですが、技術的にこれから重要になるもので、 未知の領域なものが1つあることを、忘れていました。

それは、「DNSSEC」です。

キャッシュポイズニングの根本的な対策として脚光を浴びている DNSSEC ですが、 今まで縁がなかったからか、いまいちピンと来ません。

自分の勉強も兼ねて、今回は DNSSEC のさわりをご紹介します。

DNSSEC とは?

「DNSSEC(DNS Security Extensions)」…つまり「DNSセキュリティ拡張」とは、 DNSの各レコードが正しいことを確認できるようにするための拡張機能です。

もうちょっとちゃんと説明しますと、各レコードに電子署名をつけることで、 そのレコードの出どころが自分のドメインであることと、 それが改竄されていないことを確認できるようにするための仕組みです。

DNSSECの機能を実現するために、リソースレコードに対して、 いくつかのタイプが追加されています。それらを問い合わせて得た値から、 レコードの正しさを確認することができます。
ということは、DNSSECに対応していないホストは、それらのタイプを使用せずに、 従来通りDNSを使用すればよいということになります。
…つまり、互換性があるということです。

また、暗号化に関しては、DNSSECの対象外です。
基本的には、みんなが参照できる情報を扱いますので、 暗号化する必要はないだろう、ということになっていると思われます。

 

ちなみに、さらっと電子署名とか言ってしまいました。
さらにさらっと、説明を試みます。

DNSSECでは、公開鍵暗号方式という、暗号化と復号化で別の鍵を使う方式を使用します。 一方の鍵は「秘密鍵」と言って、誰にも教えません。もう片方は「公開鍵」と言って、 みんなに公開します。

電子署名とは、暗号化する前の平文のハッシュ値を、「秘密鍵」で暗号化したものです。 通常は、平文そのものと電子署名を相手に渡します。
受け取った側は、電子署名を「公開鍵」で復号し、 それが平文のハッシュ値と一致することを確認します。

もし平文や電子署名を改竄しようとしても、 双方のハッシュ値が一致するように改竄するのは限りなく難しいため、 相手に正しく情報を伝えたい時に、電子署名が有効な手段だと言えます。

DNSSECでも、各レコードを正しく伝えるための手段に、電子署名を使用します。

…いろいろ説明をはしょりましたので、わからない言葉などありましたら、 グーグルさまに聞いてみてください。(他力本願)

DNSSEC で追加されたタイプ

さて、DNSSECに関連するタイプには、以下があります。

DNSKEY
KSK(Key Signing Key)やZSK(Zone Signing Key)が格納されています。
実際のレコードに署名する際は、ZSKを使用します。
KSKは、ZSKを署名するための鍵です。安全のため、 ZSKをときどき変更する必要がありますが、KSKは基本的には滅多に変更しません。
DS
KSKのハッシュ値が格納されています。これを親ゾーンに置いてもらうことで、 KSKの内容を保証してもらいます。
RRSIG
ZSKで署名した情報が格納されています。
NSEC, NSEC3, NSEC3PARAM
ドメインが存在しないことを証明するためのものです。

 

いくつかを実際に見てみましょう。
まずは、DNSKEY です。「dnssec.jp」のDNSKEYを問い合わせてみます。

  $ host -t dnskey dnssec.jp.
  dnssec.jp has DNSKEY record 257 3 8 AwEAAe0GfS9ZQEOqW...後略...
  dnssec.jp has DNSKEY record 256 3 8 AwEAAbXdq8xS5JM/A...後略...

2つ情報が得られました。最初の行は、record の後に「257」という数が来ています。 これが KSK であることを示しています。もう1行は「256」で、 ZSK であることを示しています。
続いて「3」はプロトコル番号(3に固定)、「8」は暗号化アルゴリズムを示しています。 その後の羅列が KSK もしくは ZSK の公開鍵の値です。

 

次に、DS を見てみましょう。

  $ host -t ds dnssec.jp.
  dnssec.jp has DS record 36700 8 1 138E1DDBFA95582C029...後略...
  dnssec.jp has DS record 36700 8 2 718F289D99890FE8CD3...後略...

「36700」は鍵のID、「8」は暗号化アルゴリズム、 「1」「2」はハッシュのアルゴリズム、その後が KSK のハッシュ値です。

ちなみに、DS の値は、以下の手順で確認できます。
dig コマンドで得た KSK の情報を、 dnsseczone-dnskey というファイル名で保存しておきます。 (ファイル名は任意でかまいません。) そして、dnssec-dsfromkey コマンドで DS を求めます。すると、出力された結果と、 上記が一致することがわかります。

  $ dig dnssec.jp. dnskey | grep 257 > dnsseczone-dnskey
  $ dnssec-dsfromkey -1 -f dnsseczone-dnskey dnssec.jp.
  dnssec.jp. IN DS 36700 8 1 138E1DDBFA95582C029D1B31DB...後略...
  $ dnssec-dsfromkey -2 -f dnsseczone-dnskey dnssec.jp.
  dnssec.jp. IN DS 36700 8 2 718F289D99890FE8CD385CECB0...後略...

また、DS は親ゾーンに置いてあります。
ですので、以下のように、dnssec.jp のネームサーバに聞いても、ないと言われます。

  $ host -t ns dnssec.jp.
  dnssec.jp name server ns1.dnssec.jp.
  dnssec.jp name server ns2.dnssec.jp.
  $ host -r -t ds dnssec.jp. ns1.dnssec.jp.
  ...中略...
  dnssec.jp has no DS record

親ゾーンである jp ドメインのネームサーバが、知っています。

  $ host -t ns jp.
  jp name server b.dns.jp.
  jp name server a.dns.jp.
  jp name server f.dns.jp.
  ...後略...
  $ host -r -t ds dnssec.jp. a.dns.jp.
  ...中略...
  dnssec.jp has DS record 36700 8 1 138E1DDBFA95582C029...後略...
  dnssec.jp has DS record 36700 8 2 718F289D99890FE8CD3...後略...

 

最後に、RRSIG を見てみましょう。

  $ host -t rrsig dnssec.jp
  ;; Truncated, retrying in TCP mode.
  dnssec.jp has RRSIG record A 8 2 86400 20110903100502 \
  20110804100502 168 dnssec.jp. hBZRJkC2W/2bEKoCZhlbntR...後略...
  dnssec.jp has RRSIG record DNSKEY 8 2 86400 20110903100502 \
  20110804100502 168 dnssec.jp. r7afabO2urrFEmR5Dl5Tq3u...後略...
  dnssec.jp has RRSIG record DNSKEY 8 2 86400 20110903100502 \
  20110804100502 36700 dnssec.jp. 4qKpZWDgo6jC5oHbrzpg/...後略...
  dnssec.jp has RRSIG record NS 8 2 86400 20110903100502 \
  20110804100502 168 dnssec.jp. PnXxUoeiVjB90zS19twuxnm...後略...
  dnssec.jp has RRSIG record DS 8 2 86400 20110905174502 \
  20110806174502 45666 jp. d6E7CLjomdDUVldgyD7Iqz7JPrEv...後略...

dnssec.jp. の、 A, DNSKEY, NS や DS といった各リソースレコードに対する署名が得られます。 データ量が多いため、最初に、"Truncated, retrying in TCP mode." …つまり、 TCPでデータを取り直したよと言っています。

いずれも、タイプの後の「8」が暗号化アルゴリズム、 「2」がラベルの数(ドメイン名を . で分けた部分がラベルです)、 「86400」がTTL(キャッシュされる時間です)、「2011090xxxxxxx」が署名の有効期限、 「2011080xxxxxxx]が署名の開始時刻、残りが鍵のIDとドメイン名、そして署名、です。

ネームサーバを DNSSEC 対応にしてみる

DNSSECを理解できたのかどうか、よくわからない状況かもしれませんが、 ここで一発、BINDでDNSSECを有効にして、使ってみたいと思います。

そのためには、DNSSECの確認を行う対象の頂点となるゾーンの KSK を、 named.conf に登録する必要があります。
これを、「トラストアンカー」と呼んでいます。

ここでは、「.」の KSK を登録してみたいと思います。
といっても、以下のように、. の DNSKEY として登録されていますよね。

  $ dig . dnskey
  ...中略...
  ;; ANSWER SECTION:
  .   155305   IN   DNSKEY   257 3 8 AwEAAagAIKlVZrpC6I...後略...
  ...後略...
ただ、これが本当に正しい値なのか、これだけでは判断できません。
そこで、IANA(Internet Assigned Numbers Authority)が公開する情報を元に判断し、 これが正しい情報だということを確認した上で、named.conf に記述します。

まず、PGPの公開鍵を入手します。

  $ gpg --search-keys --keyserver pgp.mit.edu dnssec@iana.org
  gpg: “dnssec@iana.org”をhkpサーバーpgp.mit.eduから検索
  (1)  DNSSEC Manager 
       1024 bit DSA key 0F6C91D2, 作成: 2007-12-01
  Keys 1-1 of 1 for "dnssec@iana.org".  番号(s)、N)次、またはQ)\
  中止を入力してください > 1    <== 登録するなら番号を入力
  gpg: 鍵0F6C91D2をhkpからサーバーpgp.mit.eduに要求
  gpg: 鍵0F6C91D2: 公開鍵“DNSSEC Manager <dnssec@iana.org>”を\
  読み込みました
  gpg: 最小の「ある程度の信用」3、最小の「全面的信用」1、PGP信用モデル
  gpg: 深さ: 0  有効性:   1  署名:   0  信用: 0-, 0q, 0n, 0m, 0f, 1u
  gpg: 処理数の合計: 1
  gpg:               読込み: 1

次に、IANA のページに置いてある情報と、その署名を入手します。

  $ wget http://data.iana.org/root-anchors/root-anchors.xml
  $ wget http://data.iana.org/root-anchors/root-anchors.asc
上記で入手した root-anchors.xml が正しいことを確認します。
  $ gpg --verify root-anchors.asc root-anchors.xml
  gpg: 2010年07月07日 07時49分10秒 JSTにDSA鍵ID 0F6C91D2で施された署名
  gpg: “DNSSEC Manager <dnssec@iana.org>”からの正しい署名
  gpg: 警告: この鍵は信用できる署名で証明されていません!
  gpg:          この署名が所有者のものかどうかの検証手段がありません。
  主鍵の指紋: 2FBB 91BC AAEE 0ABE 1F80  31C7 D1AF BCE0 0F6C 91D2

dnssec@iana.org そのものの鍵の信憑性を証明できていないため、 警告が表示されていますが、3行目に「正しい署名」とありますので、 問題ないと言ってよいと思います。

後は、上記で得た root-anchors.xml の内容と、 DNSで得た DNSKEY の値から生成した DS が一致することを確認します。

  $ dig . dnskey | grep 257 > rootzone-dnskey
  $ dnssec-dsfromkey -2 -f rootzone-dnskey .
  . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1...後略...
  $ cat root-anchors.xml
  ...中略...
  <KeyTag>19036</KeyTag>
  <Algorithm>8</Algorithm>
  <DigestType>2</DigestType>
  <Digest>49AAC11D7B6F6446702E54A1607371607A1A41855200F...後略...
  ...後略...

鍵のID、暗号化アルゴリズム、ハッシュのアルゴリズム、そして署名そのもの、 いずれも一致しますので、問題ないですね。

それでは、 named.conf(もしくは named.conf.options など)に以下を追加してください。
「257 3 8」および署名の値は、 この節の最初に示したdigコマンドの出力結果そのままです。

  managed-keys {
        . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gE...後略...";
  };

そして、optionsステートメントか、対象のviewステートメントに、 以下を追加します。

  dnssec-enable yes;
  dnssec-validation yes;

「dnssec-enable」でDNSSECを有効にします。
また、「dnssec-validation」でDNSSECによる確認作業を使用するようにしています。

あとは、named を再起動するだけです。

  # named-checkconf || echo NG
  (NG とか出力されたら、named.conf を見直してください)
  # service named restart  (FedoraやCentOSの場合)
  # service bind9 restart  (UbuntuやDebianの場合)

named を再起動したら、dig コマンドで動作確認を行います。
「+dnssec」というオプションで、DNSSECの確認を実施します。

  $ dig +dnssec www.dnssec.jp
  ...中略...
  ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 7

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags: do; udp: 4096
  ;; QUESTION SECTION:
  ;www.dnssec.jp.               IN      A

  ;; ANSWER SECTION:
  www.dnssec.jp.        72607   IN      A       111.89.176.107
  www.dnssec.jp.        72607   IN      RRSIG   A  8 3 86400 ...
  ...後略...

flags: のところに「ad」があれば、署名の確認ができています。

おわりに

以上、DNSSEC のさわりを、ほんとにさわりだけをご紹介しました。

グーグルさまに伺うと、いろんなサイトを紹介してくださいますが、 その中でも有用だったのは以下です。
上記で不十分だなと思われた貴兄は、ぜひ下記をご覧くださいませ。

DNSSECチュートリアル
http://www.nic.ad.jp/ja/materials/iw/2009/proceedings/h3/iw2009-h3-01.pdf
DNSSECジャパン
http://dnssec.jp/

次回も、DNSSEC を引き続きご紹介しようと思っております。

宿題の答え

前回の宿題は、

  allow-query-cache の動作確認をしてみましょう。

でした。

まず、named.conf の options ステートメントなどに、 以下の設定を追加(あるいは変更)してみましょう。
(/etc/named.conf や /etc/bind/named.conf.options だったりと、 環境 によって設定ファイルの場所が違います。お探しくださいませ。)

  allow-recursion { localhost; };
  allow-query-cache { localnets; };

allow-recursion で、自ホストからのみ再帰問合せを許可しています。
allow-query-cache で、自ホストに接続しているネットワーク上のマシンからのみ、 キャッシュされた情報に対する問合せを許可しています。

キャッシュを確実にクリアするため、named を再起動します。

  # service named restart  (FedoraやCentOSの場合)
  # service bind9 restart  (UbuntuやDebianの場合)

ではまず、キャッシュにだけ問合せを許可されている、 ネットワーク上の別のマシンから、www.google.com の情報を問い合わせてみます。
(namedを動かしているマシンが192.168.1.1だと仮定しています。)

  $ host www.google.com 192.168.1.1
  Using domain server:
  Name: 192.168.1.1
  Address: 192.168.1.1#53
  Aliases: 

  $

何も得られませんでした。
次に、再帰問合せを許可されている自ホストから、問い合わせます。

  $ host www.google.com 127.0.0.1
  Using domain server:
  Name: 127.0.0.1
  Address: 127.0.0.1#53
  Aliases: 

  www.google.com is an alias for www.l.google.com.
  www.l.google.com has address 72.14.203.147
  www.l.google.com has address 72.14.203.99
  www.l.google.com has address 72.14.203.103
  www.l.google.com has address 72.14.203.104
  www.l.google.com has address 72.14.203.105
  www.l.google.com has address 72.14.203.106

当然ですが、情報が得られました。
これで、www.google.com の情報がキャッシュされているはずです。
もう一度、ネットワーク上の別のマシンから問い合わせてみましょう。

  $ host www.google.com 192.168.1.1
  Using domain server:
  Name: 192.168.1.1
  Address: 192.168.1.1#53
  Aliases: 

  www.google.com is an alias for www.l.google.com.
  www.l.google.com has address 72.14.203.106
  www.l.google.com has address 72.14.203.147
  ...後略...

今度は、ちゃんと情報が得られました。

ちなみに、もともと持っているゾーン情報に関しては、当たり前ですが、 ちゃんと情報が得られます。

  $ host www.local.usupi.org. 192.168.1.1
  Using domain server:
  Name: 192.168.1.1
  Address: 192.168.1.1#53
  Aliases: 

  www.local.usupi.org has address 192.168.1.80
  www.local.usupi.org has IPv6 address fd41:28b7:be11::80

こちらは allow-query-cache の設定は関係なく、 allow-query で決まるように思われます。(allow-query のデフォルトは any です。)

今回の宿題

今回の宿題は、

  他のドメインの DNSSEC の対応具合などを確認してみましょう。

です。

本題では主に「dnssec.jp」を勝手に対象とさせていただきました。
他のドメインではどうなのかなど、確認してみてくださいませ。

あとがき

2月に転職してから今まで、余裕のないまま走り続けてきました。
夏休みに入っても、状況はあまり変わっていません。

自分がどうなりたいとか、目標などを、転職前に考えたはずなのですが、 考えただけでうやむやになってしまっています。

目標を明確にして、そのために何が必要で何をすべきなのかを、 逆算して決めるべきだと思います。夏休み中に明確にしたいと思います。

そして、今の余裕のない状況を打破するために、 生活習慣や考え方を変更する必要があると思っています。
平日の平均睡眠時間が3時間というのは、たぶん余裕がなさすぎです。
遠くない将来に破綻するのは目に見えています。

こっちは、明確にするのが難しいのですが、変化のきっかけになるようなことを考えて、 実行していこうと思っています。

というわけで、1泊2日の旅行を、9〜10日に行くことが決まりました。
そのため、ゴミ出しと部屋の整理を諦め、上記をやろうかなと思っております。 ついつい考えることから逃げがちですので、 こうしてここに記述をさせていただくことで、 自分に対して外堀を埋めてみたつもりです。

 

今回も、ここまで読んでいただき、たいへんありがとうございました。
次回は、8月21日(日) の未明にお会いしましょう!

 

「いますぐ実践! Linux システム管理」の解除は、以下からできます。
http://www.usupi.org/sysad/ (まぐまぐ ID:149633)

バックナンバーは、こちらにほぼ全部そろっています。
http://www.usupi.org/sysad/backno.html

「栗日記」- 目下低迷中ですが、毎日何とか描いています。
http://www.usupi.org/kuri/ (まぐまぐ ID:126454)
http://usupi.seesaa.net/ (栗日記ブログ)
http://usupi.org/k/ (モバイル栗日記)


[バックナンバーのトップへ] [Linux システム管理のトップへ]

トップ

バックナンバー
    [日付順] [目的別]

プロフィール

▼ リンク

独学Linux
Linuxデスクトップ環境に関する情報が満載です。 メルマガもありますよ。
Server World
CentOS 6をサーバとしたときの設定例が、これでもかというくらいたくさん載っています。 CentOS以外のディストリビューション(Fedora, Ubuntu)も充実しています。
LINUXで自宅サーバーを構築・導入(Fedora9)
Fedora9のインストールの仕方から管理方法まで、詳しく載っています。 SearchManには情報がもりだくさんです。
マロンくん.NET
〜サーバ管理者への道〜
Linuxをサーバとして使用するための、いろいろな設定方法が載っています。 マロンくんもかわいいです。 なんといっても、マロンくんという名前がいいですね!!
日経Linux
今や数少なくなってしまったLinuxの雑誌。ニュースやガイドもあります。
Linux Square − @IT
@ITが提供する、Linux の情報が満載。 載っていない設定方法はないんじゃないでしょうか。
gihyo.jp…技術評論社
Linuxに限らず様々な技術情報が満載のサイト。 SoftwareDesign誌も、 ソフトウェア技術者は必見です。
SourceForge.JP Magazine
Linux に限らず、オープンソース関連の記事が網羅されています。
ITmediaエンタープライズ:Linux Tips 一覧
Tips というより FAQ 集でしょうか。わからないことがあれば覗きましょう。
IBM developerWorks : Linux
開発者向けですが、勉強になりますよ。
Yahoo!ニュース - Linux
Yahoo!のLinuxに関するニュース一覧です。
栗日記
システム管理とかと全然関係ありませんが、毎日栗の絵を描いています。
システム管理につかれちゃったとき、癒されたいときに、ご覧ください。:-)
WEB RANKING - PC関連
ランキングに参加してみました。押してやってください。

▼ 作ってみました

Add to Google

▼ せんでん




▼ 最近読んだ本

▼ 気に入ってる本