DNSSECとは

DNSSEC（DNS Security Extensions）は、DNSの拡張仕様である。DNSの情報に電子署名を付けることで、DNSのデータが正式な発行元のデータであることを検証することができるようにする。

DNSSECの最初の仕様は1999年にRFC2535として公開されたが、長い間、実用とならなかった。それは、インターネットのトップレベルドメインのDNSSEC対応が遅れたためである。しかし、2008年7月に発生したDNSキャッシュポイズニング攻撃を受けて、2010年にトップレベルドメインがDNSSECに対応したことを受け、徐々に利用が広がっている。日本のccTLDである.jpドメインも2011年にDNSSECを導入した。また、すでに.com、.netなどのほとんどのドメインがDNSSECに対応している。

DNSSECの普及状況

APNICは、各TLD毎のDNSSEC対応状況をマップにして公開している（http://stats.labs.apnic.net/dnssec）。この統計では、DNSSECによって検証が行われているDNS問い合わせの率を見ることができる。

2016年9月の段階で最も普及が進んでいた地域はオセアニア、南北アメリカ、ヨーロッパで約20%の問い合わせが検証されている。ccTLD（国別）でみると、スウェーデンとアイスランドのccTLDであるSEとSIドメインでは、約80%が検証されている。一方、アジアはアフリカよりも普及が遅れていて地区別では最下位である。アジア全体で10%以下となっている。特に、日本（jp）では2.91%しか検証されておらず、アジアの平均にも遠く及ばない。全ccTLDの順位でも155位と世界の中でも極めて低い普及状況である。

なお、2018年11月の段階でも、アジアは依然として10%以下の普及状況である。しかし、日本では8.84%と約2年で6%ほど増え、徐々に普及率が高くなってきている。

DNSSECとキャッシュポイズニング攻撃

キャッシュポイズニング攻撃は、DNSサーバに偽造したデータを送り込む攻撃である（詳しくは、キャッシュポイズニングを参照）。この攻撃では、利用者が誤ったサイトに誘導されたり、通信の内容を盗聴、改ざんされたりする可能性がある。DNSSECでは、公開鍵暗号の技術を使って、DNSのレコードに署名する。そのため、万一誤ったデータが送り込まれても、署名を検証することで攻撃を検出することができる。この検査では、トップレベルドメインからTLD、該当ドメインと順に検証を行うため、データの入手元が正しいDNSサーバであることも確認できる。そのため、DNSSECを導入すれば、キャッシュポイズニング攻撃による被害を防ぐことができる。

DNSSECは、キャッシュポイズニング攻撃を防ぐためには欠かせない技術なのである。

自分が騙されないためのDNSSEC

DNSSECを導入する理由の一つは、DNSキャッシュサーバの利用者が騙されないようにすることである。DNSキャッシュサーバが攻撃され、誤った情報が配信されると、利用者は別のサイトに誘導されてしまう可能性がある。例えば、銀行のオンラインサイトのDNSデータを偽造すれば、利用者のログイン情報、パスワードなどを入手することができる。あるいは、重要な取引先のメールサーバの情報を偽造されれば、その取引先へのメールはすべて盗聴されてしまう危険がある。

DNSキャッシュサーバでDNSSECの検証を行えば、DNSSECに対応したドメインのデータは自動的に検証が行われ、偽造データにより騙されることはなくなる。銀行など、重要な機関はDNSSECに対応しているので、こうした攻撃の危険性を大きく下げることができる。

顧客や関係者が騙されないためのDNSSEC

DNSSECを導入するもう一つの理由は、自組織の顧客や取引先を守るためである。自組織が管理するドメインがDNSSECに対応していなければ、顧客や取引先はキャッシュポイズニング攻撃により騙されてしまう可能性がある。顧客が正しいURLを入力しても、まったく別のサイトが表示されるかもしれない。このサイトに不適切な情報が掲示されていたり、ウィルスなどが埋め込まれていても、顧客はその情報を信じることになる。そのため、顧客が次々に被害に会い、重大な信用問題に発展してしまう可能性がある。

また、メールサーバの情報を偽装されてしまうと、自分の組織に届くはずのメールがすべて他のサーバに届けられてしまう可能性もある。当然、企業間でやり取りされている秘密情報が漏えいしてしまう危険がある。

こうした問題に対処するためには、自組織が公開しているDNSゾーンの情報をDNSSECで署名しておく必要がある。きちんと署名されていれば、少なくとも利用者が情報の信憑性を確認することが可能になる。

上位ドメインの対応とDLV（DNSSEC Lookaside Validataion）

DNSSECでは、ルートドメインが各TLDの情報を署名し、各TLDが配下のドメインの情報に署名することで、ツリー状に署名の連鎖を構築し、全体としての安全性を維持している。そのため、上位のドメインがDNSSECに対応していない場合には、下位ドメインはDNSSECの署名の連鎖に参加することができない。

DNSSECの普及にあたっては、このような問題が発生することが考慮され、DLV（DNSSEC Lookaside Validation）と呼ばれる仕組みが用意されている。DLVに対応したDNSキャッシュサーバは、上位のドメインで提供されるべき署名データが見つからない場合には、あらかじめ用意した特別ドメインからDLVレコードを入手し、署名データを入手する。この特別なドメインをDLVレジストリと呼ぶ。現在、DLVレジストリは、DNSサーバ（BIND）の開発元であるISCが運用している。

DNSSEC導入時の注意点

DNSSECの署名には有効期限が設定されている。そのため、DNSサーバの時刻が正しくないと、DNSSECの検証に失敗する。NTPなどを導入し、正確な時刻に同期する必要がある。

