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
DNSpooqの脆弱性詳細と攻撃コード解説 - knqyf263's blog
概要 要約 詳細 背景 前提 インターネット上に公開されたdnsmasq LAN内のマシンが攻撃者の支配下にある LAN内のマシンに攻撃者管理のWebサイトを閲覧させることができる 影響 中間者攻撃 汚染拡大 DDoS/Reverse DDoS CVE-2020-25684: ポートの多重化 CVE-2020-25685: 脆弱なCRC32の利用 CVE-2020-25686: 同一ドメイン名に対する複数クエリ発行 DNSフォワーダにおけるレスポンスの未検証 組み合わせる ドメイン名の登録 ソースIPアドレスの偽装 CRC32の衝突 攻撃の流れ ブラウザからの攻撃 検証端末 攻撃の成功確率 PoC fowarder cache attacker 大量クエリの送信 偽装レスポンスの送信 高速化の話 実行 対策・緩和策 余談 まとめ 概要 先日DNSpooqという脆弱性が公開されました。 ww
DNS Resolvers Performance compared: CloudFlare x Google x Quad9 x OpenDNS
A couple of months ago I did a performance comparison between some of the top free DNS Resolvers available. It was just after Quad9 had launched and I was trying to decide which one to use and recommend to families and friends. Google, OpenDNS, Quad9, .. some many options… I love options … And things just got better. CloudFlare, one of the companies that know the most about Internet performance re
.io ドメインがおかしくなったので dig で調べてみた（2016/10/28） - Qiita
更新履歴 思ったより参照量が多くてビビる。 情報源として使用されてるケースも見かけたため、更新履歴入れました。（多分今日だけでしょう） 2016-10-29 11:50 ns-a4.io が正しく次の権威サーバーを返してくれるの確認しました。障害復旧でいいんじゃないでしょうか。Android で dig 叩くツールあった。 03:08 http://dnsviz.net/d/io/WBOUpA/responses/ 直った？ 2016-10-28 19:21 JST @rocca0504 さんの記事追記。 19:10 JST NXDOMAIN ステータスを勝手に返すのが問題の本質だったので追記。 18:10 JST dig の +norecurse (+norec) について追記しました。(@fumiyas さんご指摘ありがとうございます。) 見た目悪くなりますが、必要な箇所には記載がある
Google Public DNS over HTTPS を試す | IIJ Engineers Blog
【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 サーバ(フルレゾルバ)を提供し
facebookの13億ユーザーを支えるロードバランサーの話 - stanaka's blog
最近、SREが話題ですね。 tech.mercari.com www.wantedly.com ということでSREについて調べてたら、SREconなんてものが開催されていたので中を見てたら、「Building a Billion User Load Balancer」というタイトルでFacebookのDNS〜LBまでの話があったので、そのメモです。 Building a Billion User Load Balancer | USENIX tl;dr tinydns + IPVS で Facebook規模はいける httpsの接続確立はかなり重い(RTTの4倍 = RTT 150msとするとGETまで600ms)ので、太平洋越えとかは厳しい httpsを終端させるCDNとかは活用の可能性ありそう (国内だけを考慮するなら影響は軽微かも) メモ L4 LB shiv (IPVS + pyt
livedoor Techブログ : CNAMEの間違った使い方
情報環境技術研究室の永井です。 今日はDNSのCNAMEの間違った使い方のお話です。 その間違った使い方がうちのサービスで使用されているかもっ!? DNSって? Domain Name System（ドメイン ネーム システム、DNS）はインターネットを使った階層的な分散型データベースシステムである。 1983年に情報科学研究所 (ISI) のポール・モカペトリスとジョン・ポステルにより開発された。 Wikipediaより一部抜粋 http://ja.wikipedia.org/wiki/Domain_Name_System 例えば、ライブドアのポータルサイトといえば「http://www.livedoor.com/」ですが、実際には「http://125.6.172.15/」というIPアドレスがインターネット上の住所になります。でも、こんな数字の羅列を一々覚えていられないので、DNSとい
（緊急）複数のDNSソフトウェアにおける脆弱性（システム資源の過度な消費）について（2014年12月25日更新）
--------------------------------------------------------------------- ■（緊急）複数の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を含む複
実践！ヌーラボサービスでの CloudFront の障害対策 | 株式会社ヌーラボ(Nulab inc.)
CDNが単一障害点にならないようにするために ヌーラボでは 2010 年 Cacoo の商用サービスの開始に合わせて AWS における運用を開始しました。当時、運用環境として AWS を採択する決め手の一つになったのが CloudFront でした。その後も着々とエッジロケーションは増え、独自ドメインのサポートなど魅力的な機能も提供され、今ではヌーラボの全サービスの静的ファイルの配信で利用している、無くてはならないサービスとなっています。 その魅力の反面、CloudFront の障害は、アプリケーションそのものに問題がなくても、以下のような表示が崩れた画面が表示されて、ユーザが全くサービスを使えなくなるという、その影響が非常に大きいものです。また障害の原因が DNS やネットワークの経路における問題といった、私たちが直接解決しにくい領域にあることもしばしばです。 ただ、どんな事情であれ、障
Cloud DNS documentation | Google Cloud
Stay organized with collections Save and categorize content based on your preferences. Publish your domain names by using Google's infrastructure for production-quality, high-volume DNS services. Google's global network of anycast name servers provides reliable, low-latency, authoritative name lookups for your domains from anywhere in the world. Learn more
クラウド時代はDNS Pinningが落とし穴になる | 水無月ばけらのえび日記
公開: 2011年9月3日19時50分頃 モバツイ (www.movatwi.jp)の作者えふしんさんと、Twitterでこんなやりとりをしました。 OperaってDNSのTTL考慮してない？！多くのブラウザは安全性のために短すぎるTTLを無視したりしますが (DNS Pinning)、それとはまた違う話でしょうか?AWSのElastic Load Balancingで、動的にロードバランサーのサーバが増えたり減ったりするようで、夜明けのOperaがよく全然違うサービスに繋がってしまうことがあるんですよね。少なくともクッキーは送っちゃってますよね...あー、なるほど。それはまずいですね。これは盲点でした……。 OperaやIEなどは、DNSのTTLが短く設定されていても無視してキャッシュし続ける事があります。これはDNSの負荷を減らすというだけはでなく、セキュリティ上の意味もあり、「DNS
JPRSが最新の技術標準に対応したDNS解説書籍『実践DNS』を出版 / 株式会社日本レジストリサービス（JPRS）
＜本書の特長＞ DNSの基礎知識から具体的な設定・運用までを幅広く解説 DNSSECやIPv6など、最新の技術規格に対応 基礎知識の解説において専門用語を極力排し、幅広い読者層のニーズに対応 ＜本書の目次＞ 第1部 導入編 インターネットの基礎知識 第1章 インターネットではどうやって相手を特定するのか 第2章 重要性を増すDNS 第2部 入門編 DNSの基礎知識 第3章 急成長を可能にし、対応した仕組みの本質 第4章 DNSの概要 第5章 DNSにおける信頼性の確保と信頼の連鎖の構築 第3部 実践編 DNSの設定と運用 第6章 基本的な知識 第7章 キャッシュDNSサーバーの設定と運用 第8章 権威DNSサーバーの設定と運用 第9章 DNS運用技術 付録 付録A ICANNとIANAの概要 付録B トップレベルドメイン名（TLD）一覧 付録C DNSキャッシュポイズニングとカミンスキーメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PDF]【第2報】障害に関するお詫びとご報告 - 株式会社朝日ネット