一番下に追記あり。 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 (
総務省は、本日、株式会社日本レジストリサービス（JPRS）に対し、我が国の国別トップレベルドメイン名である「.jp」の管理・運用が適切に行われるよう要請しました。 旧山梨医科大学（※）がかつて利用していたドメイン名「yamanashi-med.ac.jp」について、本来「ac.jp」ドメイン名の資格要件を満たさない者を登録してしまい、成人向けウェブサイト開設のために利用されていた事案がありました。 「.jp」ドメイン名を管理・運用しているJPRSでは、同社の「属性型（組織種別型）・地域型JPドメイン名登録等に関する規則」において、「ac.jp」ドメイン名は高等教育機関等のみが登録できるものとして資格要件を定めています。 本事案は、「ac.jp」の登録に当たって申請者が資格要件を満たすかどうかの確認漏れがあったものです。 （※）旧山梨医科大学は平成14年に山梨大学の医学部として統合。 インタ
2018年9月頃から第三者に汎用JPドメインがのっとられるドメイン名ハイジャックの事例が相次ぎ、これらは不正なドメイン移管手続きにより発生した疑いがあります。ここでは関連する情報をまとめます。 不正移管の手口 のっとり犯が自身が利用するレジストラを通じて他人が所有するドメインの移管申請を行う。 次のいずれか該当する場合に（一時的に）ドメイン移管申請が行われてしまう恐れがある。 指定事業者が承認確認（不承認含む）を行わない（放置する） 登録者または指定事業者がのっとり犯が行った移管申請を誤って承認してしまう 汎用JPが狙われているのは自動承認ルールを悪用しているためとみられる 移管元指定事業者から承認、または不承認が10日以内に確認取れない場合、自動承認となる。 「汎用JPドメイン名登録申請等の取次に関する規則」第11条第2項に則ったものとされる。 第11条（取次にかかる登録申請等に対する決
--------------------------------------------------------------------- ■（緊急）米国国土安全保障省によるDNS設定の改ざんに関する緊急指令の公開について 株式会社日本レジストリサービス（JPRS） 初版作成 2019/01/28（Mon） --------------------------------------------------------------------- ▼概要 2019年1月22日、米国国土安全保障省（DHS）のサイバーセキュリティ・イン フラストラクチャセキュリティ庁（CISA）が「Mitigate DNS Infrastructure Tampering（参考訳：DNSインフラストラクチャ改ざんの軽減）」という緊急 指令（Emergency Directive 19-01）を公開しました。 本
When the Internet was built, computers weren’t mobile. They sat in offices next to data centers. The Internet has changed but the assumptions made 30 years ago are making your experience slower and less secure. 1.1.1.1 with WARP replaces the connection between your device and the Internet with a modern, optimized, protocol. Learn more Your Internet service provider can see every site and app you u
【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 サーバ(フルレゾルバ)を提供し
この脆弱性は2016年2月17日に対策済みバージョンと共に公開されました。内容としては getaddrinfo の呼び出しにおいてスタックバッファオーバーフローが発生する物です。公開時点で以下の通り、PoC を含めた技術的な詳細が公開されています。本記事では、脆弱性が発生するまでの処理と、回避策について解説したいと思います。 CVE-2015-7547 — glibc getaddrinfo() stack-based buffer overflow Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow 脆弱性に至るまで 今回の脆弱性は getaddrinfo の呼び出しに起因しています。脆弱性のある箇所までの関数呼び出しは以下の様になっています。 getaddri
今日になって突然、光回線なのに2Mbpsしか出なくなりました。 回線は、Softbank光。いろいろググると遅いという意見が多いので、それなのかなぁと思ったのですけれど、原因はどうもDNSっぽい。 なんとDNSを再設定したら、50Mbpsの速度まで戻りました。 追記: いただいたご意見・ご指摘を参考に記事を追記しました。 (11/25) 光回線の速度低下はDNSの設定が原因？ もともと設定していたのは、Google Public DNSというもの。（8.8.8.8と8.8.4.4） USENのスピードテストを行ってみたところ、なんと2Mbpsというスマホの3G回線並みの速度。これはひどい。。。↓↓ そこで、DNS設定を再設定。なんと速度が復活しました。↓↓ 別サイト、BNRスピードテストで試したら、50Mbpsまででるように。↓↓ ここまで出たら上等ですね。 さてやったことといえば、プロバ
This blog post is older than a year. The information provided below may be outdated. 本記事は、Microsoft Security のブログ “ Threats in the Cloud – Part 1: DNS Attacks ” (2014 年 2 月 4 日公開) を翻訳した記事です。 クラウド サービスの人気は、ここ数年で著しく増加しています。このような成長の背景には、クラウド サービスの設計や管理の方法の透明性が大きな役割を占めています。クラウド サービスの活用について話をした CISO の多くは、安心して組織のデータやアプリケーションをクラウドでホストできるよう、クラウド サービスが直面する脅威の種類についての詳細情報を求めています。最新版のマイクロソフト セキュリティ インテリジェンス レ
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
本日、JPRSが緊急の注意喚起を公表しました。 緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
DNS問い合わせの可視化 最近、データをまとめたり可視化したりしてその性質を調べる探索的データ分析(例)にはまっています。と、同時にネットワーク分析にもちょっと手を出しており、その2つの派生物としてドメイン名問い合わせの結果を可視化してみました。 これを読んでいる人にはもはや説明の必要はないと思いますが、一応書いておくと、世の中のwww.google.comやwww.amazon.co.jpのようなドメイン名はサーバの場所を直接示しているわけではなく、「この名前を持っているサーバのIPアドレスはなんですか？」というのをDNSサーバという別のサーバに問い合わせることで目的のサーバのIPアドレスを教えてもらい、その後目的のサーバへ接続します。以前は正引き（ドメイン名からIPアドレスを問い合わせる）と逆引き（IPアドレスからドメイン名を問い合わせる）が対称構造になるように設定するのが主流でしたが
DNS Summer Days 2013の初日最後のセッションで面白い話が公表されていました。 JPCERT/CCに対して「うちのDNSが攻撃されています。助けて下さい」という問い合わせが来ることがあるらしいのですが、調べてみるとその大半がDDoSの踏み台として使われているのであって、実際は攻撃に加担してしまっているというものでした。 他者を攻撃するトラフィックを生成することで、自身の回線やサーバに負荷がかかってしまっている状態が凄くよくあるそうです。 「助けて！」と言っている人が、意図せずに誰でも使えるオープンリゾルバとして設定されており、攻撃者の踏み台にされているというものです。 キャッシュDNSサーバの設定を変更し、オープンリゾルバをやめると問題が解決することが多いとのことでした。 今年に入ってから、オープンリゾルバがDDoS攻撃の踏み台にされる話がインターネット通信業界で話題です。
DNSの終焉が垣間見える、ぶっ飛んでて危険すぎるお名前.comの検閲事件
忍者ツールズ全サービスが表示不可となる障害につきまして | ドメイン取るなら お名前.com ドメイン取得 年間280円～ 忍者TOOLSは、お名前.comというドメイン名レジストラにninja.co.jpのドメイン情報を管理させていた。忍者TOOLSは、ninja.co.jpというドメインを、自社の様々なサービスに使っていた。そのサービスは、忍者TOOLSのユーザーが使うものである。 さて、お名前.comの主張では、忍者TOOLSのユーザーがお名前.comの規約違反を起こしたために、ユーザーの規約違反は、すなわちそのユーザーのサービス提供元の規約違反であるとし、事前の協議や警告すらなしに、一方的にninja.co.jpのドメイン情報を消したそうだ。 これは恐ろしく危険な事件である。問題は、DNSが階層的な中央管理をされたシステムである以上、この問題は仕組み上どうしようもないという事である
日本で行われている児童ポルノブロッキングで採用されているのは、DNSキャッシュサーバがブロックリストに掲載されたFQDNの名前解決を行わないという、DNSキャッシュポイズニングという手法です。 この手法は、主にISPが提供するDNSキャッシュサーバにて行われているので、児童ポルノブロッキングを行っていないDNSキャッシュサーバを利用することで回避が可能です。 また、IPアドレスを直接指定して通信を行うことで回避することも可能です。 このような手法が採用されていることに関して、「アホじゃないの？」とか「ザルじゃないの？」という感想が述べられがちです。 昨日、以下のような記事が出ていましたが、それに対しても「仕組みを考えた奴はバカだろう」的なニュアンスの感想が散見されます。 児童ポルノ遮断、「ＩＰ直打ち」ですり抜け横行 : 社会 : YOMIURI ONLINE（読売新聞） 私の感想 「IPア
最近、特集執筆のためIPv6の取材をする機会があった。IPv6のことはご存じの方も多いと思うが、いまのIPネットワークで使用されるIPv4の後継にあたるプロトコルである。2011年3月ころとみられるIPv4アドレスの枯渇（関連記事）や、4月以降にNTT東西のNGN上でIPv6インターネット接続サービスが始まる（関連記事）ことをきっかけに普及が進むとみられている。 機器/ソフトベンダーやサービス事業者にIPv6関連の取材をしていると、たびたび「ナゾ」が出てくる。ここでは最近記者が遭遇した「IPv6でDNSを使う」ときの二つのナゾを紹介したい。 DNSの役割はIPv4でもIPv6でも同じだ。ホスト名からIPアドレスを調べる正引きも、IPアドレスからホスト名を調べる逆引きも利用できる。ところがIPv6では、IPv4のようにはいかないのだ。 ナゾその1：DNS問い合わせのうち、なぜIPv6アドレス
--------------------------------------------------------------------- ■権威DNSサーバーにおける不適切なBogonフィルターの設定について - 設定内容の確認と割り振り状況に対応したフィルターの更新を忘れずに - 株式会社日本レジストリサービス（JPRS） 初版作成 2010/11/02（Tue） 最終更新 2010/12/02（Thu） （0.0.0.0/7に関する注意事項を追加） --------------------------------------------------------------------- ▼概要 IANAが割り振りを開始していない未割り当てのIPアドレス、プライベート IPアドレス・例示用IPアドレスや、特殊な用途のためにIANAが予約している IPアドレスといった、本来インターネット
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
