タグ

dnsに関するmather314のブックマーク (5)

  • DNS over TLS/HTTPSについて考える | IIJ Engineers Blog

    はじめに 昨年から DNS over TLS (DoT)、DNS over HTTPS (DoH) にまつわる動きが急速に活発になっています。 DoT は2016年に RFC7858 が出てしばらくは大きな動きはありませんでしたが、2017年11月にサービス開始した public DNS である Quad9 (9.9.9.9)、昨年4月開始の Cloudflare (1.1.1.1)が相次いで DoT に正式対応し、遅れて今年1月には Google Public DNS (8.8.8.8) も対応しました。クライアント側としては昨年8月リリースの Android 9 “Pie” が DoT に対応しています。 DoH は仕様の標準化より実装の方が先行しています。Cloudflare は DoT だけでなく DoH も昨年4月のサービス開始当初からサポートしています。Mozilla Fire

    DNS over TLS/HTTPSについて考える | IIJ Engineers Blog
    mather314
    mather314 2019/05/08
    わかりやすい解説
  • ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;

    先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座:DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co

    ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
  • .ioドメイン不調に伴うMackerelの死活監視アラートの誤報の発生とそれに対する対応について - Mackerel お知らせ #mackerelio

    Mackerelサブプロデューサーの id:Songmu です。表題の件、ユーザーの皆様には度々ご迷惑をおかけしており大変申し訳ありません。 件の詳細に関する説明と、今後の対応に関してお知らせいたします。 死活監視のアラート誤報に関して Mackerelでは、mackerel-agentから一定時間メトリック投稿が途絶えた事をもって、サーバーがダウンしたと判断し、死活監視アラートを発報する仕組みになっています。 現在、 mackerel.io ドメインの名前解決が不安定になっております。それに伴い、 mackerel.io ドメインの名前解決が一定期間失敗し、Mackerelへのアクセスが一時的にできない環境において、 mackerel-agent がMackerelへのメトリック投稿をおこなうことができず、Mackerelシステム側でサーバーがダウンしたと判断してしまい、死活監視のアラ

    .ioドメイン不調に伴うMackerelの死活監視アラートの誤報の発生とそれに対する対応について - Mackerel お知らせ #mackerelio
    mather314
    mather314 2017/09/22
    .io って信頼性は高くないのか…。 / “信頼性の高いTLDのドメインを新たに取得し、mackerel-agentはそちらのドメインを利用するように変更する予定”
  • なぜIPv6とIPv4の名前解決は別々に行なわれるのか?:Geekなぺーじ

    www.example.comなどの「名前」に対応するIPアドレスDNSサーバに問い合わせるとき、IPv4とIPv6に関する名前解決を単一の問い合わせで行うことはできません。そのため、DNSサーバに対して、IPv4に関する問い合わせと、IPv6に関する問い合わせを、別々に2度行う必要があります。 これは、DNSサーバに対しての問い合わせが単一のレコードに対してしか行えないためです。 Aレコード(IPv4アドレス)の問い合わせと、AAAAレコード(IPv6アドレス)の問い合わせは、それぞれ別々のレコードに対する問い合わせなので、両方を同時には行えないのです。 ただし、「IPv4とIPv6に関するDNSサーバへの問い合わせは別々に行わなければならない」というのは、事実上の話であって、「仕様上そうなっている」と言い切れるのかどうかは微妙かも知れません。 DNSに関するRFCは、悪名高いRFC

  • 強烈なDNSキャッシュポイズニング手法が公開される:Geekなぺーじ

    日、JPRSが緊急の注意喚起を公表しました。 緊急)キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について(2014年4月15日公開)- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう

  • 1