また、DNSSECを有効にしてDNSの問い合わを行うと、DNSレコードとともに署名データを入手することになる。従来のDNSの問い合わせデータは比較的小さなデータであったため、DNSはあまり大きなデータを扱うように設計されていなかった。そのため、DNSSECを導入すると従来のDNSのプロトコルでは、メッセージサイズの制限のために不都合が生じる。

この問題を解決するために、RFC2671でEDNS0と呼ばれるDNSの拡張プロトコルが定められた。DNSSECを有効にすると、従来のDNS、EDNS0、TCPによるDNSの3つの通信形式が利用される可能性がある。そのため、ファイアウォールを適切に設定しないと、正常に通信を行えなくなる場合がある。EDNS0に対応していないファイアウォールも存在するため、注意が必要である。

DNSキャッシュサーバのDNSSEC対応

DNSキャッシュサーバをDNSSEC対応にする方法は、比較的簡単である。DNSSECに対応したソフトウェアを導入し、検証機能を有効にするだけで対応できる。

DNSSEC対応状況

「DNSサーバのおすすめOSS比較」には、4つのDNSキャッシュサーバのソフトウェアが紹介されているが、BIND、unbound、ResursorがDNSSECには対応している。例えば、DNSサーバとして有名なBINDは、古くからDNSSECに対応している。BIND9.6以上でDNSSECを使うことができるが、一般的には9.7系以降が推奨されている。また、unboundでもDNSSECを利用することができる。

ディストリビューションの対応

最近の多くのLinuxディストリビューションでは、DNSSECに対応したDNSサーバソフトウェアを採用している。また、RedHat Enterprise Linux/CentOSでは、RHEL6/CentOS6以降、DNSサーバをインストールすると標準でDNSSECが有効になるように設定されている。

トラストアンカー

トラストアンカーは、DNSSECの信頼の連鎖の大元になる情報である。一般的には、ルートゾーンの公開鍵のことを指す。DNSキャッシュサーバをDNSSEC対応にする場合には、トラストアンカーを入手する必要がある。ただし、多くの場合には、ソフトウェアパッケージに同梱されている。RHEL/CentOSでも、標準パッケージをインストールすると自動的に設定が行われる。

DNS権威サーバのDNSSEC対応

DNSキャッシュサーバのDNSSEC対応と異なり、DNS権威サーバをDNSSEC対応にするための作業は難易度が高い。

DNSSEC対応状況

「DNSサーバのおすすめOSS比較」には、4つの権威DNSサーバのソフトウェアが紹介されているが、BIND、NSD、knotDNS、PowerDNSのすべてのソフトウェアがDNSSECに対応している。

ただし、BIND、NSD、knotDNSは比較的設定が難しい。PowerDNSは、DNSSECの普及が進んでいるオランダ、スウェーデンなどで良く使われているDNSソフトウェアである。PowerDNSのWEB管理ツールであるPowerAdminを利用すれば、DNSSECで必要な煩わしい管理を隠蔽し、容易に運用することができる。

DNSSECの仕組みと暗号鍵

DNSSECでは、信頼の連鎖を構築するために2種類の鍵を使う。KSK（Key Signing Key）とZSK（Zone Signing Key）である。公開暗号方式であるので、KSK、ZSKとも公開鍵と秘密鍵のペアである。したがって、実質的に4つの鍵が使われることになる。

DNS権威サーバは、KSK、ZSKの公開鍵をDNSKEYレコードとして公開する。DNSキャッシュサーバがDNSの情報を検証する場合には、公開鍵を使って検証する。これらの鍵は、十分にセキュリティ強度の強いものを利用し、定期的に更新を行う必要がある。

親ゾーンへの登録とKSK

KSKは、ゾーンの信頼の連鎖を構築するために使う。そのため、上位ゾーンの管理者にKSK公開鍵を渡し、上位ゾーンの鍵を使ってKSK公開鍵の署名を作成し、それをDSレコードという形で公開してもらう必要がある。DNS権威サーバが管理するゾーンが、TLDから参照されるゾーンの場合には、TLDにKSK公開鍵のダイジェストを登録してもらう必要がある。

ゾーンの署名とZSK

ゾーンの署名は、ZSKを使って行われる。ゾーンを署名すると、ゾーンの各レコードには署名としてRRSIGレコードが付加される。DNSSECに対応した問い合わせがあった場合には、要望されたレコードとそのRRSIGレコードを応答として返す。ゾーンの署名は、ゾーンの情報が更新されるたびに再設定する必要がある。この作業は比較的煩わしいが、PowerAdminを利用すると自動的に行われる。

KSKロールオーバー

KSKロールオーバーとは、ルートゾーンのKSKを更新することである。ルートゾーンKSKは、DNSSECの基点となる最上位のKSKのことである。2017年9月からルートゾーンKSKの更新が行われており、影響が起きると懸念されている（詳しくは、「KSKロールオーバー」を参照）。デージーネットでは、無料セミナーなどでKSKロールオーバーに関する注意喚起も行っている。対策に関する詳しい実施方法と確認方法については「KSKロールオーバー セミナー資料」をダウンロードすることで確認できる。

デージーネットの取り組み

デージーネットでは、DNSSECに対応したDNSサーバの構築サービスを行っている。

デージーネットでは、2011年からDNSSEC対応のDNSサーバを構築し運用を行ってきた。当初は、BINDで運用を行っていたが、2016年からはDNSSECの運用により適したDNSサーバとして、PowerDNS、PowerAdminを使って運用を行っている。デージーネットでは、2016年9月からPowerDNSの商用サポートを開始した。

なお、デージーネットで出版した書籍は、すべてDNSSECを使う前提で解説を行っている。もちろん、デージーネット社内でもDNSSECを有効にしたキャッシュサーバが使われている。デージーネットでは、キャッシュサーバとしてはunboundを推奨している。