■DNSSECとは？
DNSSEC(Domain Name System Security Extensions)とは、 DNSに対し、データ作成元の認証やデータの完全性を確認できるように仕様を拡張するものです。 DNSSECによって、データの偽装を検知することができるようになり、 DNSキャッシュポイズニングのような攻撃を防ぐことができます。
DNSSECでは、従来のDNSプロトコルに対し、DNS Public Key (DNSKEY)、 Resource Record Signature (RRSIG) 等のリソースレコードや、ADビット等のヘッダフラグが追加・修正されています。
データの作成元は、これらのレコードを用いて署名を行い、 また、データを参照する側のDNSリゾルバ(クライアント)は、 送られてきたデータの署名を検証することで、情報が正しいものかどうかを判断します。
（JPNICより)
■BINDの設定
BIND9.7からはDNSSECに関する設定がデフォルトでほとんどされており、特別な手間を必要としません。DNSSECに必要な設定 は以下の2点です。
- トラストアンカーの設定
- DNSSECの有効化
BIND9.7からは上記2点ともデフォルトで有効になっておりますが該当箇所を確認していきます。まずDNSSECに関するnamed.confの設定について以下が該当箇所となります。
# vi /etc/named.conf dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; |
デフォルトで上記のようになっていると思いますので特に意識しなくともDNSSECは有効ということになります。トラストアンカーについては/etc/named.iscdlv.keyで定義されておりこちらも特に意識する必要はありません。ちなみに中身は以下のようになっています。
$ORIGIN .
$TTL 0 ; 0 seconds
@ IN SOA . . (
15 ; serial
0 ; refresh (0 seconds)
0 ; retry (0 seconds)
0 ; expire (0 seconds)
0 ; minimum (0 seconds)
)
KEYDATA 20121122074635 20121121014556 19700101000000 257 3 8 (
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
) ; key id = 19036
dlv.isc.org KEYDATA 20121121084634 20121121014603 19700101000000 257 3 5 (
BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn
4MxDCE1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW
58dnJNPCxn8+jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6B
D4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5ymX4BI/o
Q+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte
/URkY62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw
/mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3xiRXF1Rf+
al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh
) ; key id = 19297
|
実際にdigコマンドで確認を行います。
# dig jprs.jp +dnssec ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.5 <<>> jprs.jp +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48625 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;jprs.jp. IN A ;; ANSWER SECTION: jprs.jp. 86399 IN A 202.11.16.167 jprs.jp. 86399 IN RRSIG A 8 2 86400 20121215023007 \ 20121115023007 31944 jprs.jp. s5dBsoZIRQtiZ4+CVYzoNm43px7EgDvudYJ65Lxdp0FEv5weqnMJEj4p \ xn58I9PerqAOEnF6tc7fQU33ExB+RWaNXiUf+quGqPw3ZcAJsaWdZrn9 \ YeXk8ogP70BIIcgDyYMaDmlHNS0AXA0crIRXweNguMM9MH8Xi5+jd3uR Sgk= ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Nov 21 17:42:52 2012 ;; MSG SIZE rcvd: 219 |
flagsのところで「ad」という文字列があればDNSSECは成功しています。DNSSECの運用上、以下の3つに注意する必要があります。
■時刻同期
時間が大幅にずれている場合、署名の検証等に失敗し名前解決が一切できなくなる可能性があるので注意してください。( DNSSECに限らず外部公開用サーバであれば時刻は正確に合わせておくべきですが )
■Port番号
DNSといえばポート番号はUDPの53という認識があると思いますが、実はTCPの53も比較的使われていたりします。基本的にはゾーン転送にTCP、クエリーにはUDPを使用しています。ただ、クエリーのUDPパケットはRFC上、512オクテットに制限されておりこのサイズを超えた場合はUDPからTCPに切り替わることもありますので、間にFIrewallがある場合は注意が必要です。
■時刻同期
通常のDNS運用と比較して、当然ながら色々な動作が増えますのでその分CPUやメモリなどで使用するリソースが多くなります。その辺りを考慮にいれても相当数のアクセスがなければ気にする必要はないと思いますが、一応頭に入れておいたほうが良いと思います。