Google Chromeは「DNSルートサーバー」に大きな負荷をかけている、その理由とは？
Google ChromeやMicrosoft Edgeのベースであるオープンソースのウェブブラウザ「Chromium」には、アドレスバーと検索バーを一体化させた「Omnibox」という機能が搭載されていますが、そのOmniboxによってDNSのルートサーバーに大きな負荷がかかっていると、ベリサインのCSOであるMatthew Thomas氏が報告しています。 Chromium’s impact on root DNS traffic | APNIC Blog https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/ A Chrome feature is creating enormous load on global root DNS servers | Ars Technica https://ar
DNS改ざん検知ツール(Slack通知付き)で検知速度を爆速にした - Code Day's Night
暑い夏2020、DNSと戯れていました。 レジストラの脆弱性でDNSが改竄されてサイトがハッキングされる事件を見て、これを防ぐ方法がなかったので7月末にDNS改ざん検知ツール NSchecker を作って公開しました。 blog.ichikaway.com 結論 忙しい方のために結論だけ先に。NSchecker Ver0.03ではDNS改竄検知速度が60秒程度に大幅改善しました！（Ver0.01では最大48時間の検知遅延） NScheckerのソースコードはこちら。 github.com 詳細 このツールはDNSのNSレコードが改竄されるとSlackで通知できる(slack以外も可能)ため便利だったのですが、NSレコードの参照がDNSキャッシュサーバだったため検知が最大で48時間ぐらいかかる問題がありました。(NSchecker Ver 0.01) 無いよりはマシなツール程度になってしまっ
2020年6月に発生したドメイン名ハイジャックのインシデント対応について - coincheck tech blog
はじめまして、サイバーセキュリティ推進部の喜屋武です。 今回は2020年6月に発生したお名前.com上の当社アカウント乗っ取りによる「coincheck.com」のドメイン名ハイジャックのインシデントについて、発覚までの経緯とその後のインシデント対応についてご説明します。 1 発覚までの経緯 1.1 サービスの応答時間の遅延の確認 当社利用のドメイン登録サービス「お名前.com」で発生した事象について（最終報告） | コインチェック株式会社 でもタイムラインを記載しましたが、最初の異変は日頃からモニタリングしているサービスのレスポンスタイムが著しく遅延していたことでした。 当時のサービスのレスポンスタイム この異常を確認し、SRE チームが調査に乗り出しましたがこの段階では他に問題は確認されず、レスポンスが遅延している原因の特定には至っていませんでした。 1.2 他部署やユーザーからの問い
DNS における Master/Slave vs Primary/Secondary の現状（2020/06） - suu-g's diary
BLM の関係でコンピュータ業界の Master / Slave という言葉遣いにもメスが入ろうとしているいま、 DNS ではどうなっているんだっけ、というのがふと気になった。 というのも mattn さんの blacklist/whitelist master/slave に関する情報集め を見たから。あとコメントもしたから。 で、調べて行ったところ、ひとことで言えば既に Primary / Secondary になってるんだけど、そもそもこの用語自体そんな使わないよな、と思ったのだけど、そのあたりを解説するのは元記事の関心ごとと全く違うってことで、改めて自分のブログの記事にしてみたというわけ。 DNS は趣味でしかないので、ツッコミ大歓迎です。 Primary/Secondary が正しい用語です 用語に困ったら RFC 8499 (Jan, 2019) が正しい参照先。こう書いてある
NextDNSというサービスは子持ち家庭のインターネットを安心安全にする - kuenishi's blog
tl:dr; 子供にも安全にインターネットさせたいが、なるべく親がコントロールしたい いままで /etc/hosts を工夫して狭い範囲でブラックリスト管理していたが運用が辛かった NextDNS.io というサービスがやりたいことを全部実現していたので課金した 我が家には小学生と幼稚園の男児がいて、どちらもラップトップを持ってネットサーフィンをする。分からないことは自分で調べさせたりScratchでプログラミングさせたりして遊ばせれば、これが結構な時間潰しになる。わたしの古いMacBook Airを使わせたりしていたが、予算に余裕が出たタイミングで上の子にはMacBook Proを買い与えた。いちどそのMacにMinecraftをインストールしてやったらすぐに廃人になったので、さすがにそれはアンインストールして禁止した。おおよそ自由にネットサーフィンはさせているのだが、インターネット上で
新進気鋭のDNSサービス「NextDNS」を使うと何ができるのか？
「gigazine.net」といったドメイン名をコンピューターが処理できるIPアドレスに変換するDNSは、インターネットを支える重要な技術です。そんなDNSサービスのひとつである「NextDNS」の機能について、クラウドサービスのエンジニアであるStanislas Lange氏が説明しています。 NextDNS is my new favourite DNS service https://angristan.xyz/2020/04/nextdns/ Lange氏はDNSサービスとして、広告をネットワークレベルでブロックできる「Pi-hole」や、Cloudflareが提供する「1.1.1.1」、「AdGuard DNS」などの利用を検討しましたが、通信の遅延や信頼性において、いずれもLange氏の要求水準を満たさなかったとのこと。 そんな中Lange氏が出会ったのが「NextDNS」でし
ついにFirefoxがDNSとの通信を暗号化する「DNS over HTTPS」をデフォルトで有効にすると発表
ウェブブラウザのFirefoxを開発するMozillaは、以前からブラウザによるDomain Name System(DNS)との通信を暗号化してプライバシーを強化する「DNS over HTTPS(DoH)」を実装する計画を進めてきました。2020年2月25日、Mozillaは今後数週間で、アメリカ国内のFirefoxユーザーに対してDoHをデフォルトで有効にすると発表しました。 Firefox continues push to bring DNS over HTTPS by default for US users - The Mozilla Blog https://blog.mozilla.org/blog/2020/02/25/firefox-continues-push-to-bring-dns-over-https-by-default-for-us-users/ Fire
CNAME トラッキングについての議論
先日割と感情的に呟いたものがそこそこ拡散されてしまって、「良くないものだ」という気持ちだけが広まってしまうのは本意ではないので、改めてきちんとした議論をしたいという思いでこの記事を書きます。 前提となる立場 トラッキングをすること自体の是非は問わない トラッキングの手法についての議論である ユーザーがトラッキングを望まない場合、積極的な対処をせずとも有効な選択肢が与えられる状態が望ましい CNAME トラッキングの方法・背景 アドエビスによる解説がわかりやすいです。最近の Third-party Cookie に対する制限の回避策となり得ます。 セキュリティの懸念事項 不適切な設定をされた Cookie が、トラッキングサービスに送信されてしまう Set-Cookie ヘッダに Domain ディレクティブを指定した場合、すべてのサブドメインに Cookie が送信されてしまいます。もし認
以前やった社内向けDNS勉強会の資料を公開してみた | DevelopersIO
ども、ゲストブロガーの大瀧です。 クラスメソッド在籍中の2018年2月頃社内向けにDNS勉強会を全4回で開催したことがあり、そのときの資料がひょこっと見つかったので公開してみます。(正確には第3回は聖剛さん担当だったので一緒に公開してもらいました、感謝。) 第1回 DNS入門 : DNSのしくみ、キャッシュ 第2回 DNSコンテンツサーバー : DNSサーバーの分散構成とゾーンの委任 第3回 DNSセキュリティ : DNS関連の攻撃手法とDNSSEC 第4回 AWSのDNSサービス : Route 53とAmazon DNS DNSについての理解を深める一助にしていただければと思います。現職(SORACOM)でももちろん超重要な技術です！ 第1回 DNS入門 スライド共有サービス終了に伴い、公開終了 第2回 DNSコンテンツサーバー スライド共有サービス終了に伴い、公開終了 第3回 DNS
[初心者向け]Webサービスを利用する際のDNSからTCPコネクションについて再入門 | DevelopersIO
もう少しSOAレコードについて触れます。 形式として、下記のようになっており、 [認証局ドメイン] [ゾーン管理者のドメイン] [ゾーンのシリアル番号] [更新時間] [再試行時間] [期限が切れる時間] [負の結果をキャッシュする TTL] ゾーンの管理を行うDNSサーバのFQDN（ホスト名まで含むドメイン名）や、管理者に連絡が取れるメールアドレス、ゾーン情報の新旧を判別するためのシリアルナンバー（改訂する度に増加する）が順に記載されています。 続く3つの情報は、セカンダリネームサーバがプライマリのネームサーバから入手したゾーン情報を、どう扱うかを指定するものです。各データはそれぞれ秒数で指定されています。 digコマンドで弊社クラスメソッドのSOAレコードを確認してみましょう。ANSWER SECTIONに上記形式で内容が記載されています。 # SOAレコード $ dig soa cl
![[初心者向け]Webサービスを利用する際のDNSからTCPコネクションについて再入門 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/1a571ac8238b9005bf9f6a214ab2b1492a06c8e0/height=288;version=1;width=512/https%3A%2F%2Fcdn-ssl-devio-img.classmethod.jp%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_developers.io_1200x630.jpeg)
Microsoft Azure、DNSの設定変更に失敗して全世界的にサービス障害。日本は十連休中だったのが不幸中の幸いか
Microsoft Azure、DNSの設定変更に失敗して全世界的にサービス障害。日本は十連休中だったのが不幸中の幸いか Microsoft Azureは、2019年5月2日午後7時43分から午後10時35分まで（日本時間 2019年5月3日午前4時43分から午前7時35分まで）の約3時間、DNSの名前解決に問題が発生。 ほぼ全世界的に、Microsoft AzureをはじめOffice 365/Microsoft 365やMicrosoft Dynamicsなど同社サービスに対する接続ができなくなるという大規模な障害を起こしました。 この大規模障害の原因は、同社サービス用のDNSのメンテナンス作業のミスが原因だったと発表されました（中間報告の段階では既存のDNSからAzure DNSへのマイグレーション作業に失敗したと報告されていました。現在の報告では計画メンテナンス作業での失敗だとされ
EC2上でDNS RebindingによるSSRF攻撃可能性を検証した
AWS EC2環境でのDNS Rebindingについて検証したので紹介します。 まずは、「前回までのおさらい」です。先日以下の記事でSSRF攻撃およびSSRF脆弱性について紹介しました。 SSRF(Server Side Request Forgery)徹底入門 この記事の中で、以下のように紹介しました。 ホスト名からIPアドレスを求める際にも以下の問題が発生します。 DNSサーバーが複数のIPアドレスを返す場合の処理の漏れ IPアドレスの表記の多様性（参考記事） IPアドレスチェックとHTTPリクエストのタイミングの差を悪用した攻撃（TOCTOU脆弱性） リクエスト先のWebサーバーが、攻撃対象サーバーにリダイレクトする 上記のTOCTOU(Time of check to time of use)問題は、DNSの名前解決の文脈ではDNS Rebindingとも呼ばれます。 DNS R
Fake SNIという提案仕様について - ASnoKaze blog
SNIを用いた通信のブロッキング及び、「Encrypted SNI拡張」のブロッキングについてはIETFのTLS WGでも話題となりました（(TLS) SK filtering on SNI, blocking ESNI）。 Encrypted SNIはSNIを暗号化する一方で、ClientHelloにencrypted_server_name拡張をつけます。そのため、経路上の観測者はEncrypted SNIが使われていることを検知できます。 それを回避するために、ニセのSNIをつける「Fake Server Name Indication」というdraftが提出されています。 初版のdraftであり、これから議論のあるところだとは思うが、とりあえず面白そうなので読んでみる。 Fake SNI Fake SNIを利用するサービスは事前に、偽のホスト名を公表します。DNSを利用することを想
DNS over HTTPSの必要性について - Qiita
なぜ今までのDNSでは問題があるのか インターネット上の通信の多くは、ブラウザを利用したウェブによるものです。 セキュリティ向上のため、GoogleやFireFoxといった大手ブラウザベンダーが平文通信であるHTTPから暗号通信であるHTTPSへの移行を推奨し、盗聴・改竄・なりすましといった問題を解決することが出来ます。 しかしながら、そのHTTPS通信をする前のDNSによるドメイン解決は暗号化されておらず盗聴でアクセスするホスト名を把握される、なりすましで偽の応答を返されるといった可能性があります。 それを防ぐための方法の1つが、DNS over HTTPSです。 DNS over HTTPSとは 今までDNSサーバ（フルリゾルバ）の（主に）UDPポート53番に対して行われていたDNSによる名前解決を、TCPポート443番に対するHTTPS(HTTP/2 over TLS)通信上で行うプ
Ubuntu 18.04でDNSサーバーを変更する方法 - 動かざることバグの如し
めっちゃハマった 環境 Ubuntu 17.04以降 ネームサーバーを変更できない問題 DNSの変更は/etc/resolv.conf、という時代は古い。Ubuntu 17.04以降ではsystemd-resolvedがデフォルトで動作しているため、/etc/resolv.confを書き換えても変更されない そもそも/etc/resolv.confは/run/resolvconf/resolv.confのシンボリックリンクになっている（） $ ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 29 1月 15 11:13 /etc/resolv.conf -> ../run/resolvconf/resolv.conf UbuntuでDNSサーバーを変更する方法 systemd-resolve --statusを実行すると現在の設定されているDNS
ubuntuでapt-getが名前解決できなかった - きゅうり。
しばらく何も書いてなかったの、たまにはCTF関係ないことも書きます。 カテゴリー的には、「技術的に苦戦したことの覚書」 内容的に多くなったので、2つの記事にわけて書きます。 その１の内容は、「ubuntuでapt-getしようとしても名前解決できない」です。 http[:]//archive[.]ubuntu[.]com/ が一時的に解決できません 的な文言が出てきます。 404で見つかってない場合は old-releases にすればいいのですが、今回は明らかにDNS面で問題が起きているので探っていきます。 まずはDNSの指定がきちんとなされているかを調べます。 /etc/resolve.conf に直書きでもいいのですが、このファイルは動的に変わるよ、的なことを言われます。 ubuntu 12.04 以降は、/etc/network/interfaces にて、 dns-servers
DNS over HTTPSサーバを見つけるためのTXTレコードの提案仕様 - ASnoKaze blog
20190821 追記 この提案は廃案されました https://mailarchive.ietf.org/arch/msg/doh/qkmhh93Id6XIngH3LJwp-HokH_Y DNS over HTTPS(DoH)の標準化が進められており、引き続き注目を集めている。 asnokaze.hatenablog.com 一方で、DoHサーバをどのように見つけるか、見に行かせるかの議論が始まっています。 JPNIC Blog :: DNS over HTTPSとDHCP －IETF102における議論－ で紹介されている通り、先月行われたIETF102でもDNSリゾルバの識別子と利用についてのBoFがありました。 例えば、設定ファイルだったり、DHCPでDNSサーバを設定する際にDoHサーバを設定する際にどうすればいいか、どのようディスカバリさせるかといった議論です。 その流れで、Do
セキュリティアナリストのつぶやき
2022.03.09 Azure AD導入環境に対するペネトレーションテストの資格「Certified Az Red Te...
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google、「Chrome 78」で“DNS-over-HTTPS”を実験／DNSへの問い合わせをセキュアでプライバシーが保たれるHTTPS接続で
もし、ドメイン名が他人にハイジャックされたら？ 平成の記憶から学ぶ、その手口と対策【Internet Week 2018】 - INTERNET Watch
