DNS問い合わせの可視化 | ある研究者の手記
DNS問い合わせの可視化 最近、データをまとめたり可視化したりしてその性質を調べる探索的データ分析(例)にはまっています。と、同時にネットワーク分析にもちょっと手を出しており、その2つの派生物としてドメイン名問い合わせの結果を可視化してみました。 これを読んでいる人にはもはや説明の必要はないと思いますが、一応書いておくと、世の中のwww.google.comやwww.amazon.co.jpのようなドメイン名はサーバの場所を直接示しているわけではなく、「この名前を持っているサーバのIPアドレスはなんですか？」というのをDNSサーバという別のサーバに問い合わせることで目的のサーバのIPアドレスを教えてもらい、その後目的のサーバへ接続します。以前は正引き（ドメイン名からIPアドレスを問い合わせる）と逆引き（IPアドレスからドメイン名を問い合わせる）が対称構造になるように設定するのが主流でしたが
Geekなぺーじ : Google Public DNSについて調べてみた
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が多い所を優先的にキャッシュ更新しておくので、非常に効率が
An Engineer's Guide to DNS (Yahoo! Developer Network Blog)
This article is the second in a series and part of ongoing research on web app performance. Get updates on the latest YDN articles via Twitter, follow @ydn. The Domain Name System (DNS) is part of the "dark matter" of the internet. It's hard to observe the DNS directly yet it exerts an obscure, pervasive influence without which everything would fly apart. Because it's so difficult to probe people
すべての基礎、マスター・ゾーンサーバの設定
すべての基礎、マスター・ゾーンサーバの設定：実用 BIND 9で作るDNSサーバ（2）（2/3 ページ） ゾーンファイルの作成 次に、/var/named下に/etc/named.confで記述したすべてのゾーンファイルを作成します。 named.ca キャッシュサーバとして動作するためには、ルートサーバがどこにあるのかを正しく知っておく必要があります。そのためのゾーンファイルをftp://ftp.rs.internic.net/domain/named.rootから入手し、/var/named/named.caとして保存します。 ルートサーバは不変であると思われがちですが、頻繁でないにしろ更新されることがあります。2002年11月にはDoS攻撃への対策から、5年ぶりにルートサーバに変更が加えられました。BINDはnamed起動時にルートサーバに接続し、自動的に最新のルートサーバ一覧情報に
JPRS DNS 関連技術情報
このページは DNS に関連する技術情報を提供するページです。 [ 最終更新：2024年03月21日 更新履歴はこちら] [ RSS ] ■ トピックス L4 グルーレコードについて改めて考える ～ランチのおともにDNS～(「Internet Week 2023」での発表資料[PDF]) DNSを用いたドメイン名の管理権限確認を使用する際の注意点(IETF 116 Host Equipment Demosでの配布資料[PDF]) Important Notes of Using Domain Name Ownership / Control Verification by DNS (Distributed on IETF 116 Host Equipment Demos[PDF]) L6 DNSの弱点を振り返り、今後の針路について考える ～ランチのおともにDNS～(「Internet We
DNS: 短いTTLのリスク
(Last Updated On: 2014年12月5日)TTLが短いとDNSキャッシュサーバがドメイン権限を持ったDNSサーバにクエリに行く機会が増える（当たり前ですがDNSキャッシュサーバはTTLで指定された時間だけレコード情報をキャッシュしてドメイン権限を持つDNSサーバにクエリしない）ので危険と言う話。1秒に一回キャッシュを更新するほうが1時間に一回キャッシュを更新するよりDNSキャッシュ汚染が行いやすくなる、という当たり前の事です。DNSキャッシュが汚染可能である事、その汚染の仕組みを知らない方には思いがけないリスク増加かもしれません。 7ページ目に記載されている数式だけではどれが何だか分かりませんが、Nはポート数を表しているはずです。ポートが固定されていると16^2の組み合わせしかない、と言う話は良く知られていると思います。DNSを管理している人なら誰でも知っていると思いますが
DNS Rebinding
Protecting Browsers from DNS Rebinding Attacks DNS rebinding attacks subvert the same-origin policy and convert browsers into open network proxies. These attacks can circumvent firewalls to access internal documents and services require less than $100 to temporarily hijack 100,000 IP addresses for sending spam and defrauding pay-per-click advertisers For information about defenses, please read our
DNSベストプラクティスとは「隠す」そして「重ねる」 ― ＠IT
第2回 DNSベストプラクティスとは「隠す」そして「重ねる」 澁谷 寿夫 Infoblox株式会社 Systems Engineer 2007/12/14 軽視されがちのDNSにもう一度明かりをともす新連載。第2回ではDNSの最新情報と、前回の最後で図だけ提示した「DNSのベストプラクティス」構成の意味を解説します（編集部） いまだに設定ミスの多いDNS 今回も引き続きDNSについて説明していきたいと思います。まずは、おさらいをかねて、2007年11月に発表されたDNS関係のリリースを紹介したいと思います。 11月19日に開催されましたDNS DAYでも話題に上がっていたのですが、いまだに多くのDNSサーバに設定ミスが多いという問題があります。設定ミスの内容としては、いくつかありますが、その中でも深刻な問題としてはオープンリゾルバのサーバになってしまっているというものです。 前回説明した「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://jprs.jp/tech/material/IW2002-DNS-DAY-morishita.pdf
DNS Day: JP DNS Updates