[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

タグ

BINDに関するyhira0202のブックマーク (33)

  • BINDの脆弱性対応についての動きまとめ - infragirl’s blog

    おはこんばんにちは。ナツヨです。 いつか、脆弱性対応についての記事を書こうと思っていたら、BINDさんがまた 脆弱性を発表してくれました。(CVE-2015-8704,CVE-2015-8705) 前回の発表から1ヶ月も立っていないのに、流石BINDさんだなぁと思いました。(遠い目) 今日は、BINDに焦点をあてて、脆弱性対応とはどういうことが必要なのかまとめていこうと思います。すでに日常的に脆弱性対応されている方というよりは、「なんかしらんけどDNSサーバの管理者になっていた。とりあえずBINDというソフトウェアで動いていることは知っている」という方向けだと思います。 1.BINDの脆弱性の発表をキャッチする BINDの脆弱性について、世の中で一番早く発信するのはBINDのサポートを行っているISC家(BIND | Internet Systems Consortium)だと思います。

    BINDの脆弱性対応についての動きまとめ - infragirl’s blog
  • (緊急)BIND 9.10.xの脆弱性(DNSサービスの停止)について(2014年6月12日公開)

    --------------------------------------------------------------------- ■(緊急)BIND 9.10.xの脆弱性(DNSサービスの停止)について(2014年6月12日公開) - キャッシュ/権威DNSサーバーの双方が対象、バージョンアップを強く推奨 - 株式会社日レジストリサービス(JPRS) 初版作成 2014/06/12(Thu) --------------------------------------------------------------------- ▼概要 BIND 9.10.xにおける実装上の不具合により、namedに対する外部からのサー ビス不能(DoS)攻撃が可能となる脆弱性が、開発元のISCから発表されまし た。脆弱性により、提供者が意図しないサービスの停止が発生する可能性 があります。

    yhira0202
    yhira0202 2014/06/13
    恒例のBIND祭り。このビッグウェーブに乗り遅れない。
  • DNS トラブルシューティング

    yhira0202
    yhira0202 2013/11/16
    必読だわな。
  • (緊急)BIND 9.xの脆弱性(DNSサービスの停止)について(2013年6月5日公開)

    --------------------------------------------------------------------- ■(緊急)BIND 9.xの脆弱性(DNSサービスの停止)について(2013年6月5日公開) 株式会社日レジストリサービス(JPRS) 初版作成 2013/06/05(Wed) --------------------------------------------------------------------- ▼概要 BIND 9.xにおける実装上の不具合により、namedに対する外部からのサービ ス不能(DoS)攻撃が可能となる脆弱性が、開発元のISCから発表されました。 脆弱性により、提供者が意図しないサービスの停止が発生する可能性があ ります。 該当するBIND 9.xを利用しているユーザーは関連情報の収集、緊急パッチの 適用など、適切

  • dns-memo.info - 

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

  • 歪Blog: bind queryログの意味

  • Ghost Domain 脆弱性まとめ

    Yasuhiro Morishita @OrangeMorishita RT @hdais: やれやれ、こういうことをよく思いつくなぁ。ある意味「浸透問題」の応用問題だよね Ghost Domain Names: Revoked Yet Still Resolvable: http://t.co/yURxlsWu Yasuhiro Morishita @OrangeMorishita というわけで、影響はBIND 9のみにとどまらず、ちょっと古いUnbound、PowerDNS recursor、Windows server 2008のDNSサービス、djbdns(dnscache)など、広い範囲に及ぶ模様。 Yasuhiro Morishita @OrangeMorishita 論文を斜め読みした限りでは、件の脆弱性の悪影響は「上位ゾーンがそのゾーンに対する委任を消したとしても、当該ゾー

    Ghost Domain 脆弱性まとめ
  • 「DNS浸透問題」は脆弱性だった!「幽霊ドメイン名脆弱性」:Geekなぺーじ

    「浸透いうな!」という掛け声が一部界隈で有名な「DNS浸透問題(もしくは、DNS浸透いうな問題)」ですが、今年2月にDNS浸透問題の原因の一つとなっている現象と同じものに起因する新たな脆弱性が発表されました。 その名は「幽霊ドメイン名脆弱性(ghost domain names)」です。 一見、DNS浸透問題とは全く別の問題のように思える「幽霊ドメイン名脆弱性」ですが、それが発生する原因と状況をよく見ると、「あ!これってDNS浸透問題で言ってた話と同じ原因だよね!?」とわかります。 実際、後述する通り、幽霊ドメイン名脆弱性の発想をDNS浸透問題と組み合わせることで、他人のDNS引っ越しを妨害するDoS攻撃も可能になります。 そう考えると、問題発生原因を調べずに「DNSの浸透をお待ち下さい」で済ませてしまうのは脆弱性の放置であるという考え方もできそうです(*1)。 ここでは、幽霊ドメイン名脆

  • キャッシュDNSサーバーには lo を

    キャッシュDNSサーバーと権威DNSサーバーは分離すべきだが、IPアドレスが「1つしかない」場合は 127.0.0.1 や ::1 的なものが使えるよ、というおはなし

    キャッシュDNSサーバーには lo を
  • Japanese version of notice for CVE-2011-4313 | Internet Systems Consortium

    BIND 9キャッシュサーバがquery.cでエラーログを出してクラッシュする インターネット上の複数の組織から、BIND 9のキャッシュサーバが再起問い合わせの処理中にクラッシュして停止するという報告がありました。影響を受けるサーバはquery.c(ソースファイル) において以下のメッセージをログに出力した後にクラッシュしています: "INSIST(! dns_rdataset_isassociated(sigrdataset))" 報告によれば、現在サポートされているすべてのリリースバージョンを含む複数のバージョンが影響を受けています。ISCでは全力を挙げて原因の究明にあたっており、また、クラッシュを回避するパッチをを作成しました。さらに詳しい情報は得られ次第ご報告します。 CVE: CVE-2011-4313 文書バージョン: 1.1 公開日付: 2011年11月16日 影響を受ける

  • livedoor Techブログ : CNAMEの間違った使い方

    情報環境技術研究室の永井です。 今日はDNSのCNAMEの間違った使い方のお話です。 その間違った使い方がうちのサービスで使用されているかもっ!? DNSって? Domain Name System(ドメイン ネーム システム、DNS)はインターネットを使った階層的な分散型データベースシステムである。 1983年に情報科学研究所 (ISI) のポール・モカペトリスとジョン・ポステルにより開発された。 Wikipediaより一部抜粋 http://ja.wikipedia.org/wiki/Domain_Name_System 例えば、ライブドアのポータルサイトといえば「http://www.livedoor.com/」ですが、実際には「http://125.6.172.15/」というIPアドレスがインターネット上の住所になります。でも、こんな数字の羅列を一々覚えていられないので、DNSとい

  • サバカン日記+::allow-queryのかしこい使い方

    bind-usersネタですけど、自分も投稿者と同じような状況にあったのにスルーしてた部分で、うまいworkaroundが紹介されてたので書いときます。 bindの9.4.1-P1以降、デフォルトで再帰問い合わせとキャッシュ応答が拒否になり、バージョンアップのときにあたふたした記憶があります。 そんで、allow-recursionは前からあるけど、allow-query-cacheという便利なオプションができました。 allow-recursionで再帰問い合わせを受け付ける問い合わせ元の制限ができ、allow-query-cacheでキャッシュを持ってたら返答してあげる問い合わせ元の制限ができます。 ただ、allow-query-cacheはそれ以前のバージョンでは存在しないので、その場合はキャッシュの応答を防げません。 たとえば、再帰問い合わせを許可している内部のクライアン

  • http://www.ssken.gr.jp/MAINSITE/download/wg_report/info-secmng/dns/dns.pdf

  • bind 9.4 - TenForward

    bind 9.4 の recursion allow-query allow-query-cache allow-recursion 辺りの関係がイマイチ... マニュアルに Specifies which hosts are allowed to get answers from the cache. If allow-query-cache is not set then allow-recursion is used if set, otherwise allow-query is used if set, otherwise the default (localnets; localhost;) is used. ってあるけど,allow-query-cache 設定しなくて allow-recursion とか allow-query 設定していても,その値が allow-que

    bind 9.4 - TenForward
  • BIND 9.4 の問い合わせの制限について

    BIND 9.4.2 をいじってて,気になったことについてのメモ. その気になったことというのは,allow-query サブステートメントなどを設定していない状態にもかかわらず,localnets; localhost; からの問い合わせにしか応答しないということについてだ.allow-query サブステートメントを設定していなければ,デフォルト値は any; になるので,どこからの問い合わせでも応答するはずなのだ. うだうだと調べていたら,BIND 9.4 から allow-query-cache サブステートメントというものが追加され,それに伴って allow-recursion のデフォルト値が変更されたからということがわかった.いままでは,allow-recursion のデフォルト値は any; であったが,9.4 からはデフォルト値が複雑になったのだ.表にまとめてみたので,

    BIND 9.4 の問い合わせの制限について
  • (緊急)BIND 9.xのネガティブキャッシュ機能の実装上のバグによるnamedのサービス停止について

    --------------------------------------------------------------------- ■(緊急)BIND 9.xのネガティブキャッシュ機能の実装上のバグによる namedのサービス停止について - バージョンアップを強く推奨 - 株式会社日レジストリサービス(JPRS) 初版作成 2011/05/27(Fri) 更新 2011/06/01(Wed) (ISC発表文書の更新を反映) --------------------------------------------------------------------- ▼概要 BIND 9.xのネガティブキャッシュの取り扱いには実装上のバグがあり、 namedのリモートからのクラッシュ(サービス停止)が可能であることが、 開発元のISCより発表されました。脆弱性により、提供者が意図し

    yhira0202
    yhira0202 2011/05/27
    職場を出た後に気づいたよ。どーすんのよ!
  • DNS: 短いTTLのリスク

    (Last Updated On: 2014年12月5日)TTLが短いとDNSキャッシュサーバがドメイン権限を持ったDNSサーバにクエリに行く機会が増える(当たり前ですがDNSキャッシュサーバはTTLで指定された時間だけレコード情報をキャッシュしてドメイン権限を持つDNSサーバにクエリしない)ので危険と言う話。1秒に一回キャッシュを更新するほうが1時間に一回キャッシュを更新するよりDNSキャッシュ汚染が行いやすくなる、という当たり前の事です。DNSキャッシュが汚染可能である事、その汚染の仕組みを知らない方には思いがけないリスク増加かもしれません。 7ページ目に記載されている数式だけではどれが何だか分かりませんが、Nはポート数を表しているはずです。ポートが固定されていると16^2の組み合わせしかない、と言う話は良く知られていると思います。DNSを管理している人なら誰でも知っていると思いますが

    DNS: 短いTTLのリスク
  • http://jprs.jp/tech/material/IW2002-DNS-DAY-morishita.pdf

  • @IT:DNS Tips:ゾーンファイルの書き方について教えてください

    この中で、「クラス」にはいくつかの種類が存在しますが、「IN」(Internet) 以外を利用することはまずありません。また、リソースデータはタイプの違いにより複数の値が必要な場合があります。例えば「SOA」なら7つの値が、「MX」ならば2つの値が必要になります。 以下にBINDによるゾーンファイルの書き方を具体的に説明します。BIND以外の実装のネームサーバの場合は、ゾーンに含まれるデータは同じでもゾーンファイルの書き方は異なるものとなりますので、注意してください。 example.jp のゾーンファイルを例2に示します。example.jp.で始まる行がヘッダに当たる部分で、それに続いてns1.example.jp.等のexample.jpドメインに属する情報が記載されています。 この例ではリソースレコードが省略なくすべて記載されています。実際に管理者が作成するゾーンファイルではもっと

  • キャッシュの消し方

    他のキャッシュサーバのキャッシュに載ってしまったデータは、コンテンツサーバ側ではどうしようもない。 キャッシュサーバ側で消すには namedを再起動する。 rndc flush(BIND9.2.0で機能追加) rndc flushname name(BIND9.3.0で機能追加) rndc flushでnegative cacheに載った情報も消えた。 rndc flushnameで対象の名前を指定してもnegative cacheは消えなかった。 BIND9.3.0で実験