インターネット10分講座：DNSSEC - JPNIC
今回の10分講座は、各TLDが対応を表明するなど導入の機運が高まりつつある、DNSSECについて解説します。 1. DNSSECの予備知識 1.1 DNSの仕組み まずはじめに、DNSではエンドユーザーのPCなど、DNSを利用するクライアントがどのようにドメイン名の情報を得るのか、その流れについて簡単に説明します(図1)。 図1：DNS 問い合わせ (1)クライアントから、所定のネームサーバに対し、問い合わせを依頼します。具体的には、ドメイン名に関する情報はリソースレコードという形式で管理されているので、www.nic.ad.jpというドメイン名のIPアドレスを知りたい場合にはwww.nic.ad.jpのAレコード(IPアドレスを格納するリソースレコード)を問い合わせます。 (2)依頼を受けたネームサーバは、問い合わせ内容を元に、ルートサーバ※1から委任をたどりながら順に問い合わせを行い、
「DNSに対する最悪の攻撃」 迅速なパッチ適用を推奨 ATHENEによると、KeyTrapを悪用した場合、単一のDNSパケットが結果的にCPUの使い果たしを誘導し、「Google Public DNS」やCloudflareのDNSなど広く使われているDNS実装やパブリックDNSプロバイダーを全て停止させることが可能だ。発表によると「BIND 9」を16時間ダウンさせたとされている。なお、この欠陥は「CVE-2023-50387」として特定されている。 この攻撃はインターネットの基本的な機能に深刻な影響を与え、世界中のWebクライアントの大部分が利用不能になる可能性がある。主要なDNSベンダーはこの攻撃を「これまでに発見されたDNSに対する最悪の攻撃」と呼んでおり、状況の重大さが指摘されている。 KeyTrapを悪用するサイバー攻撃者は、DNSSECを検証するDNSリゾルバを利用する全ての
("Breaking DNSSEC" 日本語訳) D. J. Bernstein University of Illinois at Chicago 1993年11月 Galvin: 「ある朝、DNSワーキンググループにおけるDNSセキュリティチームの メンバーがヒューストンのIETFで会った」 1994年2月 Eastlake-Kaufman、 dns-security メーリングリストでの数ヶ月の議論のあと 「DNSSEC」プロトコル仕様が作られる。 DNSSECの調査研究に、百万ドル単位の政府予算が使われる: たとえば DISA から BIND company へ、 NSF から UCLA へ、 DHS から Secure64 Software Corporation へ。 現在のインターネットには、 およそ 80000000個の *.com ドメインがある。 2008年8月20日:
[速報] Amazon Route 53 が DNSSEC に対応しました！ #reinvent | DevelopersIO
AWS re:Invent 2020 年内期間最終日の今日、すばらしいニュースが飛び込んできました。 ついに、Amazon Route 53がDNSSECに対応しました！ You can now enable DNSSEC signing for all existing and new public hosted zones, and enable DNSSEC validation for Amazon Route 53 Resolver. ということで、Route 53にホストしているゾーンに対してDNSSEC署名することも、Route 53リゾルバでDNSSEC署名を検証することも、両方向で対応したとのこと！ ドメイン情報を払い出す Route 53 レジストラは既にDNSSEC対応していましたから、これで実質死角ナシになりましたね！ DNSSECとは すごくざっくりいうと、DNS
![[速報] Amazon Route 53 が DNSSEC に対応しました！ #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/1691f45c9a149fa23ecf71949f6c6eff39c1915c/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F11%2Feyecatch_reinvent-2020-breakingnews-sokuho.jpg)
DNSSEC はなぜダメなのか
DNS に依存している 腐り沈みゆく船 (DNS) の上に継ぎ足しで新しい船を築くのは愚か DNSSEC は難しすぎる 強度の弱い暗号を用いているため、鍵を定期的に更新しなければいけない (そして失敗) 鍵を証明する情報を定期的に上位組織 (委任元) に預けて署名し直してもらわなくてはいけない (そして失敗) ルートの鍵を証明する情報を定期(?)的に世界の検証サーバたちに配布し直さなくてはいけない (歴史上始めての更新が今年行われつつあり障害発生が危惧されている) 運用事業者の移管の際に事業者間で安全に鍵を受け渡すことが困難 運用事業者の移管の際に一旦署名を外すのは安全性と可用性を下げる DNSSEC 署名対応事業者から非対応事業者への移管で事故も起きている (移管元も移管先も委任元に預けた鍵情報を消さなかったのが原因 / 一部の有志たちが作成したガイドラインがあって移管先が消すことになっ
DNSSEC再入門
インターネットの重要な基盤技術の1つであるDNSに対して新たな攻撃手法が公開され、その安全性が脅かされている。DNSにセキュリティ機能を提供するための技術であり、普及が進んでいるDNSSECについて、仕組みと運用方法を紹介する。（編集部）
次世代のセキュリティ拡張DNSSECをBIND 9で実現：実用 BIND 9で作るDNSサーバ（13）（1/3 ページ） 現在、標準化作業が進行中のDNSSEC。その仕組みとBIND 9での実現方法を解説する。後半では、スプリットDNSの設定方法を紹介。（編集局） 今回は、DNSのセキュリティ拡張である「DNSSEC」とスプリットDNSを実現する「VIEW」について解説します。DNSSECは、まだ標準化の議論が活発に行われている最中です。そのためBIND 9では実装が不完全なものもあります。 ゾーン情報の信頼性を保証するDNSSEC 第9回で、ゾーン情報が改ざんされる危険を回避する手段としてDNSSEC（DNS Security Extension：DNSセキュリティ拡張）を紹介しました。現在、DNSSECはIETFのDNSEXT（DNS Extensions）ワーキンググループで標準化の
キャッシュDNSサーバのDNSSEC対応
今回は、DNSSECの検証機能を有効にしたキャッシュDNSサーバを構築・運用する方法について解説する。 DNSSECにおけるキャッシュDNSサーバの役割 キャッシュDNSサーバは、名前解決を依頼するクライアントと権威DNSサーバの間に立ち、反復検索を行うサーバである。DNSSECにおいて検証を担当するものを「バリデータ（Validator）」と呼び、多くの場合キャッシュDNSサーバがバリデータを担当する。 第2回でも簡単に説明したが、DNSSECの検証を行うためには信頼の連鎖の起点となる情報が必要となる。これを「トラストアンカー（Trust Anchor）」と呼ぶ。バリデータとなるキャッシュDNSサーバは、トラストアンカーを起点に、DNSSECの信頼の連鎖を検証していくことになる。 DNSの階層構造における委任の起点がルートゾーンであることから、一般的にはルートゾーンの公開鍵情報をトラスト
内部（192.168.10.0/24）に対してはプライベートアドレスで正引き／逆引きができ、キャッシュサーバ機能を有効にします。外部（内部以外のネットワーク）に対してはグローバルアドレスで正引き／逆引きができ、キャッシュサーバ機能を無効にします。このような場合、通常は次のように2つのDNSサーバを設定する必要があります。 options { directory "/var/named"; pid-file "/var/run/named/named.pid"; recursion yes; }; zone "." { type hint; file "named.ca"; }; zone "localhost" { type master; file "local.zone"; }; zone "0.0.127.in-addr.arpa" { type master; file "loca
最近のDNSSECの動向
2010/10/19 コース：元祖こってり 「元祖こってり」記事はネットエージェント旧ブログ[netagent-blog.jp]に掲載されていた記事であり、現在ネットエージェントに在籍していないライターの記事も含みます。 最近のDNSSECの動向 こんにちは、ネットエージェント株式会社研究開発部、大阪支社の山口です。今回は、DNS のキートピックのひとつである DNSSEC（DNS Security Extension） について紹介したいと思います。 ----- DNS（Domain Name System） とは、ご存じの通り、インターネット上に展開されている階層的な分散型データベースのことで、主にホスト名とIPアドレスの対応付け等に使用されています。現在のインターネットにおいては DNS はもはや必要不可欠なシステムであり、インターネット技術の根幹といっても過言ではありません。しかし
「実践DNS - DNSSEC時代のDNSの設定と運用 -」の献本を頂きました。 ありがとうございます。 私はDNSのことが良くわからなくて「勉強したい」と思いつつ色々調べてはいるのですが、DNSの情報がまとまって述べられている書籍が発見できずに困っているところだったので、非常に参考になりました。 これまで、通称「バッタ本」と呼ばれているDNS & BINDが最も詳しいDNS本だったと思うのですが、バッタ本はBINDの本であって、DNSの本ではありませんでした。 そういう意味で、「実践DNS」は、技術としてのDNSに関してキッチリ書いてある良書だと思います。 豪華な執筆陣 「実践DNS」は、DNSやDNSSECに関して日本国内で考え得る最高レベルの執筆陣によって執筆されていると思いました。 著者は3名とも「.jp」のJPドメイン名の登録管理業務とDNSの運用を行っている株式会社日本レジスト
はじめに JPRSでは、DNSのセキュリティ拡張方式であるDNSSEC[*1]を、2011年1月16日にJPドメイン名サービスへ導入する予定で準備を進めています。 この文書では、DNSSEC導入の背景と、今後JPRSが予定しているDNSSEC導入関連の活動について説明します。 *1 DNSSEC: DNS Security Extensions DNSSEC導入の背景 DNSはインターネットの根幹を支える重要な仕組みであり、インターネットが社会基盤として重要性を増す中で、その安定的な運用が求められています。これに加えて、近年、DNS応答の偽造により引き起こされるセキュリティ上の脅威が現実のものとなり、このような脅威を排除し、安心して利用できるDNSであることも強く求められるようになってきました。 DNSに関するセキュリティの向上については、IETF[*2]において検討が進められ、DNSSE
9月19日にDNSSECで使用されるゾーン署名鍵の更新が行われるのだが、その影響でネットワーク関連のトラブルが発生する可能性があるとし、総務省が注意喚起を行っている（ITmedia、ZDNet Japan）。 DNSSECは、インターネット上における名前解決を行うDNSにおいて、電子署名を用いた信頼性検証を実現する技術。これを利用することで、本来意図していないサーバーに気付かずにアクセスさせるような攻撃を防ぐことができる。 DNSSECではゾーン署名鍵（ZSK）と鍵署名鍵（KSK）の2つの公開鍵が使われており、ZSKは3か月ごと、KSKは5年ごとに更新される（日経ITpro）。KSKの更新は今回が初めてとのことだが、この更新のタイミングでDNSSECで使われる「DNSKEY応答パケット」という公開鍵が含まれるパケットに新旧のKSKおよびZSKが含まれることで、パケットサイズが1400バイト
This web page is designed to test your network's ability to resolve domain names that have been signed with "large" DNSSEC keys. See the explanations below for additional information. Test ID at The tests provided on this web page were developed in 2016, in advance of two changes anticipated for the DNS root zone: (1) an increase in the size of the root zone Zone Signing Key (ZSK), and (2) a rollo
重要なポイント ○COの役割～平常時のHSM（KSK）の有効化～ HSMを有効化するスマートカードが保管された金庫の鍵を預かる スマートカード自身は預からない 第三者であるCOがHSMに直接触る（近づく）ことを避け、第三者がHSMを物理的に壊すリスクを回避できる ○RKSHの役割～緊急時のHSM（KSK）の復旧～ KSKの暗号化バックアップを作る際にHSM内部で使われた（HSM独自の）鍵の一部を預かる KSKそのものを暗号化したもの（の一部）は預からない もしRKSHだけが全員集合しても、KSKは複製できない ○直接の関係者はCO及びRKSHには就任できない 直接の関係者：ICANN、VeriSign、米国商務省（DoC） 不法な業務命令などによる圧力を回避 ○HSMの稼動を止めないことが重要 HSMはICANNの東西の拠点に2台ずつ、計4台稼動する 拠点内及び拠点間の双方において、それぞ
2012/3/21 第3回DNSSECジャパン総会において、DNSSECジャパン設置期間終了につき解散することについて、全会一致で承認されました。 ただし、DNSSEC 2012 スプリングフォーラム 開催のため、開催およびフォローアップに必要な活動に限り、設置期間終了後も活動を継続する、という付帯事項がありました。 イベントの開催から少し時間が経ってしまいましたが、資料等の掲載を終えることができ、おかげさまにてこれにて解散となります。 現状のコンテンツ管理、事務局機能の一部につきましては、日本DNSオペレーターズグループ へ移管し、維持してまいります。 期間限定の組織ということで発足し、2年半程の活動を経て解散となりますが、まだまだDNS、DNSSECを取り巻く環境には課題が山積しています。 DNSSECジャパンでの活動は終了しますが、今後とも業界内で連携して課題解決に取り組んで行くこと
インターノット崩壊論者の独り言 - 総務省の注意喚起は FUD - DNSSEC に関する一連の注意喚起で混乱中の皆様へ
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 総務省をはじめとする一連 (NISC,JPRS,JPNIC,JPCERT/CCあるいはそれらを元にした報道) の DNSSEC KSK ロールオーバーに関する注意喚起を鵜呑みにしてはいけません。総務省データ通信課の高村信企画官は注意喚起文書の文面が嘘も方便あるいは FUD であることを認め、さらには注意を喚起するためには「Terrible Story (恐ろしい話) が必要だった」とまで発言されています。(先日の記事参照) 彼らの説明や対策は DNSSEC 推進のための余計な方策が組み込まれているために、非常に複雑なものになっている一方で説明すべきことを説明していない
DNSSECの役割と動作の概要
DNSSECが提供するもの 第1回で説明したとおり、DNSSEC（Domain Name System Security Extensions：DNSセキュリティ拡張）を導入すれば、DNSの応答が「本当に正しい」ことを検証できる。 「本当に正しい」とは、どういう状態を意味するのだろうか？ 正しいことを検証するには、以下の2つの事項を検証できればよい。 ・データの出自認証（Data origin authentication） →ゾーンの管理者が登録したとおりの内容であること ・データの完全性（Data integrity） →通信途中で応答が書き換えられたり、応答の一部が損失したりしていないこと DNSSECの機能は、従来のDNSの仕組みを拡張する形で実装しており、従来のDNSと上位互換性を保っている。具体的な仕組みは後述するが、DNSSECに対応した権威DNSサーバおよびゾーンの検証は、
独自開発によるDNSSECの実現 DNSに対するセキュリティ機能の拡張であるDNSSECは、近年になって導入が開始されるようになったものの、実装がそろっていないため普及が遅れています。そこで、IIJでは、DNSSEC実現のためのすべての処理を独自に実装することに。特別な知識がなくても、ご利用のドメインをDNSSEC対応にすることを可能にしました。 ここでは、DNSSEC実現のための処理を独自開発した経緯を紹介します。 DNSSECとは IIJが提供している「IIJ DNSアウトソースサービス」は世界的に見てもまだ提供例の少ない、DNSSEC（DNS Security Extensions）に対応したDNSサービスです（2011年9月現在）。つまり、一歩進んだ安全なDNSサービスだと言えるでしょう。 さて、安全なDNSサービスとはなんでしょう。様々な観点がありますが、一歩進んだという意味では
（2016/3/27追記）0.88ドルというのは期間限定のキャンペーン価格のようです。普段はもっと高いのかもしれません。 DNSSECって名前は聞くけど詳細は知らないな、というくらいの理解度の人って多いんじゃないでしょうか。実は筆者もそんな一人だったのですが、この連休中に独自ドメインを取得してDNSSEC対応させてみました。DNSSEC対応できるレジストラ・ドメインの組み合わせとしてはNamecheapで.pwドメインを取るのが探した範囲では最安値で、最初の1年間だけ維持するなら0.88ドル、翌年以降更新する場合でも年額7.88ドルに収められることがわかりました。 本稿では一連の顛末を紹介します。 そもそもレジストラやドメインのDNSSEC対応って何？ DNSSECにおいて、レジストラはどういう役割を担うのでしょうか？レジストラの選択がDNSSECの利用にどういう影響を与えるのでしょうか？
2010/07/20 7月8日、9日の2日間に渡って、インターネット技術者やネットワークオペレーターの集う「JANOG 26 Meeting」が東京・恵比寿にて開催された。インターネットを運営するために必要な情報交換やネットワーク事業者の課題についてディスカッションする場として開催されてきたものだ。 26回目のミーティングとなるJANOG26では、IPv4アドレス在庫の枯渇を前にいよいよ注目が集まるIPv6の導入、運用にまつわる話題から、インターネットエクスチェンジ（IX、通信事業者の接続点）の取り組みを紹介するパネルディスカッション、あるいは国際化ドメイン名などネットワークオペレータ以外にもかかわってくる話題があれば、一方で国際通信を支える海底ケーブルをテーマにしたセッションがあるなど、多岐にわたった。 この記事ではその中から、導入が進みつつあるDNSSECが及ぼすインパクトを紹介した「
--------------------------------------------------------------------- ■BIND 9.xの大量のDNSSEC検証要求受信時におけるサービス停止について - バージョンアップを強く推奨 - 株式会社日本レジストリサービス（JPRS） 初版作成 2012/07/25（Wed） --------------------------------------------------------------------- ▼概要 BIND 9.xの高負荷環境下におけるキャッシュデータの取り扱いの不具合によ り、namedに対する外部からのサービス不能（DoS）攻撃が可能となることが、 開発元のISCから発表されました。本脆弱性により、提供者が意図しないサー ビスの停止が発生する可能性があります。 該当するBIND 9.xを利用してい
DNSSEC の設定
2010-10-13 Network/Ether 2010-10-12 Linux/Memo/network/誰がそのアドレスを使っているのか? Linux/cfg/utvpn-v101-7101 2010-10-11 Linux/Memo/network 2010-10-10 Linux/cfg/net-snmp-5.6 2010-10-09 Linux/cfg/libiconv-1.12 Linux/cfg Linux/cfg/samba-3.5.6 2010-10-08 Linux/cfg/xinetd-2.3.14 Linux/cfg/mecab-0.98 Linux/cfg/sendmail-8.14.2 Linux/cfg/mysql-5.1.51 Linux/cfg/openssh-5.6p1 Linux/Memo/DNS
セキュリティシンクタンクの米Black Hatとインターネット協会の共催によるカンファレンス「Black Hat Japan 2008」が10月5日から10日まで、東京・新宿の京王プラザホテルで開催中だ。 まず、8日までの4日間は、授業形式で詳細な知識を解説する「トレーニング」を実施、続いて9日・10日にセキュリティ専門家らによる講演「ブリーフィングス」を実施する。 9日に行われるブリーフィングスの基調講演には、セキュリティ研究者のDan Kaminsky氏が登場する。Kaminsky氏は、7月にその存在が広く公になったDNSキャッシュポイズニングの脆弱性（通称「カミンスキー攻撃」）の発見者。8月にラスベガスで行われたBlack Hatに引き続き、日本でもこの脆弱性について講演する予定だ。今回、Kaminsky氏にメールでインタビューした。 なお、ブリーフィングス2日間の参加費は8万950
1月10日にComcastがDNSSECに完全対応したという発表を行っていましたが、DNSSEC対応することによって、技術的には間違った設定を行ってないのに多数の抗議が来てしまうという事例が発生してしまっていたようです。 障害が発生したのは1月18日ですが、それに関するレポートが1月24日に公表されています。 Comcast: Analysis of DNSSEC Validation Failure (PDF) Internet Society: Comcast Releases Detailed Analysis of NASA.gov DNSSEC Validation Failure 1月18日に、NASA.govがDNSSECでの鍵更新に失敗したため、DNSSECを使っているとNASA.govの名前が引けないという状況になりました。 その状況に気がついたComcastユーザが「C
--------------------------------------------------------------------- ■DNSブロッキングとDNSSECを共存させるための手法について 株式会社日本レジストリサービス(JPRS) 2010/07/28(Wed) --------------------------------------------------------------------- ▼本文書の概要・目的 本文書は、児童ポルノ流通防止の一手法として実施が検討されているいわゆる 「DNSブロッキング」と、DNSをより安全に利用するための技術として導入が進 められている「DNSSEC」を、互いの影響を最小限にする形で共存させるための 手法について考察・記述することにより、インターネットの安定運用に資する ことを目的としている。 なお、本文書では、DNSブロッキ
他のDNS Tips「DNSSECの仕組みを教えてください（今後公開予定）」にあるように、DNSSECでは、DNSにおける応答が改ざんされていないこと・欠落していないことを確認できるようにするため、署名と検証という仕組みを使用する。そのため、DNSSECを構成する要素としては、DNS Tips「DNSを構成する要素を教えてください（今後公開予定）」で示された要素に以下のものが加わる。 署名（Signature） 公開鍵（Public Key） 署名者（Signer） バリデーター（Validator） トラストアンカー（Trust Anchor） 以下、それぞれについて解説する。 署名（Signature） DNSSECにおける署名は、公開鍵暗号方式による電子署名である。RRSIGレコードとして署名者がゾーンに登録し、バリデーターがDNSの応答の検証に用いる。 公開鍵（Public Key
2011/04/12 SSLにDNSSECを導入することの批判 コモド事件などからSSLの信頼が揺らいでいる。そこで、IETFではDNSSECを導入して、SSL証明書の信頼を確認しようとする動きがある(DANE WG)。そんな中、セキュリティ研究者のMoxie Marlinspike氏がブログに「SSL And The Future Of Authenticity」と題するエッセイで、現在のCAシステムには問題があることを認めつつ、DNSSECを使うことを強く警告している[slashdot]。DNSもCAも同じような階層的な信用システムを使っている以上、CAシステムと何ら変わりない。DNSSECの場合は3つの階層クラスを無条件に信用しなければならない。レジストラ: GoDaddyのようなレジストラは果たして信用できるか? TLD: .comの場合はCAシステムでも登場するVeriSignで
DNSCheck[.SE] Test your DNS-server and find errors DNSSEC Debugger[VeriSign Labs] DNSSEC Validator[nic.cz] FireFox add-on DNSViz[Sandia National Laboratories] A DNS visualization tool OpenDNSSEC DNSSEC ジャパン 運用技術 WG はじめに この文書では、リリース5以前の RedHat Enterprise Linux およびその互換 OS をセカンダリサーバとして用いているゾーンで DNSSEC を有効にしたときに観測された問題点を示し、DNS の運用者に、当該事象に対する注意を喚起したい。 ここで示す問題は、セカンダリサーバの運用者が DNSSEC への対応を意図していない場合に起きることに
権威DNSサーバのDNSSEC対応
インターネットの重要な基盤技術の1つであるDNSに対して新たな攻撃手法が公開され、その安全性が脅かされている。DNSにセキュリティ機能を提供するための技術であり、普及が進んでいるDNSSECについて、仕組みと運用方法を紹介する。（編集部） 古くから検討されてきたDNSSEC 近年注目を集めているDNSSECだが、実はその検討は1993年ごろから始まっている。また、最初の標準としてRFC 2065が発行されたのは1997年のことである。 それから継続して検討が進められ、現在のDNSSECの技術仕様は、2005年に発行されたRFC 4033、RFC 4034、RFC 4035（注1）がベースとなっている。これに加え、第3回でも触れたキャッシュDNSサーバにおけるトラストアンカーの自動更新の仕様を定めたRFC 5011が2007年に、またゾーンの列挙を困難にするためのNSEC3拡張を定めたRFC
DNSSEC
図1 DNSSECのしくみ 電子署名によって正しいDNSサーバーからの回答であることを証明する。DNSキャッシュ・ポイズニングなどの攻撃を防ぐ。 DNSSECとは，DNSサーバーから送られてくるIPアドレスとホスト名の対応情報の信頼性を証明するセキュリティ拡張機能である。DNSキャッシュ・ポイズニングのようなDNS応答のなりすまし攻撃を防ぐためのものだ。DNSキャッシュ・ポイズニングとは，DNSサーバーに一時的に保存（キャッシュ）してあるホスト名とIPアドレスの対応情報を偽の情報に書き換える攻撃のことである。この攻撃を受けると，ユーザーのWebブラウザは偽のWebサイトに誘導されてしまう。 DESSECでは，応答を送信するDNSサーバーが秘密鍵を使って応答に署名し，受信する側が公開鍵で検証する(図1)。秘密鍵を持っていないと正しく署名を付けられないので，署名の検証によって偽の応答を検知でき
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
そのDNSの応答、本当に正しいものですか？ 「.jp」でも正式導入、DNSSECの仕組みと意義＜前編＞ -INTERNET Watch
「DNSに対する最悪の攻撃」 DNSSEC設計の根幹に関わる脆弱性「KeyTrap」が見つかる
DNSSECを破る ("Breaking DNSSEC" 日本語訳)
あなたのキャッシュDNSサーバー、DNSSECしてますか？ 「.jp」でも正式導入、DNSSECの仕組みと意義＜後編＞
次世代のセキュリティ拡張DNSSECをBIND 9で実現
＠IT：次世代のセキュリティ拡張DNSSECをBIND 9で実現（3/3）
[書籍]実践DNS - DNSSEC時代のDNSの設定と運用 -:Geekなぺーじ
JPドメイン名サービスへのDNSSECの導入予定について | JPドメイン名についてのお知らせ | 新着情報一覧 | JPRS
Amazon.co.jp: 実践DNS DNSSEC時代のDNSの設定と運用: 民田雅人 (著), 森下泰宏 (著), 坂口智哉 (著), 株式会社日本レジストリサービス（JPRS） (監修): 本
【イベント】DNSSEC導入の負荷実験データに大きな関心、海底ケーブル埋設＆修理ネタも
DNSSECの公開鍵更新でトラブルが発生する可能性、事前の検証を推奨 | スラド IT
DNSSEC Key Size Test
DNSSEC 関連情報 ～ルートゾーンにおけるKSKの管理方法～ / JPRS
DNSSECジャパン
IIJ、DoT/DoHとDNSSECをDNSキャッシュサーバーに導入、セキュリティを強化
【】現実になってきたDNSSEC、しかし関係者は手探り状態？
JPドメイン名サービスへのDNSSEC導入、2011年1月16日に決定
IIJの技術・活動詳細 | 研究・開発 | IIJ - 独自開発によるDNSSECの実現
DNSSEC対応の独自ドメインを年額$0.88で運用できるよという話 - hnwの日記
DNSSECのインパクトは？ オペレーター必携の「道具」とは？ － ＠IT
BIND 9.xの大量のDNSSEC検証要求受信時におけるサービス停止について
DNSSECの仕組みと KSKロールオーバへの対応 - DNSSEC-seminar2017
DNSSECは解決策になりえるか？ DNSの脆弱性の発見者に聞く
NASAのDNSSEC鍵更新失敗でComcastが非難された事例:Geekなぺーじ
DNSSECの導入・普及へ、「DNSSECジャパン」設立
DNSブロッキングとDNSSECを共存させるための手法について
DNSSECを構成する要素を教えてください
yebo blog: SSLにDNSSECを導入することの批判
リリース5以前のRedHat Enterprise Linuxおよびその互換OSをセカンダリサーバとして用いるゾーンへのDNSSECの導入にあたっての注意喚起 « DNSSECジャパン