ISUCON13のベンチマーカーのDNS水責め攻撃について - Hateburo: kazeburo hatenablog
この記事はさくらインターネット Advent Calendar 2023の12月3日の記事になります。 先日行われました ISUCON13 の作問を担当しました。参加者の皆様、スタッフの皆様ありがとうございました。 このエントリではISUCON13のDNSに関わる要素とベンチマーカーから行われたDNS水責めについて紹介します。 ISUCON13の問題の講評と解説は以下のエントリーでも行っていますので読んでいただけると嬉しいです isucon.net こんいす〜 ISUCON13における名前解決 上記のエントリーにもある通り、今回のISUCONではDNSが問題の一部として出てきます。 これまでポータルから参加者は割り振られたサーバの中から負荷をかけるサーバ1台選択し、ポータルはそのサーバに対して負荷走行を行うことが多くありましたが、今回はサーバ1台を選択したら、ベンチマーカーはそのサーバの
日本からipv4only.arpaへの名前解決が大量に送られてるっぽい - momokaのブログ
一番下に追記あり。 ipv4only.arpa への名前解決 Cloudflareの1.1.1.1を使ったドメインランキングを眺めていたら人気でないはずのドメインが日本国内ランキングで上位に。 ipv4only.arpaへの名前解決が大量に。 https://radar.cloudflare.com/domains/domain/ipv4only.arpa https://radar.cloudflare.com/domains/jp 51位にあった amazon.co.jp より高い位置に。 確実にネットワーク機器か何かソフトウェアが行っているDNS。（ランキング上位はそのようなものがどっちみち多いが） でも日本だけ多いのがとても不思議。 ipv4only arpaの名前解決をそんなに大量にするってどんな状況だろうか？ ipv4only arpaのAAAAクエリの名前解決はDNS64 (
DNSの不正使用手法をまとめた技術ドキュメントの公開 - JPCERT/CC Eyes
はじめに Domain Name System（DNS）はインターネットサービスを使用する上で欠かせない基幹サービスであり、DNSが関連するセキュリティインシデントへの対処は、健全なインターネットを維持するために重要です。本ブログでは、JPCERT/CCもメンバーとして参加しているFIRSTのDNS Abuse SIGが、2023年2月に公開したDNS Abuse Techniques Matrixについて、その日本語版をJPCERT/CCが主体となり作成および公開したので紹介します。 2023年2月、FIRSTのDNS Abuse SIGが公開したDNS Abuse Techniques Matrix - DNS Abuse Techniques Matrix https://www.first.org/global/sigs/dns/DNS-Abuse-Techniques-Matri
Dangerous Labels in DNS and E-mail
Workgroup: intarea Internet-Draft: draft-dkg-intarea-dangerous-labels-01 Published: 21 May 2022 Intended Status: Informational Expires: 22 November 2022 Author: Dangerous Labels in DNS and E-mail Abstract This document establishes registries that list known security-sensitive labels in the DNS and in e-mail contexts.¶ It provides references and brief explanations about the risks associated with ea
DNSリバインディング(DNS Rebinding)対策総まとめ
サマリ DNSリバインディングが最近注目されている。Google Chromeは最近になってローカルネットワークへのアクセス制限機能を追加しており、その目的の一つがDNSリバインディング対策になっている。Googleが提供するWiFiルータGoogle Nest WiFiはデフォルトでDNSリバインディング対策機能が有効になっている。 DNSリバインディング対策は、攻撃対象アプリケーションで行うべきものであるが、ブラウザ、PROXYサーバー、リゾルバ等でも保護機能が組み込まれている。本稿ではそれら対策機能の状況と対策の考え方について説明する。 DNSリバインディング（DNS Rebinding）とは DNSリバインディングはDNS問い合わせの時間差を利用した攻撃です。DNSのTTL（キャッシュ有効期間）を極めて短くした上で、1回目と2回目の問い合わせ結果を変えることにより、IPアドレスのチ
Herokuから ECSに 移行した - pixiv inside
こんにちは、インフラ部の id:sue445 です。私事ですが先日GCPの Professional Cloud Architect を取得しました。 そういうわけで今日はGCPではなくAWSの話をします。 tl;dr; 劇的ビフォーアフター 構成 移行のモチベーション パフォーマンス向上 コスト圧縮 アーキテクチャの採択理由 やったこと 1. DB作成 2. MySQL 5.7 -> 8.0 MySQL 8.0でハマったこと MySQL 8.0からデフォルトの認証がcaching_sha2_passwordになった RDSのMySQL 8.0からMariaDB 監査プラグインがなくなった 3. 本番用のDockerイメージを作成 困ったこと：CodeIgniterがログの標準出力に対応していなかった 4. ECS + Fargate + CodePipeline構築 5. CDN作成 6
リモートワーク文脈で超低コスト擬似DNSを社内で提供しました。 - エニグモ開発者ブログ
こんにちは、インフラチームの加藤です。 この記事は Enigmo Advent Calendar 2020の23日目の記事となります。 本記事では、リモートワーク環境のため、擬似DNSを社内提供したお話をします。 エニグモでは、今年の2月頃から全社的にリモートワークを開始しました。 それに伴いインフラチームでは、リモートワークのネットワーク周りの対応を行いました。 エニグモが運用しているサーバ群 エニグモの運用するサーバは、データセンター内に構築したものとAWSのものがあります。 情シスの足立さんが、SaaS導入を進めて下さったためオフィス内にサーバはほぼありません。 サーバへの疎通経路 オフィス・リモート環境共にVPN経由(+ファイアウォール)で、サーバ群へアクセス可能です。 リモートワーク開始後のサーバアクセスの問題 リモートワーク開始直後から、ネットワーク設定に関するお問い合わせと、
[速報] 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)
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がよくわかる教科書」DNSの入門にとてもおすすめの一冊 | DevelopersIO
大阪オフィスのYui(@MayForBlue)です。 DNSを一から勉強するために読んだ「DNSがよくわかる教科書」が入門にとても良かったのでご紹介します。 この記事の目次 本の概要 「DNSがよくわかる教科書」書評 最後に 本のリンク さらにDNSを知りたい方におすすめの記事 本の概要 DNSとは何かというところから管理・運用、セキュリティまでDNSを知る上で必要な基礎知識が網羅されていて初心者にもわかりやすく書かれています。 また、各章が基礎編(第1章〜第4章)、実践編(第5章〜第10章)、アドバンス編(第11章〜第14章)と大きく３つのテーマに分かれているので、読む人のレベル感によって読み方、進め方を変えられるのもおすすめのポイントです。 実際に運用する上で考慮すべき点や設定、トラブル対応についても解説されていて、最初に読むのにとても良い本だと思いました。 著者 株式会社日本レジスト
以前やった社内向け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
東京リージョンでVPC Lambdaの高速起動が確認できたので改善効果を計測してみた | DevelopersIO
2019/9/16時点でAWSからはVPC Lambdaの改善適用完了のアナウンスはありません。 「なんか新アーキテクチャで起動してるっぽいから試しに測ってみるかー...」という程度のノリでの計測なので、アーキテクチャの段階移行の過程における一時的な計測結果として参考にするに留めて下さい。 実際にAWSから移行完了がアナウンスされる際は、今回の計測結果のような動作にならない可能性が高いことに留意して下さい CX事業本部＠大阪の岩田です。 先日公式にアナウンスされたVPC Lambdaのコールドスタート改善、数ヶ月かけて徐々に適用とのことでしたが、先ほど東京リージョンで新アーキテクチャでのVPC Lambda起動が確認できました。 【速報】もうアンチパターンとは呼ばせない！！VPC Lambdaのコールドスタート改善が正式アナウンスされました！！ VPC Lambdaのコールドスタートがどの
IIJ Public DNSサービス
サービス内容 IIJ Public DNSサービス（以下、本サービス）はDNS over TLS（DoT/RFC7858）、DNS over HTTPS（DoH/RFC8484）を利用した名前解決サービスです。 DoT、DoHは、従来用いられているDNSに変わる名前解決のためのプロトコルとして開発が進められています。 IIJでは、DoT、DoHによる名前解決の実用性の確認、また、DoT、DoHに対応したDNSサーバの運用ノウハウの獲得のため、試験的にDoT、DoH対応の名前解決サービスを提供いたします。本サービスはpublic DNSとして、IIJをご契約の方以外でもご利用いただくことができます。 DoT、DoHにご興味があり、本ページでご案内の条項に同意いただける方は、ご利用中のパソコン・スマートフォンに設定を行うことで、本サービスを利用した名前解決を行うことができます。 DoT、DoH
hatena.ne.jp ドメインのゾーンを AWS Route 53 に引っ越した話 - Hatena Developer Blog
こんにちわ、株式会社はてなのシステムプラットフォーム部で SRE をやっている id:nabeop です。この記事ははてなエンジニア Advent Calendar 2018 の14日目の記事です。昨日は id:Pasta-K でした。 今日は hatena.ne.jp ドメインのゾーンを AWS Route 53 に移設するにあたって、AWS 初心者がどんなことを考えながら移設したかという話です。DNS ゾーンの移設の手順などについては既に様々な情報があるので、そちらを参照してください。 そもそもの始まり 僕は2018年3月に はてな に中途入社しました。入社して1ヶ月くらいたった4月のある日、「ねぇ、hatena.ne.jp というゾーンを AWS Route 53 に移設してみない?」とタスクが降ってきました。時期としては中途入社後、業務のキャッチアップをしつつ、今まで触ったことがな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DNS水責め攻撃と監視 / DNS water torture attack Monitoring and SLO
DNS水責め攻撃、食らっちゃいました
TechCrunch
名前解決の仕組みを使ってDNSを攻撃、「NXNSAttack」とは 
IIJ、世界100拠点以上のDNSサーバーを利用できる「IIJ DNSプラットフォームサービス」開始 
「BIND 9」にリモートから悪用可能な複数の脆弱性 
