DNS over TLS - Thoughts and Implementation
Discussion on Hacker News. A week or so I discovered that Android P has DNS over TLS support! It piqued my curiousity - could it finally be that DNS encryption goes mainstream? In this post we’ll survey DNS over TLS, implement a client and share some thoughts! Party like it's 1983 TL;DR Sure, with DNS over TLS your DNS queries are encrypted - that’s a major step forward! Nevertheless, the majority
ルート ゾーン KSK の更新に伴う Windows の DNS サーバー上での対策の必要性
こんにちは、Windows プラットフォーム サポートの串田です。 今回は、先日総務省より通達があった DNSSEC を利用する際に使用されているルート ゾーン KSK の更新に伴う Windows の DNS サーバー上での対策の必要性の確認方法についてご紹介いたします。 ICANN は、ルートゾーン KSK と呼ばれる、DNSSEC で使用される暗号化鍵のペアを更新することをアナウンスしました。 ルート DNS サーバーを経由する、DNSSEC を利用したインターネット上の名前解決には、ルートゾーン KSK が利用されるため、適切な対策が求められています。 これを受けて 2017 年 7 月 14 日(金) に、総務省からも対策の必要性が発表されています。 現在、サポート チームではそもそも運用環境にて 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 推進のための余計な方策が組み込まれているために、非常に複雑なものになっている一方で説明すべきことを説明していない
KSKロールオーバーについて - JPNIC
2018年10月17日更新 2016年10月から、 DNSの起点となるルートゾーンに対して重要な更新が行われています。 2017年9月には、 ルートゾーンからの一部のDNS応答のサイズが一時的に増加する変更作業が行われました。 また、2017年10月に予定されていたKSKの切り替え作業は延期となりましたが、 2018年2月1日付で発表された計画案では2018年10月11日に改めて実施されることとなりました。 この更新に対して問題なく対応するためには、DNSサーバ運用者だけではなく、 ネットワーク運用者も事前に調査し、 必要があれば準備しておくことが重要です。 (意図せずDNSSEC検証が有効になっている場合もありますので、 対象外とお考えの方もぜひご一読ください。) 2018年9月16日に開催されたICANN理事会において、KSKロールオーバーの最終的な実施可否について審議が行われ、 予定
DNSSEC はなぜダメなのか
DNS に依存している 腐り沈みゆく船 (DNS) の上に継ぎ足しで新しい船を築くのは愚か DNSSEC は難しすぎる 強度の弱い暗号を用いているため、鍵を定期的に更新しなければいけない (そして失敗) 鍵を証明する情報を定期的に上位組織 (委任元) に預けて署名し直してもらわなくてはいけない (そして失敗) ルートの鍵を証明する情報を定期(?)的に世界の検証サーバたちに配布し直さなくてはいけない (歴史上始めての更新が今年行われつつあり障害発生が危惧されている) 運用事業者の移管の際に事業者間で安全に鍵を受け渡すことが困難 運用事業者の移管の際に一旦署名を外すのは安全性と可用性を下げる DNSSEC 署名対応事業者から非対応事業者への移管で事故も起きている (移管元も移管先も委任元に預けた鍵情報を消さなかったのが原因 / 一部の有志たちが作成したガイドラインがあって移管先が消すことになっ
Internet Week 2015 T5 今日から始めるDNSSECバリデーション - JPNIC
メールマガジン(JPNIC News & Views)登録 パスワードが記載された確認メールが発送されます。 確認メールが届かない場合は、 ご入力いただいたメールアドレスが 誤っていた可能性がありますので、 再度ご登録手続きを行ってください。
DNSSECを破る ("Breaking DNSSEC" 日本語訳)
("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日:
逆引き DNSSEC は何のため? | インターノット崩壊論者の独り言(2012-12-21)
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) 経由では本サイトにアクセスできないよう措置させて頂いております。 逆引き DNSSEC って何がうれしいのでしょう。さっぱりわかりません。最近、APNIC逆引きDNSSECでゾーン検証エラーという事件がありました。DNSSEC の検証を行っているキャッシュサーバの利用者で悲鳴をあげた人はいらっしゃいますか? 何がうれしくて逆引きの検証をして悲鳴をあげているのですかね。 逆引き DNSSEC の検証に失敗するということは、逆引きに失敗するということです。逆引きが既定のドメイン名を指していないとログインを許さないようなサーバを利用している人は締め出されてしまったかもしれませんね。あるいは逆引きで spam 判定しているサーバではすべてのメールが spam 判定されてしまったかもしれません。(否、そんな単
文書とか (OpenSSH, djb, Python, Lisp/Scheme ...)
OpenSSH 関連 djb 関連 Python 関連 / Pygame 関連 Lisp/Scheme 関連 実用もの 資料 どうでもいいもの 著作権について: 翻訳物に関してはもとの著者に著作権があります (翻訳に際して生じた著作権は主張しません)。 新山自身が書いたものに関しては出典を残すかぎりどのように利用していただいてもかまいません。 OpenSSH 関連 お知らせ: OpenBSDプロジェクトは2014年3月から多国語の文書翻訳がなくなり、英語に一本化されています。 OpenSSH 日本語マニュアルページ OpenSSH 各種コマンドの man ページの翻訳です。 PuTTY と OpenSSH の設定 Windows 用の SSH クライアント PuTTY を OpenSSH と相互運用させる手続きを 音声つきで解説したものです。 Theo de Raadt インタビュー (2
キャッシュDNSサーバのDNSSEC対応
今回は、DNSSECの検証機能を有効にしたキャッシュDNSサーバを構築・運用する方法について解説する。 DNSSECにおけるキャッシュDNSサーバの役割 キャッシュDNSサーバは、名前解決を依頼するクライアントと権威DNSサーバの間に立ち、反復検索を行うサーバである。DNSSECにおいて検証を担当するものを「バリデータ（Validator）」と呼び、多くの場合キャッシュDNSサーバがバリデータを担当する。 第2回でも簡単に説明したが、DNSSECの検証を行うためには信頼の連鎖の起点となる情報が必要となる。これを「トラストアンカー（Trust Anchor）」と呼ぶ。バリデータとなるキャッシュDNSサーバは、トラストアンカーを起点に、DNSSECの信頼の連鎖を検証していくことになる。 DNSの階層構造における委任の起点がルートゾーンであることから、一般的にはルートゾーンの公開鍵情報をトラスト
サイト閉鎖のお知らせ | ASCII Books
ASCII Booksのサイトをご利用いただき、ありがとうございます。 2016年12月6日をもちまして、サイトを閉鎖させていただくことになりました。 今までサイトをご利用いただき、ありがとうございました。 アスキー・メディアワークスを引き続き、よろしくお願いいたします。
qmail はオワコン - どさにっき
2011年2月1日(火) ■ ちょっとトイレットペーパー買い占めてくる _ 一般向けの記事も出てるぐらいなんで別にいまさら書く必要もない気がせんでもないが、自分が後で思い出したくなったときのためにメモ。 _ ipv4 がめでたく売り切れました。厳密にはまだ /8 が5個残ってるけど、これは RIR に自動的に分配される分なので、おばちゃんおかわり、と言ってもごめんねーごはんもうないんだわ、となる。 _ 最後のおかわりは、大方の予想どおり APNIC に2ブロック。この APNIC の在庫も年内には枯渇するはず。ほとんど中国が使っちゃうのかなー。 _ 2003年8月の記事。 RIR exhaustion of the unallocated address pool would occur in 2022. 2003年の時点で、RIR の枯渇が2022年の予想。文中では言及されてないけど、
DNS/DNSSEC - moin.qmail.jp
/Bard /DSレコード /DNSKEY /TTL /時刻指定 [Opinion] To DNSSEC or not? By Geoff Huston on 20 Feb 2023 https://blog.apnic.net/2023/02/20/opinion-to-dnssec-or-not/ DNSSEC - Its Too Hard Is No Longer An Excuse 投稿者 NoelB 日時 土曜日, 7月 1. 2023 https://blog.ausics.net/archives/150-DNSSEC-Its-Too-Hard-Is-No-Longer-An-Excuse.html DNSSECに対応しているドメインの種類は？ https://help.onamae.com/answer/15014?btn_id=fromdnsservicepage_tof
最近のDNSSECの動向
2010/10/19 コース：元祖こってり 「元祖こってり」記事はネットエージェント旧ブログ[netagent-blog.jp]に掲載されていた記事であり、現在ネットエージェントに在籍していないライターの記事も含みます。 最近のDNSSECの動向 こんにちは、ネットエージェント株式会社研究開発部、大阪支社の山口です。今回は、DNS のキートピックのひとつである DNSSEC（DNS Security Extension） について紹介したいと思います。 ----- DNS（Domain Name System） とは、ご存じの通り、インターネット上に展開されている階層的な分散型データベースのことで、主にホスト名とIPアドレスの対応付け等に使用されています。現在のインターネットにおいては DNS はもはや必要不可欠なシステムであり、インターネット技術の根幹といっても過言ではありません。しかし
インターネット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から委任をたどりながら順に問い合わせを行い、
JPドメイン名サービスへのDNSSECの導入予定について | JPドメイン名についてのお知らせ | 新着情報一覧 | JPRS
はじめに JPRSでは、DNSのセキュリティ拡張方式であるDNSSEC[*1]を、2011年1月16日にJPドメイン名サービスへ導入する予定で準備を進めています。 この文書では、DNSSEC導入の背景と、今後JPRSが予定しているDNSSEC導入関連の活動について説明します。 *1 DNSSEC: DNS Security Extensions DNSSEC導入の背景 DNSはインターネットの根幹を支える重要な仕組みであり、インターネットが社会基盤として重要性を増す中で、その安定的な運用が求められています。これに加えて、近年、DNS応答の偽造により引き起こされるセキュリティ上の脅威が現実のものとなり、このような脅威を排除し、安心して利用できるDNSであることも強く求められるようになってきました。 DNSに関するセキュリティの向上については、IETF[*2]において検討が進められ、DNSSE
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DNS 温泉 4 教材
http://sim.internot.jp/vitocha/rfc5155_example_memo.txt
What kinds of security vulnerabilities does providing DNSSEC expose?
jpix.jp | DNSViz