DNSSEC では、各ゾーンの権威 (authoritative) サーバが使う鍵は上位ゾーンの権威サーバによって署名され保証されます。 DNS ツリーのルート以下全てのゾーンが DNSSEC に対応していれば、リゾルバが持つべき鍵はルートゾーンの署名に使われる鍵ひとつとなります。しかし DNSSEC が普及していない現状では、DNSSEC に対応している個々のゾーンの鍵を各リゾルバが持っておく必要があり、DNSSEC に対応したゾーンが増えればそれだけ鍵の管理の手間も大きくなります。 このような状況に対応するための暫定的な仕組みとして、ISC(Internet Systems Consortium) では DNSSEC Lookaside Validation(DLV) という技術を提唱しています。 DLV に対応したリゾルバは、上位のゾーンで提供されるべき DS(Delegation
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対応状況をマップに
dnssec-enable no;でのBINDの挙動についてメモを兼ねて。 DNSSECではRRSIGリソースレコードに ・署名対象の名前 ・署名対象のリソースタイプ・クラス ・署名対象のオリジナルの(コンテンツサーバでの)TTL ・RRSIG自体の有効期間、鍵のハッシュなど を載せ、電子署名で保護している。 RRレコードと、対応するRRSIGレコードを受け取る事ができ、対応する公開鍵を信頼しているならば、 「現在時刻と照らしあわせてRRSIGレコードが有効期間内である事」を確認し、さらに、「Aレコードの元々のTTLがRRSIGの主張するオリジナルTTLだったと仮定して、現在時刻と照らしあわせて署名に矛盾がない」ことを確認することで、改竄されていないことが証明できる。 (公開鍵はルートから権威の木構造で証明するが署名原理は同じなので割愛。NSECも割愛) キャッシュサーバから受け取るRRS
Copyright © 2015 Kyushu Telecommunication Network Co., Inc. All rights reserved. Copyright © 2015 Kyushu Telecommunication Network Co., Inc. All rights reserved. Copyright © 2015 Kyushu Telecommunication Network Co., Inc. All rights reserved. Copyright © 2015 Kyushu Telecommunication Network Co., Inc. All rights reserved. Copyright © 2015 Kyushu Telecommunication Network Co., Inc. All rights reser
JAPAN REGISTRY SERVICES JAPAN REGISTRY SERVICES Copyright © 2011 株式会社日本レジストリサービス 1 DNSSECチュートリアル 2011年7月 株式会社日本レジストリサービス JAPAN REGISTRY SERVICES JAPAN REGISTRY SERVICES Copyright © 2011 株式会社日本レジストリサービス 2 目次 • DNSキャッシュへの毒入れ とDNSSEC • DNSSECのしくみ • DNSSEC導入に向けて • DNSSECの鍵と信頼の連 鎖 • DNSSECのリソースレコー ド(RR) • 鍵更新と再署名 • BINDキャッシュサーバーで のDNSSECの設定 • 鍵生成と署名作業 • BIND権威サーバーでの DNSSECの設定 • スマート署名 (Smart signing) •
tech_team 2018年5月30日 インターネットの技術 パブリックコメントの結果報告 2016年から作業が進められていたルートゾーンKSKロールオーバーは、2017年9月に一時中断となりました。その後、再開に向けた計画案が2018年2月に発表され、それに対するパブリックコメントの募集が2018年4月まで行われました。 Plan to Restart the Root Key Signing Key (KSK) Rollover Process https://www.icann.org/public-comments/ksk-rollover-restart-2018-02-01-en その結果のレポートが、下記のURLで公開されています。主なコメント内容としては、計画案に対して賛成しているもの、計画の修正を求めるもの、もっと積極的なアウトリーチ活動を求めるものなどがあり、さまざま
Matt joined ICANN staff in May, 2016, as VP of Research in the Office of the CTO. Prior to joining ICANN, he was CTO at Dyn, Inc., and spent 13 years at Verisign, finishing his time there as VP of Research and Director of Verisign Labs. He lives in Maryland and works in ICANN's Washington, D.C. office. The ICANN org is today announcing that it will not roll the root zone KSK in the first quarter o
これまでもみなさまに何度かお知らせしているように、 DNSのルートゾーンを管理するICANNが、 ルートゾーンKSKロールオーバー(鍵署名鍵の更新)を現在実施中です。 工程のうち、 2017年7月11日のKSK-2017の公開および9月19日のZSK(ゾーン署名鍵)の更新は、 無事に完了いたしました。 事前に懸念されていたような、 DNSKEY応答サイズの増加に伴うIPフラグメンテーションによる影響などは、 これまでのところ大きな問題とはなっておりません。 多くの方々にご協力いただいた結果です。 ありがとうございました。 しかしながらICANNは、その後(2017年9月27日)に予定の延期を発表しました。 延期されたのは、 10月11日に予定される現在の鍵(KSK-2010)での署名停止と新しい鍵(KSK-2017)による署名開始です。 その理由としては、 DNSSECのトラストアンカーに
ICANNが、ルートゾーンに含まれる鍵(KSK/Key Signing Key)更新の予定を先送りすることを発表しました。 当初、2017年10月11日に鍵の署名が開始される予定でしたが、調査の結果、非常に多くのISPやネットワークオペレータの準備ができていないことがわかり、ロールオーバーの延期が決定したようです。 ICANN: KSK Rollover Postponed いまのところ、いつにKSKロールオーバーが開始されるのかは未定ですが、2018年第一四半期にできれば嬉しいと考えているようです。 KSKロールオーバーに関する参考リンク JPNICの解説 鈴木常彦先生の資料: DNSSECの仕組みとKSKロールオーバへの対応(PDF)
DNSのオンラインチェックツール集をメモする記事.色々ありますが,個人的に便利だと思ったものをリストアップしてます.見つけ次第更新. DNSSECを確認できるサイト http://dnsviz.net/ 図で視覚的に見せてくれて,どこまでが信頼できるかをわかりやすく見せてくれます. https://www.zonemaster.fr/ DNS Delegationをトレースして見せてくれるサイト http://dns.squish.net/ 個人的に好きなサイト.全て辿ってくれるのでわかりやすい. http://simpledns.com/lookup-dg.aspx dns.squishに比べてシンプルにテキストで表示してくれます. ちなみにローカルで動作するものも公開されてます.https://github.com/squish/dnstraverse # gem install dn
The Internet Corporation for Assigned Names and Numbers ("ICANN") today announced that the plan to change the cryptographic key that helps protect the Domain Name System (DNS) is being postponed. Changing the key involves generating a new cryptographic key pair and distributing the new public component to the Domain Name System Security Extensions (DNSSEC)-validating resolvers. Based on the estima
企業ネットワークや学術ネットワークなどでキャッシュDNSサーバーを運用しており、DNSSECを有効にしているのなら、KSK(Key Signing Key)という暗号鍵の更新が必要になる。その暗号鍵の更新処理が確実に実行されるように準備しておくことが極めて重要だ。 DNSSECを有効にしていないキャッシュDNSサーバーでは、暗号鍵の更新前後で何も変わらず、DNSのルックアップは問題なくできる。ただ当然ながらDNSSECを有効にしていないので、DNSSECによる保護は受けられない。 どの組織がDNSSECを有効にしているかを外部から判断するのは難しい。日本レジストリサービス(JPRS)によると、日本におけるDNSSECの普及率は12%くらい(「JP DNSサーバー」への名前解決の問い合わせに対する割合)だという。 影響を受けないようにするため注意が必要なのは、どのような企業か。 私が最も懸念
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く