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アドレスのチ
MX Lookup Tool - Check your DNS MX Records online - MxToolbox
ABOUT MX LOOKUP This test will list MX records for a domain in priority order. The MX lookup is done directly against the domain's authoritative name server, so changes to MX Records should show up instantly. You can click Diagnostics , which will connect to the mail server, verify reverse DNS records, perform a simple Open Relay check and measure response time performance. You may also check each
黒塗りのDNS
黒塗りのDNS (萎縮編) ～共用サービスの闇～ Apr 23, 2019 ssmjp E-ONTAP.COM 鈴木常彦 (@tss_ontap) ある日の我が職場 (恥) 私(TEL) 「m.chukyo-u.ac.jp 見てみれ！ 中華料理屋に乗っ取られてるぞ www」 情報システム 「え！...これは...調べます...」 後日 「レンタルサーバ返した後 A レコード削除申請がなかったようです!」 危険な忘れ物 - Floating Domainname 借りたサーバ (IPアドレス) にリソースレコードを向けたまま解約してはいけない Subdomain Takeover Attack 放置された CNAME の先は狙って再登録されうる、、、 old-service.example.jp IN CNAME orphan.cdn.example.com fan.football.son
WebサーバのDNSへの登録方法が変わるよ – JANOG48 Meeting
場所 OHGAKI(完全リモート) 日時 Day3 2021年7月16日(金) 14:45～15:15(05分) 概要 HTTPSというDNSレコードタイプを定義するdraft-ietf-dnsop-svcb-httpsがもうすぐRFCになります。実利用はすでにはじまっており、WebサーバのDNSへの登録は従来のA/AAAAレコードから今後は新しいHTTPSレコードに移行していくことになるでしょう。本発表ではHTTPSレコードの簡単な紹介と、それにともなう注意点を説明します。 発表者 山口 崇徳(株式会社インターネットイニシアティブ) 資料 公開資料 DNSでHTTP (DNS Summer Day 2021)
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サーバの引っ越しの仕方を教えてください
権威DNSサーバの引っ越しには、正しい手順がある。間違った手順で行うと古い情報がいつまでも残り、引っ越しがうまくいかなくなることがある。詳細に興味がある方は、以下のドキュメントを参照いただきたい。 関連リンク JPRS トピックス＆コラム No.019「DNSサーバーの引っ越し～トラブル発生を未然に防ぐ手順とポイント～」 http://jprs.jp/related-info/guide/019.pdf Internet Week 2011 ランチセミナー「DNS浸透の都市伝説を斬る～ランチのおともにDNS～」 http://jprs.jp/tech/material/iw2011-lunch-L1-01.pdf ここでは、 同じホスト名でサービスを継続することを前提に、引っ越し対象となるWebサーバやメールサーバなどのサーバ群のホスト名は変更せず、IPアドレスのみを変更する 当該ゾーンを
019-DNSサーバーの引っ越し
1 JAPAN REGISTRY SERVICES JAPAN REGISTRY SERVICES Copyright © 2015 株式会社日本レジストリサービス ■「DNS サーバーの引っ越し」とは サービスプロバイダーやレジストラ（JP ドメイン名では 指定事業者）の変更に伴い、その対象となるドメイン名 の権威 DNS サーバーが変更されることを、「DNS サー バーの引っ越し（以下、引っ越し）」と呼ぶことがありま す。今回は引っ越しの中でも特に、 (A) すべての権威 DNS サーバーのホスト名と IP アドレ スが変更される (B) Webサーバーやメールサーバーなど、権威DNSサ ーバー以外のサーバーのホスト名は変更されず、 IP アドレスのみが変更される 場合について、作業時のトラブル発生を未然に防ぐ、 本来あるべき手順について解説します。 なお、以降では「引っ越し」を、上記
鈴木常彦先生の「共用レンタルサーバにおけるメールの窃盗」の話を聴講した
4月23日（火）に開催された 「#ssmjp 2019/04 ～DNSの話を聞く会～」に「Outputなら任せてください枠」で参加しましたので、講演内容からとくにやばい(?)内容と思われる@tss_ontap（鈴木常彦=浸透言うな先生）の「黒塗りの DNS (萎縮編)」から、「共用レンタルサーバにおけるメールの窃盗」について紹介します。スライドは公開されています。 サマリ レンタルサーバーからメールを送信する場合、悪意の第三者に、特定のドメインに対するメールを横取りされるリスクがある 攻撃手法 攻撃者は、レンタルサーバーを契約（お試しなどでも可能）して、攻撃対象のドメイン名（ここではchukyo-u.ac.jp…中京大学のドメイン名を用いる）を登録する その際に、当該ドメイン名の権利を有している必要はない（権利があれば正当にメールを受信できるので攻撃の必要がない） これだけ なぜメールが横
インターノット崩壊論者の独り言 - DNSSEC は危ない - これを NSEC/NSEC3 Replacement Attack と呼ぶのはどうだろう?
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) 経由では本サイトにアクセスできないよう措置させて頂いております。 二週間ほど前に恐ろしい毒入れ手法が成立しうることに気づいて、どうやって公表したらよいか悩やんだのだけれど、何と Herzberg と Shulman の論文を読み返したところアバウトながらしっかり書いてあったので躊躇することなく解説することにした。なぜ私はこれを読み流してしまっていたのか。どうしてこれを誰も騒ぎにしていないのだろうか。 DO bit を常に on にしろという RFC 4035 の傲慢な要請は修正されるべきだと思う。そして RFC 2308 という酷い RFC (私なら査読通さない) も SOA に付随する NS を許さないよう書き直されるべきだと思う。(私に IETF に行けというのは無し) 以下、第一フラグメント便
DNSで浸透って言っちゃだめなの？ - tmtms のメモ
別に言ってもいいよ。 以下想定問答。 「浸透が何を意味しているのかわからない」 ホント？ 「浸透いうな」って言われてるってことは、逆に言うとそれなりに広く使われてるってことでしょ。 個人的には「DNSの設定を変更した後、徐々に新しい情報を見ることができるクライアントが増えていく」ことだと思ってるんだけど、これとは異なる意味で使われてたりするの？ 「"浸透に数週間かかる" なんて言うのはへぼい業者の言い訳」 それは同感だけど、「浸透」という単語の問題じゃないよね。 「浸透」という単語を使わなくてもその業者はへぼいままで、数週間かかるのは変わらない。 数週間じゃなくて、「浸透には5分くらいかかります」だったらOK? 「設定ミスってるくせに浸透に時間がかかるなんて言い訳するな」ならわかるけど、「浸透という単語を使うな」はおかしいと思う。「浸透」を使わないことで何か解決するの？ 「浸透なんて用語は
インターノット崩壊論者の独り言 - 総務省の注意喚起は FUD - DNSSEC に関する一連の注意喚起で混乱中の皆様へ
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 総務省をはじめとする一連 (NISC,JPRS,JPNIC,JPCERT/CCあるいはそれらを元にした報道) の DNSSEC KSK ロールオーバーに関する注意喚起を鵜呑みにしてはいけません。総務省データ通信課の高村信企画官は注意喚起文書の文面が嘘も方便あるいは FUD であることを認め、さらには注意を喚起するためには「Terrible Story (恐ろしい話) が必要だった」とまで発言されています。(先日の記事参照) 彼らの説明や対策は DNSSEC 推進のための余計な方策が組み込まれているために、非常に複雑なものになっている一方で説明すべきことを説明していない
DNSSECバリデーションにおけるルートゾーンKSKロールオーバーに関する重要なお知らせ - JPNIC
DNSSECバリデーションにおける ルートゾーンKSKロールオーバーに関する重要なお知らせ DNSSEC技術によるバリデーション(署名検証)で利用するルートゾーン鍵署名鍵(KSK)のロールオーバー(更新)について、 重要なお知らせをいたします。 この度のルートゾーンKSKの更新は、 ICANNがルートゾーンKSKの管理者として進めているものです。 これに伴い、インターネットユーザーの4人に1人、 つまり7億5000万人に影響を及ぼす可能性があるとICANNは推定しています。 このためICANNは、 ルートゾーンKSKの更新に関するガイドライン文書を公開し、 グローバルに幅広い関係者に向けた周知を行っており、JPNICは、 ICANNが提供しているこれらのガイドライン文書が日本の関係者にとって重要な情報であると判断し、 翻訳を公開しましたのでお知らせいたします。 国内では、このガイドラインに
メールを受け取らないドメイン名に
example.comゾーンには次の内容で登録されているものとします。 example.com. 86400 IN A 192.0.2.80 送信側メールサーバは次のような順番で処理を行います。 宛先メールアドレス"foo@example.com"のドメイン名"example.com"に対するMXレコードを問い合わせる。 "example.com"に対する回答として0個のMXレコードを受け取る。（MXレコードが登録されていないため。なお、"example.com"そのものは存在するため、回答のステータスとしては"NOERROR"である。） "example.com"に対するAレコードを問い合わせる。（MXレコードが存在しないときには、Aレコードにフォールバックするため） "example.com"に対する回答としてIPアドレス"192.0.2.80"を値とするAレコードを受け取る。 IPア
TCPだけでDNSサーバにqueryできるようになってた:Geekなぺーじ
DNSメッセージといえばUDPの53番というイメージの方々も非常に多いと思いますが、1987年に発行されたRFC 1035の時点でDNSメッセージのトランスポートとして利用できるのはUDPとTCPであると記述されています。 しかし、これまでDNSにとってはUDPが基本でした(ゾーン転送を除く)。「RFC 1123: Requirements for Internet Hosts」には、以下のようにあります。 DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries. Specifically, a DNS resolver or server that is sending a non-zone-transfer
図解でわかるキャッシュポイズニング
出典：日経NETWORK 2015年7月号 pp.31-32 （記事は執筆時の情報に基づいており、現在では異なる場合があります） 攻撃者は工夫を凝らし、ソフトウエアの脆弱性を意のままに操ろうとしている。だが、ソフトウエアに脆弱性が存在しても、意図したように動作させるのは容易ではない。その手口は、脆弱性の種類によって様々だ。どのようなメカニズムで脆弱性は悪用されるのか。代表的な手口を取り上げ、その恐るべきメカニズムを図解する。 この特集で紹介した脆弱性の多くは、入力データのチェックミスといった、設計や実装の不具合が原因である。だが、中にはプロトコルや仕様が原因で脆弱性が生じ、悪用されるケースもある。その1つが、DNS▼サーバーが影響を受ける「DNSキャッシュポイズニング」攻撃である。 これは、ドメイン名とIPアドレスの偽の対応情報を、DNSサーバーにキャッシュさせる攻撃。権威DNSサーバー▼
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.e-ontap.com/dns/csec87/
「 DNS 浸透いうな」と言うけれど ...
ネット史上初めての「KSKロールオーバー」が始まる、名前解決できなくなる前にDNSサーバーなど設定確認を！ 今年9月は特に注意 「Internet Weekショーケース in 名古屋」の発表から
DNSサービス提供者としての権威DNS
「ドメイン名ハイジャック」及び「DNSポイズニング」の危険性に関する一連の注意喚起について