--------------------------------------------------------------------- ■D.root-servers.netのIPアドレス変更について 株式会社日本レジストリサービス（JPRS） 初版作成 2012/12/18（Tue） --------------------------------------------------------------------- ▼概要 ルートサーバーの一つ、D.root-servers.net（以下、D-root）のIPアドレス が2013年1月3日に変更される予定である旨、D-rootの運用者である米国メリー ランド大学から事前予告（advance notice）がありました。 D-Root Renumbering - Division of Information Technology

2012年2月22日(水) ■ Apache 2.4 正式リリース _ 2.4.1 出た。…2.4.0 は？ _ しばらく前からリリースされそうな気配が見えてたので、うちのサーバも 2.3 の最終版で設定のテストをしておこうかと思ったんだけど、間に合わずリリースが先になってしまった。ずいぶん前から評価目的ではいろいろいじってたので、とくにとまどうことなく移行できる目算はついてはいるんだが。このところなんか時間が取れないな。仕事は(いつもどおり)あまりしてないのになんでだろ。まあ、本気でやろうと思えばこの程度の作業に使う時間ぐらいは確保できるので、その程度のやる気しかないってことだが。 ■ ルートサーバをでっちあげよう _ global blackout の件、なんか Anonymous は おれ知らねーとか言ってるし、落とすの無理っしょ、とかいう 記事に対して いい指摘だとか言ってる。わし

