「実践DNS - DNSSEC時代のDNSの設定と運用 -」の献本を頂きました。 ありがとうございます。 私はDNSのことが良くわからなくて「勉強したい」と思いつつ色々調べてはいるのですが、DNSの情報がまとまって述べられている書籍が発見できずに困っているところだったので、非常に参考になりました。 これまで、通称「バッタ本」と呼ばれているDNS & BINDが最も詳しいDNS本だったと思うのですが、バッタ本はBINDの本であって、DNSの本ではありませんでした。 そういう意味で、「実践DNS」は、技術としてのDNSに関してキッチリ書いてある良書だと思います。 豪華な執筆陣 「実践DNS」は、DNSやDNSSECに関して日本国内で考え得る最高レベルの執筆陣によって執筆されていると思いました。 著者は3名とも「.jp」のJPドメイン名の登録管理業務とDNSの運用を行っている株式会社日本レジスト
--------------------------------------------------------------------- ■（緊急）BIND 9.xのネガティブキャッシュ機能の実装上のバグによる namedのサービス停止について - バージョンアップを強く推奨 - 株式会社日本レジストリサービス（JPRS） 初版作成 2011/05/27（Fri） 更新 2011/06/01（Wed） (ISC発表文書の更新を反映） --------------------------------------------------------------------- ▼概要 BIND 9.xのネガティブキャッシュの取り扱いには実装上のバグがあり、 namedのリモートからのクラッシュ（サービス停止）が可能であることが、 開発元のISCより発表されました。本脆弱性により、提供者が意図し
Products Iris Intelligence Platform The first place to go when you need to know. Iris Investigate Map connected infrastructure to get ahead of threats. Iris Detect Discover and monitor lookalike domains with unmatched speed and coverage. Iris Enrich Integrate DomainTools data with SIEM, SOAR, and other tools. Farsight DNSDB The world’s largest Passive DNS intelligence solution. DNSDB API Unlock th
DNS設定でフォワーダの構成を行う際の注意点があります。 ではそもそも、フォワーダの動作はどのようになるのか？ 通常DNSの動作としては、クライアントから再帰クエリとしてDNSサーバーが受け取ります。そして、DNSサーバーは目的のホストが見つかるまで反復クエリを繰り返して、最終的に権限のある応答として目的のホストアドレスを受け取ります。そしてクライアントへの応答してアドレスを返答します。 フォワーダの設定を行うと、DNSがクライアントと同じ動作を行います。よって、クライアントから再帰クエリを受け取り、それを再度DNSサーバーに再帰クエリとして送信します。 これは外部DNSと内部DNSを分離して、内部DNSにフォワーダの設定をするシナリオによく使用されます。 では設定画面を確認します。 ここで着目してほしい場所があります。それは「フォワーダが利用可能な場合にルートヒントを使用する」というチェ
本連載では，Windows 2000の利用を前提として，DNS（Domain Name System）をどのように展開すべきかに注力して解説する。DNSは，インターネットやTCP/IPネットワークにおける標準の名前解決方式として，従来から利用されてきた。しかし，従来のWindowsネットワークではNetBIOSを利用していたため，DNSを名前解決の手段としては利用していなかった。 すでに周知のとおり，Windows 2000では標準の名前解決方式としてDNSが採用されている。現在のWindowsネットワークを熟知している人でも，Windows 2000を導入するためには，まずDNSの知識を習得する必要がある。またWindows 2000は，既存のDNSサーバーではあまり利用されていないDynamic UpdateやSRVレコードの利用を前提としている。このため，従来のDNSにかかわる知識だ
概要 IPv4 アドレスが枯渇しヴァーチャルドメインが普及する現代では，DNSとWell Known Portで構成されるアプリケーションの通信にTLS証明書問題などの不都合が生じることが稀に良くある．DNSとportmapを組み合わせたような賢いサービスディスカバリーシステムを導入していたらスマートなインターネットができたのではないのか，という考察を思考整理を兼ねて行ってみる． DNS ドメイン名とIPアドレスを対応付ける仕組み．10.0.0.1 だとわかりにくいから www.yuyarin.net という名前を付ける．名前を「解決」するとIPアドレスが得られ，アプリケーションは解決で得られたIPアドレスを使って通信を行う． ドメイン名からIPアドレスを解決することを正引き，IPアドレスからドメイン名を解決することを逆引きという．正引きは違うドメインが同一のIPアドレスを指すことができる
規模の大小を問わず、ゾーンサーバは複数台で運用する必要があります。冗長化や負荷分散などさまざまな理由が挙げられますが、何よりドメインを取得してDNSサーバを運用するのであれば、サービスの品質を低下させないという自覚を持つ必要があります。 今回はスレーブ・サーバの運用と、そこで使用されるゾーン転送およびそのセキュリティについて見ていきます。 コラム スレーブ・サーバとセカンダリ・サーバ 本稿では、「マスター・サーバ」のゾーンデータを取得してDNS問い合わせに応答するサーバを「スレーブ・サーバ」と呼んでいます。 資料によっては、同様の意味で「プライマリ・サーバ」「セカンダリ・サーバ」が用いられる場合があり、その際「スレーブ・サーバ」はDNS問い合わせを他サーバへ転送し、自身はDNS再帰検索を行わないサーバを指す場合があります。本連載ではオリジナルとなるゾーンデータを所有するサーバを「マスター・
(Last Updated On: 2014年12月5日)TTLが短いとDNSキャッシュサーバがドメイン権限を持ったDNSサーバにクエリに行く機会が増える（当たり前ですがDNSキャッシュサーバはTTLで指定された時間だけレコード情報をキャッシュしてドメイン権限を持つDNSサーバにクエリしない）ので危険と言う話。1秒に一回キャッシュを更新するほうが1時間に一回キャッシュを更新するよりDNSキャッシュ汚染が行いやすくなる、という当たり前の事です。DNSキャッシュが汚染可能である事、その汚染の仕組みを知らない方には思いがけないリスク増加かもしれません。 7ページ目に記載されている数式だけではどれが何だか分かりませんが、Nはポート数を表しているはずです。ポートが固定されていると16^2の組み合わせしかない、と言う話は良く知られていると思います。DNSを管理している人なら誰でも知っていると思いますが
この中で、「クラス」にはいくつかの種類が存在しますが、「IN」（Internet） 以外を利用することはまずありません。また、リソースデータはタイプの違いにより複数の値が必要な場合があります。例えば「SOA」なら7つの値が、「MX」ならば2つの値が必要になります。 以下にBINDによるゾーンファイルの書き方を具体的に説明します。BIND以外の実装のネームサーバの場合は、ゾーンに含まれるデータは同じでもゾーンファイルの書き方は異なるものとなりますので、注意してください。 example.jp のゾーンファイルを例2に示します。example.jp.で始まる行がヘッダに当たる部分で、それに続いてns1.example.jp.等のexample.jpドメインに属する情報が記載されています。 この例ではリソースレコードが省略なくすべて記載されています。実際に管理者が作成するゾーンファイルではもっと
DNSキャッシュポイズニングの本質的な問題点 DNSキャッシュポイズニングの本質的な問題点は、利用可能なトランザクションIDの総数が16ビット（65536）であるDNSのプロトコル仕様が、時代の変遷により貧弱となってしまったことにあります。DNSの仕様が確定した時代、コンピュータの性能がいまよりずっと貧弱な時代では、確かにこのような仕様でも十分だったのかもしれません。 しかし、コンピュータとネットワークの性能が飛躍的に向上したことは誰の目にも明らかで、近所の家電量販店で20年前のスーパーコンピュータ以上の性能を持つパソコンや、当時では考えられなかったGigabit Ethernet機器を手軽に買えるようになり、そして100Mbpsの超高速なインターネット接続環境が普及した現在では、現状のDNSプロトコル仕様が貧弱になってしまった事実は否めません。 とはいえ、ここでDNSプロトコルの仕様を拡
ブラウザでサイトを開いた時に、DNSがどうやって働いているかという仕組みを解説した動画です。 問い合わせのキャッシュとかについては触れてません。なので一般向けに理解してもらおうという企画かなと思いました。ヨーロッパのTLDレジトリが構成するCENTRによる啓蒙動画でした。 動画とは直接関係ないけれど、こういうはっきりした英語の動画だと、YouTubeで動画の下の[CC]メニューから「音声を文字に変換」を選ぶことで、それなりに英語の文字起こしをしてくれますし、さらに[キャプションを翻訳]すると、それをGoogle翻訳で翻訳してくれるので、便利になりましたねえ。日本語翻訳まですると、内容はかなり本来喋っていることから外れてしまうこともありますけど、それであっても。
他のキャッシュサーバのキャッシュに載ってしまったデータは、コンテンツサーバ側ではどうしようもない。 キャッシュサーバ側で消すには namedを再起動する。 rndc flush(BIND9.2.0で機能追加) rndc flushname name(BIND9.3.0で機能追加) rndc flushでnegative cacheに載った情報も消えた。 rndc flushnameで対象の名前を指定してもnegative cacheは消えなかった。 BIND9.3.0で実験
インターネット上で運用されているDNSサーバの中には、管理されていない状態のものがあります。ドメイン情報に偽の情報を記述させることで、第三者がそのドメイン名の持ち主であるかのようにふるまえてしまう（ドメインの乗っ取り）というものです。 ドメイン名のDNSサーバとして外部のドメイン名を持つホストを登録している場合、状況によってはドメインが乗っ取られてしまいます。このような状態は、セカンダリDNS サーバの廃止や委託業者の変更などの理由によるドメイン情報の管理不手際により、発生します。 ドメインの乗っ取りが行われた場合、以下の危険性があります。 外部に向けて運用されているDNSサーバの中には、セカンダリDNSサーバの廃止や委託業者の変更などの理由により、ドメインの乗っ取りが(*1)可能な、危険な状態で放置されているものがあります。 DNS サーバに登録し公開している情報において、外部のドメイン
DNS DNS Cache Poisoningの概要と対処 (Dan KaminskyによるDNS脆弱性指摘に関して) 23rd Jul 2008 Updated 19th Aug 2008 NTT情報流通プラットフォーム研究所 豊野 剛 toyono@nttv6.net Information Sharing Platform Labs. NTT 1 はじめに はじめに • この文書の目的 – 2008年7月22日に漏洩，8月7日に公開されたDNS脆 弱性攻撃手法に関して概略的に述べたものです • 問題点と影響度 • 対処方法 – 攻撃手法に関しては説明していません – BlackHat2008の資料が公開されたため附記 (8/7) • 多くのWebサイト上で技術的な解説がされています • 各種の攻撃ツールが出回っています Information Sharing Platfor
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く