危険なDNSサーバの利用者へ警告 - インターノット崩壊論者の独り言(2011-11-02)
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 これまで多くの警告がなされているにも関わらずインターノットにはたくさんのオープンリゾルバが存在しています。その中にはポート番号がランダマイズされていない危険なサーバがいくつも見つかっています。こうしたサーバの管理者に個別に連絡してあげられる時間は残念ながら私にはありません。 古くからDNSの諸問題に取り組まれている qmail.jp の前野さんからも「たくさんの危険なサーバが見つかっているのだが、どうしたものだろう」という声が聞こえてきていました。 どうしたものかと考えて、思案した結果「毒入れ」を敢行することにしました。「毒入れ」と言っても大量の偽応答を送り込むような
なぜ「DNSの浸透」は問題視されるのか:Geekなぺーじ
「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定
浸透いうな!
DNSの引越しをしたけどうまく切り替わらない。なかなか浸透しない。業者に問い合わせると「DNSの浸透には数日かかることもあります。お待ちください」と言われた。 、、、という話をよく聞きますが、「浸透」(伝播、伝搬、浸潤、反映などとも呼ばれる)ってなんでしょう? DNSの設定を変更するのは「浸透」という謎の現象に託す神頼みのような作業なのでしょうか。 2011.10.16 追記:「浸透」と言っている例 DNSの仕組み まず、DNSの仕組みと、特にキャッシュの動作について解説します。...と思いましたが、とっても大変なので省略します。ただ、権威サーバに登録された情報が世界中のキャッシュサーバに配信されるなどという仕組みは DNS には存在しません。浸透という人はそう思っているようですが。(こんなふうに) 「浸透」という言葉で騙されていませんか? 事前に変更したいDNSのレコードのTTLを短くし
「魔法の数字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に対する私の感想 まず最初に。 調査前
「8.8.8.8,8.8.4.4」より速い「129.250.35.250」
iPhoneのDNSの設定変更が話題になっているようなので、レスポンスの速いDNSサーバがないか調べてみました。便乗記事です。 ネタフル - iPhoneのWiFi接続を高速化する魔法の数字「8.8.8.8,8.8.4.4」 測定ツールはWindows用の「DNS Nameserver Performance Benchmark」です。ツールの詳細は割愛しますが、測定するには下のスクリーンショットの「Nameservers」タグの右側にある「Run Benchmark」をクリックするだけです。 Bフレッツ接続のPCで測定しています。 １．ベンチマーク結果 まずはベンチマーク結果をご覧ください（クリックすればちょっと拡大します）。 測定している値は次の3種類です。それぞのれの意味については「私家版 ITプロフェッショナルの仕事術 - GRCのDNS BenchmarkでDNSをスピードアップ
DNSサーバによる検閲を回避する8つの方法 | スラド IT
米国では「著作権侵害を犯しているとされるWebサイトを検閲する機能を著作権者に提供する」という、Protect IP法案が検討されている。これはDNSサーバーに検閲機能を持たせることで実現するそうなのだが、本家/.ではこれに対抗する「検閲を回避する8つの方法」が紹介されている（ネタ元のZero Paid記事）。日本でもDNSを用いた児童ポルノのフィルタリングがすでに行われており、他人事ではない。紹介されている回避方法は下記のとおり。 VPNサービスの使用：信頼性が高くセキュリティー機能には優れているがコストがかかるhostsファイルの使用：DNSサーバの必要性を完全に排除できるが、メンテナンスを必要とするTORの使用：匿名での通信を行うのに優れているが、コンテンツをダウンロードする必要がある無料 DNSツールの使用：無料である。だが、インターネット接続業者にブロックされないという保証はない
GREE Engineer's Blog coming soon...
コンテンツへスキップ ナビゲーションに移動 【謎解き解説】GREE Tech Conference 2025 〜クラッシュしたゲームを復元せよ〜2025/12/09hidakatakumaこんにちは！GREE Tech Conference 2025 謎解き運営チームです。 はじめに GREE Tech Conference 2025にご参加いただいた皆さま、誠にありがとうございました！ 今年も大好評だっ […] InfoDEXA 2025 に参加してきました2025/10/29yamashitafumihiro Conference こんにちは。開発本部 インフラストラクチャ部の山下です。 8/25 - 8/27 にタイ・バンコクで開催された DEXA という国際会議に参加 / 発表してきましたので、その報告をさせていただきます。 はじ […] GREE Tech Conferenc
（緊急）BIND 9.7.xの脆弱性を利用したサービス不能（DoS）攻撃について
--------------------------------------------------------------------- ■（緊急）BIND 9.7.xの脆弱性を利用したサービス不能（DoS）攻撃について - 9.7.3へのバージョンアップを強く推奨 - 2011/02/23（Wed） --------------------------------------------------------------------- ▼概要 BIND 9.7.1から9.7.2-P3までのバージョンには実装上の不具合があり、ゾー ン情報の更新に差分転送（IXFR）またはDynamic Update機能を使用している 場合、namedに対するリモートからのサービス不能（DoS）攻撃が可能になる 脆弱性が存在することが、開発元のISCより発表されました。本脆弱性は危 険度が高いため、該当
リビアのインターネットとbit.ly:Geekなぺーじ
Twitterなどを使っているとbit.lyというURL短縮サービスを良く見ますが、「.ly」というccTLD(country code Top Level Domain)はリビアです。 現在、リビアが不安定化していますが、もしリビアのccTLDが停止した場合、bit.lyが影響を受ける可能性もありそうです。 まず、最初にどの部分がどう影響があるのかを見てみます。 bit.lyそのものはアメリカにありそうです。 DNSはDny Inc.によるDynectとNTT CommunicationsのAS2914のIPアドレスという組み合わせです。 この組み合わせによる運用(負荷分散)はTwitterと同じです。 > dig bit.ly. ; <<>> DiG 9.4.3-P2 <<>> bit.ly ;; global options: printcmd ;; Got answer: ;; -
IDN Info by JPRS / 標準化状況
■国際化ドメイン名の標準化状況 国際化ドメイン名の最初の標準は2003年に制定されました。その後、最初の標準における課題を解決するために改定作業が行われ、2010年に新しい標準が制定されました。新しい標準は、最初の標準を置き換えるものです。 最初の標準（IDNA2003）と新しい標準（IDNA2008）の主な相違点は以下の通りです。 Unicodeのバージョン依存性 IDNA2003はUnicodeバージョン3.2を参照していますが、IDNA2008はUnicodeバージョンに依存しません 禁止文字リストと許可文字リスト IDNA2003は使用不可能な文字（禁止文字）のリストを定義していますが、IDNA2008では使用可能な文字（許可文字）のリストを定義しています 文字列の正規化 IDNA2003は国際化ドメイン名として入力された文字列の正規化（大文字小文字や全角半角文字の統一、文字の合成
.jpゾーンへの署名鍵(DSレコード)登録受け付け、公開開始 « DNSSECジャパン
2011年1月16日から、.jpゾーンへ署名鍵を登録することができるようになりました。 これにて.jpゾーンにおけるDNSSEC導入が完了したということで、.jpゾーンのレジストリであるJPRSからプレスリリースが出ています。 JPRSがJPドメイン名サービスにDNSSECを導入 http://jprs.co.jp/press/2011/110117.html 筆者も早速自分の.jpドメインの署名鍵をJP DNSに登録してみました。 まずwhois DBの [Signing Key] が更新され、その後10分ほどでJP DNSにて該当ドメインのDSレコードを検索できる状態となり、めでたくDNSSEC対応が完了しました。 登録の前後には VeriSign Labs の DNSSEC Debugger http://dnssec-debugger.verisignlabs.com/ や San
JP DPSの公開について | 2011年 | JPドメイン名についてのお知らせ | 新着情報一覧 | JPRS
2011/01/14公開 JPRSは2011年1月14日、「JPドメイン名におけるDNSSEC運用ステートメント（JP DPS）」を公開しました。 DPS（DNSSEC Practice Statement）は、管理対象ドメイン名におけるDNSSECサービスの安全性や運用のポリシー、考え方、手順などについて網羅的にまとめた文書で、そのドメイン名のDNSSEC運用者が必要に応じて作成・公開します。 DPSはPKI（*1）におけるCPS（*2）を元にしており、その作成のための枠組みはIETFにおいて標準化が進められています。JP DPSはその記述に、draft-ietf-dnsop-dnssec-dps-framework-03（参考URLを参照）で定められる方式を採用しています。 JP DPSの全文は、以下のURIで公開されています。 日本語https://jprs.jp/doc/dnsse
Google ChromeのDNSプリフェッチ - cNotes: Current Status Notes
いまさらですが。。。 DNSプリフェッチ、、、要はユーザがクリックする前、ユーザーがリターンキーを押す前に、どういうURLにアクセスしそうかChromeが判断して、事前にDNSでの名前解決を行っておくことで、名前解決の時間を短縮してウェブアクセスの体感速度の向上を測るという技術ですね。 よく例に上がるのが、表示されたページのリンクのドメインに対するプリフェッチですが、それ以外にも、Google Chromeだと、アドレスバーに入力する文字列についてもプリフェッチが行われます。 例えば、アドレスバーに www.google.com と入力するとき、 www.google.co で、クエリが飛び、 www.google.com まで打ったときにリターンキーを押す前にクエリが飛びます。 これ、 文字列.TLD という形になった瞬間にクエリを飛ばすもののようで、 hoge.cc hoge.pr で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン名やDNSの解説 | ドメイン名関連情報 | JPRS
ういにゃん|フリーランスUnityエンジニアDJ Youtuber on Twitter: "http://t.co/8FiCNJ3p息してない 【10/12DJ http://t.co/WiTnClBo 】"
Amazon Route 53（スケーラブルなドメインネームシステム (DNS)）| AWS
新gTLD、ICANNの理事会が計画を承認、2012年1月12日から申請受け付け 
[PDF]ＤＮＳサーバーの引っ越し ～トラブル発生を未然に防ぐ手順とポイント～
http://jprs.jp/tech/material/id/draft-ietf-dnsop-rfc4641bis-04-ja.txt
TechCrunch | Startup and Technology News