ISPのDNSキャッシュサーバはTTLを越えてキャッシュを保持するか? Aレコードが5分毎に書き換わる a.t.e-ontap.com を用意して、キャッシュの expire を確認した。a.t.e-ontap.com の TTL は 60秒としており、コンテンツサーバ側での切り替え時刻+1分以内でAレコードの指すIPアドレスが変化すれば OK である。 (http://a.t.e-ontap.com/ でブラウザのチェックも可能。ただし途中のProxyの存在に注意) 2014.3.23追記: 「浸透おそい」の原因はブラウザでしょ (Firefox編) も参照のこと。 結果として、ISPのキャッシュサーバに(TTLを短くしているのに)「浸透が遅い」といわれるような問題は発見されなかった。ISPのサーバに問題があるというのは個人的な失敗のトラウマか都市伝説の可能性がある。かつてケータイのDN

ドメイン名やDNS、サーバー証明書などにまつわるトピックスを解説したコラムです。 JPRSがオフィスの受付やイベント会場などで配布しているものと同内容のHTMLやPDFを公開しています。 内容は最新の動向を随時反映しており、新たなコラムの追加も行っていきます。

2010年12月1日(水) ■ CNAME の間違った使い方 _ なんかわかりにくい書き方してるけど、よーするに CNAME を使うなら同じレコードに A とか MX とか SOA とかを共存させちゃダメ、ということ。まったくもって正しい。 _ 正しいんだが、ライブドアよ、おまえがゆーな。 _ ライブドアの独自ドメインブログが公然とRFC違反してる？この質問に対して「問題ないよ」という回答が出てるけど、これは回答者の誤りで、alfalfalfa.com というレコードにはとーぜん SOA や NS が存在してるので、さらに加えて CNAME を設定するのは明らかに違反。答える人が質問者よりレベルの低い Q&A サイトって…。 _ 2chのスーパーハカー様方は正しく即レスしてるようだ。 _ 初心者ではよくある間違いだけど、でもサービスとして他人に売ってるところでこれをやっちゃいかんだろ。上で

Google Public DNSが発表されていました。 「Official Google Blog: Introducing Google Public DNS」 本当は書籍執筆〆切に追われていて首が回ってないはずなのですが、あまりに面白そうなので思わず調べてしまいました。 これって、DNSキャッシュのクラウド化なのだろうと思います。 利点は？ 利点は「パフォーマンス向上」と「セキュリティ向上」の２つがあるようです。 パフォーマンス Performance Benefits http://code.google.com/intl/ja/speed/public-dns/docs/performance.html 原稿〆切がヤバくて、ざっと流し読みをしただけなのであまり自信がありませんが、どうも世界規模で運用して、世界的にQueryが多い所を優先的にキャッシュ更新しておくので、非常に効率が

現在、APNICが運用する逆引きネームサーバに障害が発生しています。 この障害によりJPNIC管理下でAPNICが逆引きを管理する IPv4アドレス空間の一部について、 APNICが運用する逆引きネームサーバが正しい応答を返さないため、 逆引きゾーンの名前解決に失敗する場合があります。 皆様に大変ご迷惑をおかけいたしますが、 APNICによる対応作業が終了するまで、 今しばらくお待ちいただきますようお願いいたします。 障害の影響を受けているアドレス空間 110.172.56.0/21 110.232.136.0/22 110.50.192.0/21 110.50.65.0/24 112.137.189.0/24 112.71.0.0/17 112.78.124.0/24 112.78.125.0/24 112.78.126.0/24 113.146.140.0/24 113.152.23.

digコマンドもnslookupコマンドも、ネームサーバに対して問い合わせを行い、その応答結果を表示するコマンドです。 両者の一番の違いは、digコマンドがネームサーバの応答を比較的そのまま表示するのに対し、nslookup コマンドは応答を加工して表示するという点です。 また、nslookupコマンドは実際に行いたい問い合わせ以外にもサーバに対して問い合わせを行い、場合によっては意図しない結果に見えることがあります。 nslookupコマンドはフルサービスリゾルバの挙動を前提に動作している部分があり、コンテンツサーバの挙動を知りたいときなどには向きません。このような場合はdigコマンドを使うことをお勧めします。 では、さっそく、digコマンドとnslookupコマンドの両方を使って、簡単な実行例を示してみましょう。いずれもjprs.co.jpのMXレコードをns1.jprs.co.jpに

2008年5月にリリースされたばかりの新しいDNSリゾルバ「Unbound」は、シンプルで高速に動作するうえに、話題となっているDNSキャッシュポイズニング攻撃への耐性も高いという特徴を備えています。（編集部） 株式会社 サードウェア 岩崎 登 2008/10/17 DNSとは、そしてUnboundとは UnboundはオランダのNLnet Labsが開発しているDNSキャッシュサーバ（DNSリゾルバ）である。2008年5月に正式版のバージョン1.0.0がリリースされ、BSDライセンスの下、オープンソースソフトウェアとして公開されている。 NLnet Lab.は、DNSコンテンツサーバ「NSD」の開発元としても知られており、開発元の信頼も高い。 インターネットでは、IPアドレスによって、アクセスするサーバ（ホスト）を特定している。IPアドレスとは、いわゆる郵便番号のようなもので、インターネ

What's New! 後日談 虚しきインターネットの宴 (中京大学評論誌 八事 No.22,Mar.20,2006) VISA問題 VISA問題の詳しい経緯(English only) VISA問題の簡単な解説 他の事例 消防庁 他の事例は追って報告(するかも、、、) '06/10/17現在、約5万JPドメイン(約78万JPドメイン中)をサンプリング調査してみると、107ドメインにNXDOMAINなNSレコードが存在しており、そのうち数個のJPドメインがいますぐハイジャック可能であることを把握しています。 JPRSの対応後もほとんど問題は解決しなかったため、危険そうなところについて直接あるいはIPAを通して連絡を進めています。 有益なリンク DNSの不適切な運用が生むドメインハイジャックの危険性について(E-ONTAP管理人) DNS(前野さん) 推奨 DNS/Security(前野

「Interop Tokyo 2008」において10日、DNS関係者に向けたコンファレンス「DNSの安定運用に向けて：基礎知識から最新対応策まで」が開催された。 今回の主要なテーマは、「健全な運用」。DNS（Domain Name System）はインターネットを支える重要な基盤技術のひとつだが、近年では悪用や妨害といった事件も目立つようになった。そのため、安定し、リスクの少ないDNS運用を行なうことがより強く求められるようになってきている。 ● キャッシュポイズニングのリスクは健在 DNSが抱えるリスクとして代表的なものがキャッシュポイズニングである。キャッシュポイズニングとは「毒入れ」とも呼ばれ、DNSを悪用するための代表的な手法として知られている。その動作原理は、キャッシュサーバーが出した問い合わせへの応答を偽造し、キャッシュサーバーに偽の情報を読み込ませて（利用者にとって有害な情報

2008年5月21日(水) ■ A3 1枚 _ /.j の トヨタ、パワーポイントとカラーコピー(プリント)を自粛のネタ。あれあれ、最近はパワポが多かったんですか。 このコメントにあるように、トヨタが作る資料は昔からずっと A3 一枚だと思ってたんだけど。っていうか、トヨタ社内だけじゃなくて関連会社だけじゃなくて、ぜんぜん関係ない相手にもその流儀を強要してると思ってたんだけど。 _ 何年か前、某ナントカ協会関連の仕事をしたんだけど、この協会の構成メンバーの多くがトヨタから出向で来てた人だった。ただし、そのナントカ協会の業務はあくまでトヨタの地元でやるイベントを動かすことであって、トヨタとも自動車業界ともまったく関係なく、むしろ公的な性格の強いものだった(官庁からの出向も多し)。なのに、協会の外注先(つまりわれわれ)が作る資料になぜか A3 1枚ルールが適用された。わしゃ協会との折衝も協会向

オランダNLnet Labsと米VeriSign、英Nomiet、スウェーデンKireiの4社は米国時間の20日、オープンソースのDNSサーバソフトウェア「Unbound 1.0」をリリースした。LinuxやFreeBSD、Mac OS XやSolarisなど多くのUNIX系OSに対応、BSD互換ライセンスの適用により自由な利用および再配布が可能。 Unboundは、ドメイン名とIPアドレスの相互変換 (名前解決) に用いられるDNS / キャッシュサーバソフトウェア。1980年代からUNIX系OSにおける事実上標準のDNSサーバとして利用されている「BIND (Berkeley Internet Name Domain)」の代替となるべく開発がスタート、IPv4/IPv6デュアルスタックのサポートなど新技術に対応するほか、パフォーマンスを重視した設計が行われている。 セキュリティ面では、

512bytesを越えるDNS queryもしくはreply messageはTCPにfallbackするんだけど、UDP 53をallowしてTCP 53をdenyしてると、当然名前解決ができない。そもそもTCPはoverheadがでかいので、message sizeは512bytesに納めるのが鉄則(yahoo.comのMXを引くと、authority sectionを入れても511bytes)。 じゃ、512bytes以内なら大丈夫かというと、落とし穴が。最近はMTAでTXT RRを参照することが多いからか、MXだけでなく他のRRも一緒に引こうとしてなのか、よくわからないけどANYでqueryを投げる実装があるらしい。MXだけならUDPで済むのに、ANYで引くと余裕で512を越えてしまってTCPにfallback、denyされてtimeout。「そんなでかいRRはない」とか油断してい