DNSのセキュリティとDNSに関する技術

Size: px

Start display at page:

Download "DNSのセキュリティとDNSに関する技術"

たつやいなくら
4 years ago
Views:

1 はじめに説明にあたり使用 OS は CentOS5.4, 使用 DNS ソフトウェアは BIND9.6 を前提としています目次 DNS のセキュリティ DNSのセキュリティの基本 1 基本構成その1 2 基本構成その2 3 ヒドゥンプライマリDNS 4 ゾーン転送を制限する 5 問い合わせを許可するユーザを制限する 6 再起問い合わせを禁止する 7 DNS に関するする技術日本語ドメイン名 8 TCPフォールバック 9 EDNS0 10 DNSのパケットサイズと問題 12 DNSSEC 15 DNSSECの設定 ( キャッシュサーバの場合 ) 16 DNSSECの設定 ( コンテンツサーバの場合 ) 18 DNSSECの動作確認 21 DNSBL(DNS Black List)

2 DNS のセキュリティセキュリティの基本 DNS ソフトウェア DNSソフトウェアはなるべくバージョンが高くて安定性のあるもの ( 脆弱性のないもの ) にする DNS の構成 DNSサーバはコンテンツサーバとキャッシュサーバに分かれる役割が異なるためできるなら物理的にコンテンツサーバとキャッシュサーバは分離すべき 1 コンテンツサーバコンテンツサーバとはドメインのゾーン情報を持っているDNSサーバのことマスターサーバ ( プライマリサーバ ) とスレーブサーバ ( セカンダリサーバ ) に分類されるマスターサーバはドメインのゾーン情報のオリジナルを持っているDNSサーバスレーブサーバはマスターサーバからゾーン情報のコピーを取得して保持しているDNSサーバ誰でも参照可能にする外部に公開する再帰問い合わせを禁止する 2 キャッシュサーバキャッシュサーバとは外部のDNSサーバに問い合わせをした結果をキャッシュ ( 保存 ) するDNSサーバでありドメインのゾーン情報を管理していないそのため基本的にユーザの問い合わせ先のDNSとして利用される利用者を制限する外部に公開しない再帰問い合わせを許可する - 2 -

3 基本構成その 1 社外 DNS の基本的基本的な構成 router NS2.example.jp コンテンツサーバ止めないネットワークを構成するためには 4 台以上の物理的に異なる DNS が望ましいコンテンツサーバ 2 台 ( スレーブDNS) 外部からアクセスできる場所に設置するマスターサーバとスレーブサーバはネットワーク的に分離させる DMZ 上マスターサーバ DMZ 上スレーブサーバ外部ネットワーク上 F/W ( 委託 ) NS1.example.jp キャッシュサーバ 2 台 S/W コンテンツサーバ外部からアクセスできないLAN 上に設置する ( マスター DNS) キャッシュサーバもネットワーク的に分離させる LAN 内キャッシュサーバキャッシュサーバ - 3 -

4 基本構成その 2 社外社内に DNS サーバが 1 台しかないしかない場合 1 台でコンテンツサーバ & キャッシュサーバ兼用 router F/W S/W NS2.example.jp コンテンツサーバ ( スレーブDNS) DMZ 上 NS1.example.jp view ステートメントを使って外部向けにはコンテンツサーバとして公開し内部向けにはキャッシュサーバとして公開サーバは DMZ 上に配置するコンテンツサーバのセカンダリは外部に委託コンテンツサーバ ( マスター DNS) view " 外部向け " { & キャッシュサーバゾーン情報 ; 再起問い合わせ不可 ; } ; LAN 内 view " 内部向け " { 問い合わせ制限 ; 再起問い合わせ許可 ; } ; - 4 -

5 ヒドゥンプライマリ DNS router 社外 NS3.example.jp ヒドゥンプライマリ DNS コンテンツサーバのマスターサーバを隠し ( 非公開 ) 外部からの侵入や攻撃を防ぐこと具体的にはマスターサーバをNSレコードの登録から外すことにより非公開にすることができる ( スレーブDNS) マスターサーバは外部からアクセスできないLAN 上に配置してそこから外部のスレーブサーバにゾーン情報を転送する DMZ 上 example.jp ゾーンファイル F/W [ 通常の設定 ] NS2.example.jp example.jp. IN NS NS1.example.jp S/W コンテンツサーバ example.jp. IN NS NS2.example.jp ( スレーブDNS) example.jp. IN NS NS3.example.jp ゾーン転送キャッシュサーバ LAN 内 NS1.example.jp コンテンツサーバ ( マスター DNS) [ ヒドゥンプライマリ DNS の設定 ] example.jp. IN NS NS2.example.jp example.jp. IN NS NS3.example.jp NS レコードに登録しないことにより外部にその存在を隠す - 5 -

