タグ

DNSに関するrarereのブックマーク (10)

  • 総務省|報道資料|DNSの世界的な運用変更に伴うキャッシュDNSサーバーの設定更新の必要性

    この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ICANN(Internet Corporation for Assigned Names and Numbers)が、DNS(ドメインネームシステム)において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵(ルートゾーンKSK)の更改を実施します。 総務省では、ICANNからの依頼を受けて、内閣サイバーセキュリティセンターの協力の下、国内関係者への周知を実施しております。 この度、インターネットの重要資源の世界的な管理・調整業務を行う団体ICANN(Internet Corporation for Assigned Names and Numbers)が、DNS(ドメインネームシステム)において電子署名の正当性を検証するために使う暗号鍵の中で最上位となる鍵(ルートゾーンKSK)の更改を実施します。 これに伴い

    総務省|報道資料|DNSの世界的な運用変更に伴うキャッシュDNSサーバーの設定更新の必要性
    rarere
    rarere 2017/07/23
  • bind queryログの意味

    bind queryログの意味
    rarere
    rarere 2014/10/27
  • GeekなページさんのDNS関連の記事がわかりやすかったのでまとめた - Humanity

    Geekなぺーじ:なぜ「DNSの浸透」は問題視されるのか Geekなぺーじ:「DNSの浸透」とアプリケーションのキャッシュ すごくわかりやすかったので、すごく簡潔すぎて自分にしか分からないかもしれないまとめ記事書いてみる。 「Geekなページさん」と敬称をつけるかつけないか、 「あきみちさん」と呼べる程親しい間柄ではないし・・・と小一時間悩みました。 まず上の記事を読んだ後、コメント欄にDNS pinningという単語が見えたので調べてみた。 調べた結果、自分の結論もコメント欄のtssさんの意見と同じものになった。 そもそもDNS pinning が必要なWebのセキュリティモデル自体がおかしい。 Geekなぺーじ:なぜ「DNSの浸透」は問題視されるのか (6) 2行でまとめると DNSサーバはTTLを無視しない、ってかそんなサーバ見たことねーよ しかしアプリケーションレベルではTTLが無

    GeekなページさんのDNS関連の記事がわかりやすかったのでまとめた - Humanity
  • DNS Summer Days 2014

    DNS Summer Days 2014 ※2日目である6月27日(金)は12:30開始となりました ※懇親会の情報を掲載しました ※1日目チュートリアルの資料を掲載しました。紙資料の配布はありませんので事前にダウンロードのほどお願いします。 ※2日目ワークショップの資料を掲載しました 開催趣旨 インターネットの基盤技術の一つであるDNSは、重要性がますます高まっている にもかかわらず、その運用には十分な関心が払われておらず、また必要な予算や 人材などもきちんと割り当てられているとは言えない状況が継続しています。 また、プロトコルそのものやRFC等の技術文書のわかりにくさや、実装による違 い、セキュリティ面での課題と負荷が大きいことも相まって、DNSに対してきち んと取り組み運用している技術者の数も少ないのが現状です。 このようなDNSの状況に鑑みて、今年も昨年・一昨年に引き続き2日間のD

  • 名前解決のタイムアウト設定 - 揮発性のメモ2

    resolv.confにオプションが書けることが判明 timeout:n 「レゾルバが他のネームサーバで問い合わせをリトライする前に、 リモートネームサーバからの応答を待つ時間」を設定する。 単位は秒で、デフォルトは RES_TIMEOUT である (現状では 5 秒、 を参照)。 attempts:n 「レゾルバが諦めて呼び出し元のアプリケーションにエラーを返すまでに、 ネームサーバに問い合わせを行う回数」を設定する。 デフォルトは RES_DFLRETRY 回である (現状では 2 回、 を参照)。 Man page of RESOLV.CONF つまり、タイムアウト時間×リトライ回数 という式になるのでデフォルトは5×2=10秒が最大待ち時間 $ time ping uuu.com ping: unknown host uuu.com real 0m10.029s user 0m0.

    名前解決のタイムアウト設定 - 揮発性のメモ2
    rarere
    rarere 2014/06/17
  • 「魔法の数字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に対する私の感想 まず最初に。 調査前

    rarere
    rarere 2014/06/17
    今でも変わってないんだろうか
  • (緊急)BIND 9.10.0の脆弱性(DNSサービスの停止)について(2014年5月9日公開)

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

  • 第1フラグメント便乗攻撃を(僕が)成功させられない理由 - 仙豆のレシピ

    以前、第1フラグメント便乗攻撃についてのエントリを書きましたが、そのエントリではUDPチェックサムをうまくあわせることができず最終的に毒入れを成功させることができませんでした。その後いろいろアドバイスをいただいたりしてチェックサムをあわせようと努力しましたが、(僕程度のレベルでは)やっぱり無理 or 超難しくね…?という結論に達したので、その辺のことを書いておきたいと思います。 (2014/5/7)場合によっては攻撃が成功しやすくなる可能性があることがわかったので追記しました。 問題整理 そもそもなにがうまくいかないのかを整理。 第1フラグメント便乗攻撃ではDNS応答の第2フラグメントを偽装しますが、その第2フラグメントのペイロードはどんなものでもいいわけではなく第1フラグメントのUDPヘッダ内のチェックサムと整合性がとれている必要があります。このため、偽装する第2フラグメントのペイロード

    第1フラグメント便乗攻撃を(僕が)成功させられない理由 - 仙豆のレシピ
  • The story of Basecamp’s disastrous policy

    The story of Basecamp’s disastrous policy Basecamp’s CEO published a blog post about policy changes — it may have broken the company On April 26th, Basecamp founder and CEO Jason Fried posted on his blog about some policy changes that would be happening at the company, which makes team collaboration software. One policy stuck out to many on the internet — the company would no longer be allowing it

    The story of Basecamp’s disastrous policy
    rarere
    rarere 2014/04/22
  • DNS - JPNIC

    DNSは、ドメインネームシステム(Domain Name System)の略で、 インターネット上の名前であるホスト名(ドメイン名)と、 インターネット上の住所であり、 数字で構成されるIPアドレスとを対応づける仕組みです。

  • 1