「アプリケーションエンジニアが知るべきDNSの基本」というタイトルで、builderscon tokyo 2018 で登壇するスライドです
![Basics_of_DNS_that_application_engineers_should_know - Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/31ef9f7c53124c11996287b581d11b8efe5024e9/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Ff53838df4f8b49efb9dc1970ae6b4695%2Fslide_0.jpg%3F10716851)
この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ICANN(Internet Corporation for Assigned Names and Numbers)が、DNS(ドメインネームシステム)において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵(ルートゾーンKSK)の更改を実施します。 総務省では、ICANNからの依頼を受けて、内閣サイバーセキュリティセンターの協力の下、国内関係者への周知を実施しております。 この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ICANN(Internet Corporation for Assigned Names and Numbers)が、DNS(ドメインネームシステム)において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵(ルートゾーンKSK)の更改を実施します。 これに伴い
Cloudflare is now well into its 6th year and providing authoritative DNS has been a core part of infrastructure from the start. We’ve since grown to be the largest and one of the fastest managed DNS services on the Internet, hosting DNS for nearly 100,000 of the Alexa top 1M sites and over 6 million other web properties – or DNS zones. CC-BY 2.0 image by Steve Jurvetson Today Cloudflare’s DNS serv
2020/04/28 追記 仕様の名前が少々変わりましたが、WG Draftとなり作業は引き続き続けられています。 「Specification of DNS over Dedicated QUIC Connections」 QUICの標準化とアプリケーションレイヤ IETFでQUICの標準化が活発に行われており、トランスポート・TLS・HTTP各レイヤのドラフト仕様の改定が進められております。 標準化を行うにあたって当初より、DNSのトランスポートとしてQUICを使用したいという話題は出ていましたが、QUICワーキンググループのチャーターでは、まずはQUICのアプリケーションレイヤとしてHTTPの標準化を行ってから他のアプリケーションプロトコルについて進める旨書かれている。 とはいえDNS over QUICをやりたい人はいるようで、4/11にインターネットドラフトが出されている。共著者
c-ares については過去の記事で少し触れた。c-ares は以下に詳細な API リファレンスが存在するが、Web サイトトップより詳しく、API リファレンスよりも大雑把な機能紹介がないのがもったいない。 というわけで、c-ares を簡単に紹介しておく。まずは Web サイトトップに書いてあること。 非同期名前解決ができる 大抵のプラットフォームで呼び出すことができる gethostbyname、getaddrinfo は同期呼び出しのみ C ライブラリとして提供される IPv6 に対応している 様々なプラットフォームに対応していて移植性に優れている Windows Mac OS X Linux Android etc.. 今も活発に開発が行われている メーリングリストが活発 メインメンテナの Daniel Stenberg 氏が活発 ソースコードを見たり実際にコードを書いたり実行
--------------------------------------------------------------------- ■(緊急)BIND 9.xの脆弱性(DNSサービスの停止)について(CVE-2016-2776) - フルリゾルバー(キャッシュDNSサーバー)/権威DNSサーバーの双方が対象、 バージョンアップを強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2016/09/28(Wed) 最終更新 2016/10/03(Mon) (PoCが公開され、危険性が高まっている旨を追加) --------------------------------------------------------------------- ▼概要 BIND 9.xにおける実装上の不具合により、namedに対する外部からのサービ ス不能(DoS)攻撃が可能となる脆弱性
【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
Google Webmaster Central Blogで、AkamaiがGoogle Public DNSに対応したことが公表されています。この対応が行われるまでは、Google Public DNSを利用することによって、大手Webサイトの表示やiOSのダウンロード速度が低下しがちだったのが、これによって改善するかも知れません。 Google Public DNS and Location-Sensitive DNS Responses Google Public DNSがサービスを開始したのは2009年です。スノーデン事件の影響で利用者数が減った地域もあったという調査結果も2013年にあったものの(参考)、Google Public DNSユーザが世界中で非常に多いようです。たとえば、先月公開されたAPNICのブログでは、全世界で約10%のユーザがGoogle Public DNS
--------------------------------------------------------------------- ■(緊急)複数のDNSソフトウェアにおける脆弱性(システム資源の過度な消費) について(2014年12月9日公開) - BIND 9では権威DNSサーバーにも限定的に影響、バージョンアップを強く推奨 - 株式会社日本レジストリサービス(JPRS) 初版作成 2014/12/09(Tue) 最終更新 2014/12/25(Thu) (米国The CERT Divisionの注意喚起・Vendor Informationへのリンクを追加) --------------------------------------------------------------------- ▼概要 BIND 9・Unbound・PowerDNS Recursorを含む複
DNS Reverse Lookup Shellshock Posted Oct 13, 2014 Authored by Dirk-Willem van Gulik, Stephane Chazelas DNS reverse lookups can be used as a vector of attack for the bash shellshock vulnerability. tags | exploit, bash advisories | CVE-2014-3671, CVE-2014-6271, CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187 SHA-256 | f270585f9a138adfc590970e5d69e843b483a83fdff3980b13aa5bef
2014年4月15日に公開されたJPRSの緊急注意喚起に続き、中京大学の鈴木常彦教授によるDNSキャッシュポイズニングに関する技術情報が公開されました。 今回公開された技術情報に書かれている内容には、DNSの本質につながるさまざまな要素が関係しており一回で書ききれるものではなく、また、書いている側(私)も、それぞれの要素技術について勉強しながら理解しつつ進めていかないと混乱してしまうということが良くわかったため、これから数回に分けて徐々に書いて行くことにしました。 ということで、今回はまず、そもそもDNSキャッシュポイズニングとは何かということと、JPRSの注意喚起に書かれているUDPソースポート番号のランダム化(ソースポートランダマイゼーション)の概要、そしてなぜそれが重要なのかという点について解説します。 DNSキャッシュポイズニングとは インターネットで通信を行うとき、各機器同士は通
本日、JPRSが緊急の注意喚起を公表しました。 緊急)キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について(2014年4月15日公開)- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 本日、JPRS がようやく重い腰をあげて注意喚起を発してくれましたが、その内容は危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません。 一方で注意深い攻撃者が探せば、ネット上にはすでに深刻な攻撃を行うのに必要な情報は十分に流れています。特に、JPRS が3月に慌てて co.jp などにこっそり入れた署名付き TXT レコードは大きなヒントに見えます。 DNS に詳しい攻撃者であれば、攻撃手法に辿りつくのは時間の問題でしょう。(すでに攻撃は行われているかも知れません) 長く秘密にしておくことは得策ではないと判断し、防御する側の心構えと手助けにし
--------------------------------------------------------------------- ■(緊急)キャッシュポイズニング攻撃の危険性増加に伴う DNSサーバーの設定再確認について(2014年4月15日公開) ~問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨~ 株式会社日本レジストリサービス(JPRS) 初版作成 2014/04/15(Tue) 最終更新 2014/05/30(Fri) (対策に関するDNS運用者向け文書へのリンクを追加) --------------------------------------------------------------------- ▼最近の状況 最近、日本の大手ISPにおいてカミンスキー型攻撃手法によるものと考えら れるキャッシュDNSサーバーへのアクセスが増加している旨、JP
Google Public DNS を使用するようにネットワーク設定を構成する Google Public DNS を使用する場合、DNS の「スイッチボード」オペレーターが ISP から Google Public DNS に変更されます。 ほとんどの場合、動的ホスト構成プロトコル(DHCP)は、ISP のドメイン名サーバーの IP アドレスを使用するようにシステムを自動的に構成します。Google Public DNS を使用するには、Google Public DNS の IP アドレスを使用するように、オペレーティング システムまたはデバイスの DNS 設定を明示的に変更する必要があります。DNS 設定を変更する手順は、オペレーティング システムとバージョン(Windows、Mac、Linux、ChromeOS)、デバイス(パソコン、スマートフォン、ルーター)によって異なります。こ
DNS Summer Days 2013 開催趣旨 インターネットの基盤技術の一つであるDNSは、ますます高まっている重要性に も関わらず、その運用には十分な関心が払われておらず、また必要なリソースに も恵まれているとはとても言えない状況にあります。また、プロトコルそのもの やRFC等の技術文書のわかりにくさや、実装による違いが大きいことも相まっ て、DNSをきちんと理解し運用している技術者の数も少ないのが現状です。 このようなDNSの状況に鑑みて、今年も昨年に引き続いてDNSのイベントを開催す ることにいたしました。 今年は、1日目をワークショップとして、DNSに関わる様々なトピックや、現在進 行中の問題、さらには今後についての話題を深く議論できることを期待しています。 2日目は、チュートリアルとして、昨年のチュートリアルを参考にしつつ基本的 な知識を復習した上で、DNSに関する土台固め
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く