CNAME を巡る 2/3 のジレンマ - 鷲ノ巣
当ブログをご愛読頂いている方であれば、当然ご存知ないことと思いますが、俺は DNS が大好きです。 とは言っても、DNS サーバーの構築とか運用に詳しいわけでも、攻撃に対抗する方法を知っているわけでもありません。 やったことがあるのは、せいぜい、レンタル DNS サーバーでゾーン定義ファイルを書いて遊ぶくらいのものです。 昨今は、DNSSEC で遊びたいのですが、そのための環境が無く、悲しみに暮れています。 閑話休題。 タイトルの 2/3 のジレンマというのは、DNS の運用において成立させたい、とある 3 つの性質のうち、同時に成立できるのは 2 つまでで、3 つ全部を成り立たせるのは不可能だ、ということを指しています。 その 3 つの性質というのは、 Zone Apex によるアクセス DNS サーバーのアウトソーシング 変動する IP アドレス です。 こういうの、何て言うんでしょう
（緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年5月30日更新）
--------------------------------------------------------------------- ■（緊急）キャッシュポイズニング攻撃の危険性増加に伴う DNSサーバーの設定再確認について（2014年4月15日公開） ～問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨～ 株式会社日本レジストリサービス（JPRS） 初版作成 2014/04/15（Tue） 最終更新 2014/05/30（Fri） （対策に関するDNS運用者向け文書へのリンクを追加） --------------------------------------------------------------------- ▼最近の状況 最近、日本の大手ISPにおいてカミンスキー型攻撃手法によるものと考えら れるキャッシュDNSサーバーへのアクセスが増加している旨、JP
意外と知られていない？ DNSが抱えるセキュリティ問題
12月6日、Internet Week 2006のセッションの1つとして行われた「DNS Day」では、インターネットの基盤を支えるDNSサーバの「セキュリティ」がトピックの1つとなった。 12月5日から8日にかけて「Internet Week 2006」が横浜で開催された。このうち12月6日に日本ネットワークインフォメーションセンター（JPNIC）が主催した「DNS Day」では、インターネットの基盤を支えるDNSサーバの「セキュリティ」がトピックの1つとなった。 なりすましと反射を悪用したDoS攻撃 取り上げられた課題の1つは、偽装した発信元IPアドレスから不特定多数のDNSサーバにクエリを投げかけ、被害者に多数のパケットを反射させてDoS状態に陥れる「DNS amplification attack」だ。2006年3月には実際にその被害が発生し、警察庁からも関連するレポートが公表され
キャッシュポイズニングの開いたパンドラの箱
キャッシュポイズニングの開いたパンドラの箱 Opened Pandora's box of Cache Poisoning 鈴木常彦 2014.04.15 (Concept by 前野年紀 2014.02) / English version 背景 Kaminsky 2008年、Dan Kaminsky 氏が TTL に影響されない毒入れ手法を発表した。 しかし、偽応答のAdditional Section で毒が入るとされたのは誤りだったことを2011年に鈴木が明かにした。 http://www.e-ontap.com/dns/bindmatrix.html Müller Bernhard Müller の "IMPROVED DNS SPOOFING USING NODE RE-DELEGATION", 2008.7.14 https://www.sec-consult.c
インターノット崩壊論者の独り言 - 開いたパンドラの箱 - 長年放置されてきた DNS の恐るべき欠陥が明らかに
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 本日、JPRS がようやく重い腰をあげて注意喚起を発してくれましたが、その内容は危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません。 一方で注意深い攻撃者が探せば、ネット上にはすでに深刻な攻撃を行うのに必要な情報は十分に流れています。特に、JPRS が3月に慌てて co.jp などにこっそり入れた署名付き TXT レコードは大きなヒントに見えます。 DNS に詳しい攻撃者であれば、攻撃手法に辿りつくのは時間の問題でしょう。(すでに攻撃は行われているかも知れません) 長く秘密にしておくことは得策ではないと判断し、防御する側の心構えと手助けにし
DNS問い合わせの可視化 | ある研究者の手記
DNS問い合わせの可視化 最近、データをまとめたり可視化したりしてその性質を調べる探索的データ分析(例)にはまっています。と、同時にネットワーク分析にもちょっと手を出しており、その2つの派生物としてドメイン名問い合わせの結果を可視化してみました。 これを読んでいる人にはもはや説明の必要はないと思いますが、一応書いておくと、世の中のwww.google.comやwww.amazon.co.jpのようなドメイン名はサーバの場所を直接示しているわけではなく、「この名前を持っているサーバのIPアドレスはなんですか？」というのをDNSサーバという別のサーバに問い合わせることで目的のサーバのIPアドレスを教えてもらい、その後目的のサーバへ接続します。以前は正引き（ドメイン名からIPアドレスを問い合わせる）と逆引き（IPアドレスからドメイン名を問い合わせる）が対称構造になるように設定するのが主流でしたが
「魔法の数字8.8.8.8」を検証する:Geekなぺーじ
ここ数日、8.8.8.8や8.8.4.4というIPv4アドレスを持つGoogle Public DNSに関する話題が盛り上がっているのですが、多くの人が「よくわからないけど設定変更したら早い！」と言っているので、そこら辺の話を調査してみました。 昨日、Twitterとブログでtracerouteやdigによる調査協力のお願いを発信し、8.8.8.8へのtracerouteを37件、8.8.8.8とISP DNSへのtraceroute比較及びAkamaiキャッシュサーバへのtraceroute比較を21件、日本各地及び海外のいくつかの地点からご協力頂けました(皆様ありがとうございました！)。 それらのデータをもとに、Google Public DNSを利用した場合の通信経路と、それによる遅延に関する検証を行いました。 Google Public DNSに対する私の感想 まず最初に。 調査前
「昔IIJを使っていた人」にお願いです – オープンリゾルバ対策
2013年12月2日12:00に変更実施します 対象DNSサーバのIPアドレス 210.130.0.1 210.130.1.1 210.130.232.1 202.232.2.38 202.232.2.39 IIJmioのおしらせ IIJ4Uのおしらせ (202.232.2.38, 39は法人向けに提供しているサーバのため、mio/4Uのお知らせに含まれていませんが、同時に実施します。) 今回のてくろぐは、皆さんへのお願いのために書いています。特に読んで頂きたいのは「以前IIJのサービスをご利用頂いていたが、何らかの事情で今は利用していない方」です。 と、言うのも、今回お知らせする件は、「現在もIIJをご利用頂いている方」にはあまり影響がなく、「今は利用していない方」の中の一部の方に影響が出る可能性があるためです。現在もIIJをご利用中のお客様へは、サポートセンターや担当営業からご案内を差
DNS でラウンドロビンは当てにならない。 - JULY’s diary
モバイルでもDNSラウンドロビンはちゃんと動作しますか？ PCであれば、だいたいのブラウザが対応していると聞きますが、モバイルはどうなんでしょうか？ A、B、Cというサーバをラウンドロビンで動かした時に、Bが死んだとします。 その場合、PCはBに行かなくなると思いますが、携帯の場合はどうなんでしょうか？ 携帯はキャリアのプロキシ？か何かを通っていそうなので、ちゃんと動くのかが気になります。 また、ラウンドロビンの弱点は何ですか？ 今のところ気づいているのは、単に振り分けるだけだから1台に負荷が集中するかもしれないことくらいしかないです。 上の質問を見て、「あれっ、ラウンドロビンって、ブラウザのようなアプリケーションサイドで対応するものだっけ？ gethostbyname 辺りで勝手にやっていて、アプリ側は渡された IP で繋ぐだけでは？」と思っていたら、それは、もう古い話らしい。 0000
.inドメイン名停止とwhois公開代行:Geekなぺーじ
今日(4月30日頃)、一部の人々の間で「うちのWebサイトで使ってる.inの名前解決が出来なくなった！」という悲鳴が聞こえています。 数年前、インドのccTLD(country code Top Level Domain)である「.in」を日本国内のWebサービスで使うのが流行しました。 「.in」は「イン」と読めるため語呂が良く、個人が気軽にWebサイトを作ったときに、ドメイン名も同時に登録するというのが流行ったわけですが、そのときにwhoisで世界に向けて連絡先(個人であれば氏名住所電話番号の場合もあり)を公開されるのは嫌だということで、whois情報公開代行サービス(もしくはプライバシー保護サービス)を使うというのが割と一般的に行われていました。 しかし、その.inのレジストリであるINRegistryが、whois情報公開代行サービスを利用しているドメイン名を次々と停止しているよう
Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to S3編） | DevelopersIO
Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to S3編） [2013/02/15]記事のタイトルを変えました。 プライマリサイト（EC2ベース）からセカンダリサイト（S3ベース）へのDNSフェイルオーバーの記事となります。 Route 53へのフェイルオーバー機能とヘルスチェック機能の追加 先日のAWSよりRoute 53へのフェイルオーバー機能とヘルスチェック機能の追加に関しての発表がありました。 AWSでWebサイトなどをホストする場合、障害発生時に一時的にSorry Pageを表示したり、バックアップのWebサイトに切り替えたりといったことを自動的に行うことはこれまで比較的難しいかったと思います。 今回、Route 53にフェイルオーバー機能が追加されたことにより、プライマリサイトがダウンした際に、自動的に
Amazon ELBでSorryサーバへのフェイルオーバーを実現する | DevelopersIO
AWSにおいて、ELBによるSorryサーバへのフェイルオーバーは、長らく待ち望まれている機能です。先日、Route53にDNSレベルでのフェイルオーバー機能が実装（下記）されました。 Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to S3編） Amazon Route 53のDNSフェイルオーバー機能を利用したリージョンを跨いだバックアップサイトの構築（EC2 to EC2編） ただ、Route53を利用していない場合は、未だにヘルスチェック及びフェイルオーバーの機能は手組みする必要があります。無いなら作るしかないのです。わかりました、作りますよ。 前提 まず確認しておきたいのは、今回ご紹介するテクニックは、前述のRoute53によるフェイルオーバーと比べると、オモチャみたいなもんです。知ってますか？ 何と、Ro
DNSの運用状況 ISP編 - インターネット崩壊論者の過去の日記
社団法人日本インターネットプロバイダー協会の会員リスト*1のドメインを調べてみた。 結果 全会員185会員中、 自ドメインの権威サーバがキャッシュを応答する会員 156会員 (83%) 全サーバ435台中、キャッシュを応答するサーバ 342台 (79%) *1:顧客用というよりは自社用ドメインが多いと思われる
LinuxはローカルにDNSキャッシュを持たないことを初めて知った - 元RX-7乗りの適当な日々
先日、とあるLinuxマシンをセットアップした時に、"apt-get upgrade"で最新のモジュールをダウンロード・更新していたところ、途中でモジュールがダウンロードできなくなってしまった。 調べてみると、通信はできるけど名前解決が出来ていないことが分かった。 で、しばらくすると名前解決が行えるようになり、ダウンロードが再開された。 Windowsでは暗黙で，Mac OS XではlookupdがDNS解決の結果をキャッシュしていますが，Linuxではキャッシュを行わず，都度DNSサーバへ問い合わせを行ってしまいます。 第20回 いろいろなキャッシュ：dnsmasq, cache proxy：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社 とのことなので、どうやら、小さいサイズ(数KB〜数十KB)のファイルを連続してダウンロードしていることで、DNSサーバに軽
DNSリバインディングによるルータへの侵入実験
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年03月25日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、DNSリバインディング攻撃によりブロードバンドルーターの設定を外部からの侵入を許すように変更してみたので報告する。 DNSリバインディングに対する関心が高まってきている。本年1月12日には、読売新聞夕刊一面トップで、iモードブラウザ2.0のDNSリバインディングによる不正アクセスが報じられた。3月17日のcomputerworld.jpでは、『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』という翻訳記事が紹介された。実は「最も警戒すべきセキュリティ脅威」というタイ
インターノット崩壊論者の独り言 - 「まさか」なサービス事業者(と利用者)への警告 - 権威／キャッシュDNSサーバーの兼用によるDNSポイズニングの危険性について
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) 経由では本サイトにアクセスできないよう措置させていただいております。 JPRSから本日付けで「権威／キャッシュDNSサーバーの兼用によるDNSポイズニングの危険性について」<http://jprs.jp/tech/security/2012-07-04-risk-of-auth-and-recurse.html>という注意喚起文書(業界用語では通称「重複」)がでました。また、あわせて、「ドメイン名ハイジャック」及び「DNSポイズニング」の危険性に関する一連の注意喚起について<http://jprs.jp/tech/security/2012-07-04-risk-of-shared-dns.pdf>という解説資料もだされています。 重大なポイントは大きく2つ。 まず、共用DNSコンテンツサーバ(キャ
New gTLD Current Application Status
This page reflects the current application status. Application status will be updated from time to time to reflect the various New gTLD Program processes. Except for the application statuses "Withdrawn", "Delegated" and “RA Terminated”, application statuses are not final. A change in application status is intended to inform the applicants and the community of an application's current status. A cha
DNSキャッシュポイズニングの脆弱性に関する注意喚起：IPA 独立行政法人 情報処理推進機構
－放置すれば情報漏えい～信用失墜に至る可能性も。 ウェブサイト運営者は早急にDNSサーバのパッチ適用や設定変更を！－ 最終更新日 2009年2月6日 掲載日 2008年9月18日 >> ENGLISH 独立行政法人情報処理推進機構（略称：IPA、理事長：西垣 浩司）は、「DNSサーバに対するDNSキャッシュポイズニングの脆弱性」の届出が激増していることから、ウェブサイト運営者へ注意を喚起するとともに、DNSサーバのパッチ適用や設定変更を呼びかけます。 DNS(Domain Name System)(*1) キャッシュポイズニング（汚染）の脆弱性に関して、2008年7月に複数のDNS サーバ製品の開発ベンダーから対策情報が公開されています(*2)。また、この脆弱性を悪用した攻撃コードが既に公開されていたため、2008年 7月24日、IPAはウェブサイト運営者へ向けて緊急対策情報を発行しました
セキュリティ情報 - iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性
iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性 HASHコンサルティング株式会社 公開日:2009年11月24日 概要 iモードブラウザ2.0のJavaScriptとDNS Rebinding問題の組み合わせにより、iモードIDを利用した認証機能（以下かんたんログイン）に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。 背景携帯電話のかんたんログインとは、ケータイブラウザ（たとえばiモードブラウザ）に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固有の7桁のIDがWebサーバに送
DNS Rebinding ～今日の用語特別版～
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2007年11月26日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 楽天テクノロジーカンファレンス2007にて、カーネギーメロン大学日本校の武田圭史先生の講演を聴講して、DNS Rebindingの説明がとても分かりやすかったので、ここに再現を試みる(文責は徳丸にある)。 DNS Rebindingとは DNS Rebindingは、DNSの返すIPアドレスを巧妙に変化させることにより、JavaScriptやJavaアプレットなどのsame origin policyを破り、インターネットからローカルネットワーク(通常外部からはアクセスできない)などに対してアクセスする手法
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