ゾーン転送転送を制限制限するゾーン転送とはスレーブサーバがマスターサーバからゾーン情報を取得する方法のひとつマスターサーバ側は特定のスレーブサーバのゾーン転送要求だけに応答するように allow-transfer オプションを使って制限をかけるマスターサーバの named.

6 ゾーン転送転送を制限制限するゾーン転送とはスレーブサーバがマスターサーバからゾーン情報を取得する方法のひとつマスターサーバ側は特定のスレーブサーバのゾーン転送要求だけに応答するように allow-transfer オプションを使って制限をかけるマスターサーバの named.conf マスターサーバゾーン転送要求 # 全体で制限をする場合 options { allow-transfer { ゾーン情報送信スレーブサーバのIP; ゾーン転送要求 # zone 単位で制限をする場合 zone " ゾーン名 " { type master; file " ファイル名 "; allow-transfer { スレーブサーバのIP; スレーブサーバ他のサーバ先頭の # はコメント行を示す - 6 -

7 問い合わせをわせを許可許可するするユーザユーザを制限制限するキャッシュサーバについては利用するユーザを制限するコンテンツサーバについては自身が管理するゾーン情報への問い合わせの制限をしてはいけないコンテンツサーバの named.conf 設定なしコンテンツサーバ問い合わせ社内ユーザキャッシュサーバの named.conf options { # 問い合わせを許可するユーザ allow-query { IP アドレス ; IP アドレス /Prefix 長 ; ACL 名 ; 外部ユーザキャッシュサーバ # 問い合わせを拒否するユーザ blackhole { IP アドレス ; IP アドレス /Prefix 長 ; ACL 名 ; 利用者を社内ユーザに制限する先頭の # はコメント行を示す - 7 -

8 再帰問い合わせをわせを禁止禁止する再帰問い合わせとは DNS サーバが問い合わせに対する回答を知らない場合に問い合わせ元に代わって外部の DNS サーバに問い合わせることキャッシュサーバについては利用するユーザを制限するコンテンツサーバについては再帰問い合わせを禁止するコンテンツサーバの named.conf 自分の管理するゾーン情報については応答するが再帰問い合わせはしない options { # 再帰問い合わせを禁止 recursion no; コンテンツサーバ問い合わせ社内ユーザキャッシュサーバの named.conf options { # 再帰問い合わせの制限 allow-recursion { IPアドレス /Prefix 長 ; ACL 名 ; 先頭の # はコメント行を示すキャッシュサーバ利用者を社内ユーザに制限する外部ユーザ - 8 -

日本語ドメインドメイン名日本語ドメイン名とはその名の通りドメインに日本語を使用した国際ドメイン名のことクライアント側は日本語ドメイン対応ブラウザが必要 DNS サーバ側では日本語ドメインを Punycode 表記に変換した文字列でドメイン設定をする

xn--88j1au9swd7cpd0ttg6748cehdm06m.jp? 4 回答サーバ側 192.168.24.54 DNS サーバ } named.conf ファイル内 zone "xn--88j1au9swd7cpd0ttg6748cehdm06m.

9 日本語ドメインドメイン名日本語ドメイン名とはその名の通りドメインに日本語を使用した国際ドメイン名のことクライアント側は日本語ドメイン対応ブラウザが必要 DNS サーバ側では日本語ドメインを Punycode 表記に変換した文字列でドメイン設定をするクライアント側ブラウザ 1 日本語ドメイン対応ブラウザでアクセス 5 ブラウザ表示 2 Punycode 表記に変換 3 問い合わせ 4 回答サーバ側 DNS サーバ } named.conf ファイル内 zone "xn--88j1au9swd7cpd0ttg6748cehdm06m.jp" IN { type master; file "zonefile/xn--88j1au9swd7cpd0ttg6748cehdm06m.jp.zone"; xn--88j1au9swd7cpd0ttg6748cehdm06m.jp.zone ファイル内 www A

10 TCP フォールバック DNS における TCP フォールバックとはパケットのサイズ (IP と UDP のヘッダを除く ) が 512 バイトを超える場合に TCP に切り替えて再度問い合わせる仕組みのこと通常 DNS への問い合わせ応答には UDP を使うがパケットサイズはデフォルトで 512 バイト以下と決まっている TCP に切り替えるキックは問い合わせ先 DNS サーバが応答パケットに TC ビット =1 をセットすることから始まる最初から TCP で通信をすることはできないクライアントキャッシュサーバコンテンツサーバ 2 UDPでquery 1 問い合わせ 4 UDPでresponse ( 途中までの回答 +TCビット =1 ) 9 回答 5 6 TCPコネクション確立 3 TCビット =1を見て応答パケットが512バイト TCPで再接続を超えると判断 7 TCPでquery 8 TCP で response dig コマンドでみる TCP フォールバック se. any ;; Truncated, retrying in TCP mode. TC=1を受け取ったので TCPで再試行 ( 省略 ) ;; Query time: 306 msec ;; SERVER: #53( ) ;; WHEN: Tue Feb 23 14:32: ;; MSG SIZE rcvd: 2688 受信パケットのメッセージサイズは 2688バイト

11 EDNS0 DNS の規格に対する拡張バージョン 0 のこと本来 DNS パケットサイズが 512 バイトを超える場合は TCP フォールバックが発生し TCP 通信に切り替わるが 512 バイト超の大きな DNS データでも UDP で取り扱えるようにするための仕組みただしお互いが EDNS0 に対応していないと利用できずその場合は通常の UDP TCP フォールバックとなる BIND9 以降であればデフォルトで有効となっているお互いが EDNS0 対応の場合 1 OPT RR をつけて送信 (edns-udp-size の値を通知 ) 応答サイズと XX と YY を比べて 1 回で送信できる場合は UDP それ以外は TCP edns-udp-size=xx max-udp-size=yy ( 受信可能なサイズ ) 2 応答 ( 送信可能なサイズ ) EDNS0 でない場合 1 OPT RR をつけて送信 (edns-udp-size の値を通知 ) OPT RRを無視 edns-udp-size=xx ( 受信可能なサイズ ) 2 応答 512バイト以下の回答なら UDP 512バイト超の回答なら TCP EDN0を実装していないサーバは OPT 擬似レコードを無視し EDNS0を実装しているがサポートしていないサーバはエラーを返すようになっている max-udp-sizeを超える場合はtcpフォールバックが発生する

12 EDNS0 の設定 BIND9 以降ではデフォルトで有効であるため特に設定をしていなくても利用できる options { edns-udp udp-size 数値 ; edns-udp udp-size 数値 ; EDNS0のUDPサイズ ( バイト ) を通知するサイズを指定する max-udp udp-size 数値 ; 有効な数値は 512バイトから4096バイトデフォルトの数値は 4096バイト max-udp udp-size 数値 ; server IP アドレス / プリフィックス { 回答時に送信するEDNS0のUDPメッセージの最大値を指定する edns yes no ; 有効な数値は 512バイトから4096バイト edns-udp udp-sise 数値 ; デフォルトの数値は 4096バイト max-udp udp-size 数値 ; server ステートメント特定のDNSサーバを対象とする場合に作成する dig コマンドでみる EDNS0 se. any +bufsize=3000 edns yes no ; 指定のリモートサーバとの通信時にEDNSを使用するかどうかを指定するデフォルトはyes +bufsize=xx で受信可能なサイズを通知 TCP ではないので ( 省略 ) ;; Truncated, retrying in TCP mode. ;; Query time: 306 msec が表示されていない ;; SERVER: #53( ) ;; WHEN: Tue Feb 23 14:32: ;; MSG SIZE rcvd: 2699 受信パケットのメッセージサイズは 2699 バイト

13 DNS パケットサイズと問題点 DNS のやり取りでは通常 UDP を利用するパケットサイズは 512 バイト以下としそれを超える場合は TCP に切り替える仕組みとなっているただし EDNS0 に対応していればパケットサイズが 512 バイトを超えても UDP で扱える問題点 1 TCP 53 番ポートを閉鎖しているFW 等がある場合 TCPフォールバックに切り替わった後にTCPセッションがはれないために名前解決に失敗する解決方法双方向で送信元ポート番号がTCP 53 番のポートを開放するファイアウォール DNS サーバ 1 UDP で問い合わせ 2 UDP で応答 (TC=1) 3 TCP セッション DNS サーバ TCP セッションに失敗するため問い合わせができない TCP 53 を禁止

14 問題点 2 お互いがEDNS0 対応している場合 512バイトを超えるUDPパケットを扱うことができるが古い装置やOSでは 512バイトを超えるUDPパケットを破棄するものがある解決方法 EDNS0に対応したバージョンに上げるまたは装置の取替えファイアウォール DNSサーバ DNSサーバ (EDNS0 対応 ) 1 UDPで問い合わせ (EDNS0 対応 ) 2 UDP で応答応答がないため TCP に切り替えて問い合わせすることもできず名前解決に失敗する DNS UDP 512 バイト超のパケットを破棄

15 問題点 3 途中にICMPエラーを返さなかったりフラグメントしない装置がある場合 MTU 問題により名前解決ができない解決方法 IMCPエラーを返すようにするまたはフラグメントを許可する DNSサーバ A DNSサーバ B (EDNS0 対応 ) MTU=1400 MTU=1500 (EDNS0 対応 ) 1 UDPで問い合わせ 2 UDP で応答応答パケットサイズ 2000 バイト MTU 値が 1400 超のためフラグメントが必要だがフラグメントしない ICMP エラーを送信元に返さないためまた UDP であるため DNS サーバ B はパケットの再送をしないその結果 DNS サーバ A に応答が届かない

16 DNSSEC DNS のリソースレコードに電子署名を付加する事により DNS の応答パケットの完全性を証明するための仕組み署名が正しいことを証明するためにゾーンを署名する ZSK 公開鍵とその ZSK 公開鍵と自身を証明する KSK 公開鍵の 2 つの鍵が使用される DNSSEC の仕組仕組みキャッシュサーバ側署名したAのKSK 公開鍵署名したAのZSK 公開鍵 AのKSK 公開鍵 AのKSK 公開鍵署名したデータ ( レコード ) A の ZSK 公開鍵 DNSSEC で問い合わせコンテンツサーバ A 側データ ( レコード ) A の ZSK 公開鍵 A の KSK 公開鍵ハッシュ化ハッシュ化ハッシュ化署名したデータ ( レコード ) ハッシュ化署名したAのZSK 公開鍵比較して KSK 公開鍵比較して ZSK 公開鍵の比較してレコードの署名したAのKSK 公開鍵 AのZSK 秘密鍵の信頼性を確認信頼性を確認信頼性を確認データ ( レコード ) KSK 秘密鍵で暗号化 AのZSK 公開鍵ハッシュ化ハッシュ化ハッシュ化 AのKSK 公開鍵署名したデータ ( レコード ) 署名したAのZSK 公開鍵上位 DNSから取得した AのZSK 公開鍵データ ( レコード ) 回答署名したAのKSK 公開鍵 AのKSK 公開鍵 (DS RR) 信頼の連鎖上図では AのKSK 公開鍵を証明する方法がないそこで AのKSK 公開鍵を上位のDNSサーバに登録署名してもらうことによりそのKSK 公開鍵が正しいことを証明しさらに上位のDNSサーバは自身のKSK 公開鍵を上位のDNSサーバに登録証明してもらう最終的にはルートDNSサーバにたどり着くルートDNSサーバのKSK 公開鍵だけはあらかじめキャッシュサーバに登録しておく

17 DNSSEC の設定 ( キャッシュサーバの場合 ) キャッシュサーバで必要必要な設定設定は 2つ 1 DNSSEC を有効有効にする # vi named.conf options { dnssec-enable yes no ; dnssec-validation yes no ; # DNSSEC を有効にするかどうか BIND9.5 以降はデフォルトで yes # DNSSEC による検証を行うかどうか BIND9.5 以降はデフォルトで yes 例 ) # vi named.conf options { dnssec-enable yes ; dnssec-validation yes ; 2 トラストアンカーを設定設定する DNSSECを構成する最上位のゾーンのKSK 公開鍵を登録するすでにルートDNSがDNSSECに対応しているので今回はルートDNSのKSK 公開鍵を登録する named.confの設定では managed-keysステートメントまたはtrusted-keysステートメントを使用するトラストアンカー (KSK 公開鍵 ) を取得取得する # dig +noall +answer DNSKEY. > 出力ファイル # ルート DNS の DNSKEY レコードをファイルに保存例 ) # dig +noall +answer DNSKEY. > root-dns.key # ファイルの中に ZSK 公開鍵と KSK 公開鍵がある DNSKEY がある行は ZSK 公開鍵を示す DNSKEY がある行は KSK 公開鍵を示す

18 トラストアンカーを設定設定する managed-keys { # 登録したトラストアンカーのKSK 公開鍵で署名された " 信頼するゾーン " initial-key 新しいトラストアンカーであればそれを信用する "KSK 公開鍵 "; BIND9.7 以上で対応 trusted-keys { # managed-keyとほぼ同じだが KSK 公開鍵の変更 " 信頼するゾーン " "KSK 公開鍵 "; があれば手動で変更する必要がある BIND9.6まではこちらしか使えない例 # vi named.conf managed-keys { # ルートDNSゾーン (.) に対してトラストアンカーを設定 "." initial-key "AwEAAagAIKlVZrpC6I ( 省略 ) named.conf 設定例 options { dnssec-enable yes; dnssec-validation yes; trusted-keys{ "." "AwEAAagAIKlVZrpC6I ( 省略 ) mqramrlkbp1dfwhyb4n7knnnulq QxA+Uk1ihz0=";

19 DNSSEC の設定 ( コンテンツサーバの場合 ) コンテンツサーバの場合はキャッシュサーバで行った 2 つの設定以外に管理するゾーンの署名が必要 1 ZSK 鍵と KSK 鍵の作成 # dnssec-keygen -a 鍵方式 -b ビット数 -r 鍵作成に利用するファイル -n ZONE ゾーン名 # ZSK 鍵 ( 公開鍵と秘密鍵 ) の作成 # dnssec-keygen -a 鍵方式 -b ビット数 -r 鍵作成に利用するファイル -f KSK -n ZONE ゾーン名 # KSK 鍵 ( 公開鍵と秘密鍵 ) の作成例 ) # dnssec-keygen -a RSASHA1 -b r /dev/urandom -n ZONE example.jp # dnssec-keygen -a RSASHA1 -b r /dev/urandom -f KSK -n ZONE example.jp ( 生成されるファイル ) Kexample.jp.+005+{ 識別番号 }.key # ZSK 公開鍵 Kexample.jp.+005+{ 識別番号 }.private # ZSK 秘密鍵 Kexample.jp.+005+{ 識別番号 }.key # KSK 公開鍵 Kexample.jp.+005+{ 識別番号 }.private # KSK 秘密鍵公開鍵と秘密鍵の識別番号は同じになる ZSK 鍵かKSK 鍵かはそれぞれの公開鍵の中身を見ないと分からない ZSK 鍵は KEY 256 KSK 鍵は KEY 257 となる 2 作成した ZSK 公開鍵と KSK 公開鍵をゾーンファイル内に追記する追加した後ゾーンファイルのシリアル番号を変更する # cat 1 で作成された ZSK 公開鍵ファイル >> ゾーンファイル # cat 1 で作成された KSK 公開鍵ファイル >> ゾーンファイル例 ) # cat Kexample.jp key >> example.jp.zone # cat Kexample.jp key >> example.jp.zone

20 3 作成した ZSK 秘密鍵を使用してゾーンファイルに署名を行う同時に DSSET のファイル (DS レコードが記述されたファイル ) も作成される # dnssec-signzone -o ゾーン名ゾーンファイル出力ゾーンファイル例 ) # dnssec-signzone -o example.jp example.jp.zone example.jp.zone.signed ( 生成されるファイル ) example.jp.zone.signed # 署名されたゾーンファイル dsset-example.jp. # DSSETファイル 4 3 で作成した署名済みゾーンファイルを named.conf に登録する # vi named.conf zone ゾーン名 { type master; // file " 署名前のゾーンファイル "; # 署名前のゾーンファイルは削除するか file "3 で作成したゾーンファイル "; コメントアウトする例 ) # vi named.conf zone example.jp { type master; // file "zonefile/example.jp.zone"; file "zonefile/example.jp.zone.signed";

21 5 3 で作成した DSSET の内容 (DS レコード ) を上位の DNS サーバに登録してもらう例 ) # more dsset-example.jp. example.jp. IN DS B( 省略 )2E013F919 example.jp. IN DS D82A( 省略 ) 5B50DC27 named.conf 設定例 options { dnssec-enable yes; dnssec-validation yes; trusted-keys { "." "AwEAAagAIKlVZrpC6I ( 省略 ) mqramrlkbp1dfwhyb4n7knnnulq QxA+Uk1ihz0="; zone example.jp { type master; // file "zonefile/example.jp.zone"; file "zonefile/example.jp.zone.signed";

22 DNSSEC の動作確認 dig コマンドを使って DNSSEC による問い合わせの確認をすることができる例 ) org ドメインの SOA レコードについて DNSSEC を使って問い合わせた結果 # org. soa +dnssec ( 省略 ) +dnssec オプションをつける EDNS0 も自動的に有効 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1 DNSSEC の問い合わせができている場合場合は ad ビットが立つ ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 EDNS0はデフォルトで ;; QUESTION SECTION: edns-udp-sise=4096で問い合わせる ;org. IN SOA ;; ANSWER SECTION: org. 451 IN SOA a0.org.afilias-nst.info. noc.afilias-nst.info. ( 省略 ) org. 451 IN RRSIG SOA ( 省略 ) org. ( 省略 ) 9sqxzy2h1uW206l/3seemCplRbR0jPM86QzsMNLmt4ZTrRvycChXXYNa UFc= SOA レコードに対する RRSIG が付与 ;; AUTHORITY SECTION: org. 451 IN NS d0.org.afilias-nst.org. ( 省略 ) org. 451 IN NS a2.org.afilias-nst.info. org. 451 IN RRSIG NS ( 省略 ) org NSレコードに対するRRSIGレコード ( 省略 ) が付与 /GHkkjtLZrDZEMN SgXgMTVi0AYwYMq3785j/91glI2pxAyBXR5J37VP0WSWOkdsDCq5KJFZ KB0=

23 DNSBL(DNS Black List) DNSBL とはスパムメールの送信や無制限に中継を行っているホストなど拒否したいIPアドレスを集めたリスト DNSの仕組みを利用して情報を提供しているメールサーバや掲示板ブログサイトなどでDNSBLが利用されている DNSBL はそうした仕組みを利用したデータベースの総称であるまた DNSBL の正式名称は DNS Black List というわけではないドメインを対象にした RHSB や 2 ちゃんねるが採用しているプロキシを対象にした BBQ などもある DNSBL の基本的基本的な仕組仕組み DNSBL 対応 DNSBLを提供するメールサーバ業者のDNSサーバ 1 メール送信 dnsbl.example.com A? (2) dnsbl.example.com A? dnsbl.example.comゾーン (1) メール送信から 3 A : のメールは拒否 A A (4) から (3)NXDOMAIN A のメールは受信 : 拒否したいアドレス ( 左側 ) が登録されている登録されていることが重要なので返すアドレスは以外でも良い

24 sendmail での設定例自分が使用したいDNSBLのデータベースをFEATUREの部分に追加する 1 sendmail.mcに追加 # vi /etc/mail/sendmail.mc FEATURE(dnsbl,`all.rbl.jp all.rbl.jp')dnl 2 sendmail.mc から sendmail.cf を作成 # m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf 3 sendmail.cf の再読み込み # service sendmail reload DNSBL の問題点以下の理由で最近ではDNSBLの利用に否定的な立場の人が多い動的 IPの場合他のユーザがスパムを発信したためにアドレス全体がDNSBLに登録されたり登録された動的 IPをたまたま割り当てられた無関係なユーザが迷惑を被ることがある DNSBLの管理がきちんとされていないデータベースがある DNSに無駄な負荷がかかっている DNSBL に登録登録されているかされているか確認確認するする方法 DNSBLを管理しているサイトやそれらをまとめたサイトで確認ができる ( コマンドでも可能 ) 例 ) 主要なブラックリスト一覧が記載されたHP いろいろと問題の多いSORBSのHP 2chが運営するBBQ

e164.arpa DNSSEC Version JPRS JPRS e164.arpa DNSSEC DNSSEC DNS DNSSEC (DNSSEC ) DNSSEC DNSSEC DNS ( ) % # (root)

e164.arpa DNSSEC Version JPRS JPRS e164.arpa DNSSEC DNSSEC DNS DNSSEC (DNSSEC ) DNSSEC DNSSEC DNS ( ) % # (root) 1.2.0.0.1.8.e164.arpa DNSSEC Version 1.0 2006 3 7 JPRS JPRS 1.2.0.0.1.8.e164.arpa DNSSEC DNSSEC DNS DNSSEC (DNSSEC ) DNSSEC DNSSEC DNS ( ) % # (root) BIND DNS 1. DNSSEC DNSSEC DNS DNS DNS - 1 - DNS DNS