dig の全てのコマンドラインオプションを一覧にしたシートを作成しました - Qiita
概要 筆者は DNS Summer Day 2023 で「あたらしい dig」というテーマで発表を行いました(資料はこちら)。 DNS のテストツールである dig コマンドは、ネットワークエンジニアのみなさんが日常的に利用していると思います。 一方で、dig を用いているとたまに想定とは異なる結果が得られ、戸惑うことがあります。 原因としては、dig の送信するリクエストメッセージに関するデフォルト値が一般的な感覚と異なるために起きることが多いようです。 発表ではこれらの具体的な例を挙げつつ、もし dig のいくつかのコマンドラインオプションの存在やそのデフォルト値の知識があったならば、それらはすぐに解決したであろうことを示しました。 dig には非常に多くのコマンドラインオプションがあります。しかし、man ページや -h オプションで表示される簡易ヘルプではコマンドラインオプションが
不要な DNS リソースレコードは消そう / Delete unused DNS records
https://yuru-sre.connpass.com/event/317749/ の LT 資料です
DKIM ADSP は廃止されています (HISTORIC です) | IIJ Engineers Blog
IIJ ネットワーク本部アプリケーションサービス部・(兼)社長室所属。 メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。 結論 https://www.rfc-editor.org/rfc/rfc5617.html (HISTORIC) (※1) 新しくドメイン名を登録された方へ DKIM ADSP レコードは、もはや書く必要はありません。 誰も見ていませんし、評価の対象になっていないと考えて差し支えありません。 すでにドメイン名を運用されている方へ DKIM ADSP レコードが書いてあるかは、次のように調べられます。 $ dig _adsp._domainkey.example.jp
Amazon Route 53をやさしくおさらい
Amazon Route 53をやさしくおさらいする会 https://minorun365.connpass.com/event/294692/
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
DNS権威サーバのクラウドサービス向けに行われた攻撃および対策 / DNS Pseudo-Random Subdomain Attack and mitigations
JANOG51発表資料 https://www.janog.gr.jp/meeting/janog51/dns/ 2017年のJANOG39にて弊社から「DNS権威サーバ向けのDDoS攻撃対策をした話～さくらインターネット編～」というプログラムを行い、実際に発生した障害やその後の取り組みを共有し、DNS権威サーバ向けのDDoS対策について議論いたしました。 それから5年経ちクラウドファースト、クラウドバイデフォルトなどと言われるようにクラウドサービス前提にシステムの構築運用がなされるようになり、DNSにおいても例外なくクラウドサービスが使われ、その重要度がますます高まっております。 その中で2022年にさくらのクラウドのDNS権威サーバサービスにDNS水責め攻撃が発生し、L7ファイアウォールの導入、dnsdistなどサーバ上のミドルウェアで攻撃を緩和する対策、またメトリクス取得の強化を行い
2022年11月30日のAdGuard DNS部分的ダウンについて
2022年11月30日03:24（東京）に、AdGuard DNSに深刻な障害が発生し、マイアミ、ニューヨーク、ロンドンの3ヶ所のサーバーが影響を受けました。 障害発生中、これら3つの拠点に接続されているすべてのお客様のインターネットが事実上遮断されました。 これは、AdGuard DNSの全顧客の約20％、すなわち1000万人以上の方がインターネットに問題を抱えたことになります。 影響を受けた方に、このような事態になったことを心からお詫び申し上げます。 今後このような問題が発生しないよう対策を講じる所存です。 何が起きたのか 小さなミスがいくつも重なり、問題発生に至りました。 これらのミスは、それぞれ単独なら致命的ではなく、障害を引き起こすものではありませんでした。 しかし、残念なことに、これらのミスが重なったことこそが、より大きなトラブルの原因となりました。 最初のミスは、11月28日
VALUE-DOMAIN に存在していた2種類のドメインハイジャック脆弱性について - debiruはてなメモ
2022年3月2日に確認した VALUE-DOMAIN でのサブドメインハイジャックが可能な脆弱性について経緯を説明します。 ついでに2016年の記事「VALUE-DOMAIN に存在していたアカウント乗っ取り可能な CSRF 脆弱性について」の続報も含めて、この記事で2022年現在の VALUE-DOMAIN の状況についてお伝えします。 脆弱性を2つ発見しました 第一：子ゾーン作成によるサブドメインハイジャック 第一の脆弱性の攻撃の原理 VALUE-DOMAIN のネームサーバについて 第一の脆弱性 発見後の経緯 サブドメインハイジャック攻撃を受けた場合の影響 第二：CSRF 攻撃によるドメインハイジャック ドメインハイジャック攻撃を受けた場合の影響 CSRF 攻撃によるドメインハイジャックの対策状況 VALUE-DOMAIN ユーザの方へ 脆弱性を2つ発見しました （第一）子ゾーン作
“HTTPSレコード”って知ってる？今知るべき4つの注意点 | IIJ Engineers Blog
[注] この記事はすぐに陳腐化するはずの内容について扱っています。何年か経ってからこの記事を参照する場合、2022年3月に書かれた内容であることを留意の上お読みください。 はじめに IIJ DNSプラットフォームサービスにて、先日大きなアップデートと小さなアップデートがありました。大きなアップデートというのは、これまでのマネージドDNSサービスに加えてもうひとつ、IIJ DNSトラフィックマネージメントサービスという新たなサービスが追加されたこと。サーバの死活監視結果に応じて動的にDNSの応答を変えることができます。小さなアップデートは、従来のマネージドDNSサービスへの機能追加。HTTPSレコードに対応しました。 サービスの宣伝という意味では大きなアップデートの方を紹介した方がいいんでしょうけれど、ヘソ曲がりなのでここでは小さなアップデート、HTTPSレコードの方に焦点をあてます。 そも
シャッフルシャーディングを使ったワークロードの分離
現在では、世界でも最も大きいビジネスやほとんどの著名なウェブサイトをホスティングしている Amazon Route 53 ですが、その立ち上がり時期においては、はるかに控え目なものでした。 AWS のサービス開始後、さほど長い時間が経過する前に、AWS のお客様からは、Amazon Simple Storage Service (S3) 、Amazon CloudFront 、Elastic Load Balancing のサービスをドメインのルートで使用して、「www.amazon.com」だけでなく「amazon.com」というドメイン名も使いたいというご要望がありました。 これは、一見簡単なことに思えます。しかし、1980 年代に決定された DNS プロトコルの設計思想が、これを見た目より困難にしているのです。DNS には、CNAME と呼ばれる機能があり、所有者はドメインの一部のホ
CDNは5時間で開発できる | POSTD
「CDN」（content delivery network）という言葉からは、Googleのような大企業がいくつもの巨大なハードウェアを管理し、1秒当たり何百ギガビットものデータを処理する様子が想像されます。しかし、CDNは単なるWebアプリケーションです。私たちのイメージとは違いますが、それが事実です。8年前に買ったノートパソコンを使って、コーヒーショップの席に座りながらでも、きちんと機能するCDNを構築できます。この記事では、これから5時間でCDNを開発しようとするときに、直面するかもしれないことを紹介します。 まずはCDNの機能を明らかにしておきましょう。CDNはセントラルリポジトリ（通称：オリジン）からファイルを吸い上げ、ユーザーに近い場所でコピーを保存します。初期のオリジンはCDNのFTPサーバーでした。現在、オリジンは単なるWebアプリとなり、CDNはプロキシサーバーとして機
Understanding how Facebook disappeared from the Internet
Understanding how Facebook disappeared from the Internet10/04/2021 This post is also available in 简体中文, 繁體中文, 日本語, 한국어, Deutsch, Français, Español, Português, Pусский, and Italiano. The Internet - A Network of Networks“Facebook can't be down, can it?”, we thought, for a second. Today at 15:51 UTC, we opened an internal incident entitled "Facebook DNS lookup returning SERVFAIL" because we were worr
コンテナ データセンターで AS 取ってみた – Made in container
2021/03 末に APNIC から ASN と IPv4 /23、IPv6 /48 を個人として割り当てを受けました。 半年近くかかってしまいましたが、ようやく Internetable になったのでメモ程度ですが書き残しておきます。 1. データセンターを建設します 月日が経つのは早いもので、コンテナ用地を競売で取得してから既に 5 年ほど経ちました。 一般のご家庭でサーバーやネットワーク機器を稼働させると騒音やら夏場の室温やら床の耐荷重が気になるので、 若いうち ( 家庭内稟議とかいう面倒な制度が導入される前) にデータセンターを 1 つ建てておくといいと思います。 この記事を読んでいる方には今更かと思いますが、過去の投稿や記事もご参考にどうぞ。 ブログ記事 https://www.syuheiuda.com/?cat=40Think IT の記事 https://thinkit.
Amazon CloudFront の CNAME を管理するための新しい API と機能について | Amazon Web Services
Amazon Web Services ブログ Amazon CloudFront の CNAME を管理するための新しい API と機能について Amazon CloudFront は、ListConflictingAliases と AssociateAlias という 2 つの新しい API のリリースを発表しました。これらの API は、 CNAMEAlreadyExists エラーコードが発生した際に、代替ドメイン名（CNAME）を探したり、移動させたりする必要がある場合に便利です。さらに、アカウント間でワイルドカードの CNAME を使用する際に、より多くのユースケースで利用することが可能になりました。API について詳細を紹介する前に、このブログではまず CNAMEAlreadyExists エラーコードの背景を少し説明し、CloudFront ディストリビューションで CN
Public Suffix List の用途と今起こっている問題について | blog.jxck.io
Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ
コインチェックのドメインハイジャックの手法を調査した
しゅーとです。 コインチェックは 6月2日 、ドメインレジストラである「お名前.com」の管理アカウントに不正にアクセスされ、ドメイン登録情報が変更されたこと、またそれによって第三者によるメールの不正取得が行われたと発表しました。 プレスリリース(第一報)は以下です。 当社利用のドメイン登録サービスにおける不正アクセスについて（第一報） 攻撃を受けた時刻が 5/31 0:05 で、検知時刻が 6/1 12:00 と攻撃に気付くまでの時間は1日であり、また対応完了まで2日足らずとのことで、検知・対応は非常に迅速だったと思います。 今後第二報で詳細な内容が発表されると思いますが、プレスリリースから攻撃者がどのようにメールの不正取得を行ったのか、インターネット上の情報を用いて調査してみました。 ドメインハイジャックをされている関係上、メール以外にもSSL証明書の不正取得や偽Webサーバによる盗聴
DNS パケット欠落のケース: Google Cloud サポート ストーリー
※この投稿は米国時間 2020 年 5 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。 編集者注: Google Cloud テクニカル ソリューション エンジニア（TSE）がサポートケースにどのように取り組んでいるか気になったことはありますか？TSE はお客様から報告された問題の技術的な根本原因のトラブルシューティングと特定を担当するサポート エンジニアです。かなりシンプルな問題もありますが、数名の専任エンジニアによるトラブルシューティングを必要とするサポート チケットがたまに送信されることがあります。このブログ投稿では、Google Cloud テクニカル ソリューション エンジニアから聞いた、最近解決した特に厄介なサポートケース（DNS パケットが欠落する問題）についてご紹介します。トラブルシューティングの過程で収集した情報と、どのように方法を推論し
スマホゲームの API サーバにおける EKS の運用事例 | GREE Engineering
*1 デフォルトでは Pod に割り当て可能なセカンダリ IP アドレスを ENI 1個分(その ENI に割り当てできる最大数)確保する設定ですが、実際には DaemonSet などがありすぐに ENI 1個分の空きという条件は満たさなくなるので、ワーカーノード起動時に ENI 2個分(「そのインスタンスタイプが ENI ごとに割り当てできる IP アドレス数」の2倍)が確保されるということになります。ドキュメントとしては次のリンクをご参照ください。 参考: https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/cni-env-vars.html 参考: https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md 例えば、ピーク時に c5.4x
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実録_マルチテナント環境でのGmailガイドライン対応
Cloudflareが無料の新DNSサービス「1.1.1.1 for Families」発表。DNSのレベルでアダルトコンテンツやマルウェアをブロック