「アプリケーションエンジニアが知るべきDNSの基本」というタイトルで、builderscon tokyo 2018 で登壇するスライドです
![Basics_of_DNS_that_application_engineers_should_know - Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/31ef9f7c53124c11996287b581d11b8efe5024e9/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Ff53838df4f8b49efb9dc1970ae6b4695%2Fslide_0.jpg%3F10716851)
The Java virtual machine (JVM) caches DNS name lookups. When the JVM resolves a hostname to an IP address, it caches the IP address for a specified period of time, known as the time-to-live (TTL). Because AWS resources use DNS name entries that occasionally change, we recommend that you configure your JVM with a TTL value of no more than 60 seconds. This ensures that when a resource’s IP address c
tech_team 2018年7月10日 JPNICからのお知らせ インターネットの技術 ■ はじめに DNSにはEDNSと呼ばれる拡張機能があります。このEDNSの実装が正しくないDNSサーバやネットワーク機器が、インターネット上に存在しています。これまで、いくつかのオープンソースのDNSサーバソフトウェアでは、EDNSの動作に不具合があるようなサーバ等に対しても名前解決ができるように、回避策が実装されていました。しかし「実装が複雑になりDNSの安定運用にも支障をきたすため、2019年2月1日以降のリリースから回避策の機能を削除することにした」というアナウンスがありました。 機能削除の予定日である2019年2月1日は “DNS flag day” と名付けられました。この記事では、その DNS flag day についてご紹介します。 ■ EDNS (Extension Mechanis
ども、大瀧です。 AWSとオンプレミスのハイブリッド構成は、エンタープライズのAWS活用では定番となりつつあります。そんなAWSハイブリッド構成の設計でよく課題に挙がるのが、DNSです。このブログエントリーでは、使えるDNSサービスの種類とその特性をまとめ、いくつかの構成パターンを解説、比較してみます。 AWSハイブリッド構成とは AWSハイブリッド構成は、AWSでプライベートネットワークを構成するAmazon VPCとオンプレミスのネットワークを相互接続し、両方のサーバーリソースを組み合わせて利用するものです。VPCとオンプレミスとの接続は、プライベート接続として専用線 *1かインターネットVPN *2を利用します。 AWSハイブリッド構成で利用するDNSサービス DNSサーバーには権威サーバーとキャッシュサーバーの2種類がありますので、それぞれで利用できるサービス毎に並べてみました。[
1 JAPAN REGISTRY SERVICES JAPAN REGISTRY SERVICES Copyright © 2015 株式会社日本レジストリサービス ■「DNS サーバーの引っ越し」とは サービスプロバイダーやレジストラ(JP ドメイン名では 指定事業者)の変更に伴い、その対象となるドメイン名 の権威 DNS サーバーが変更されることを、「DNS サー バーの引っ越し(以下、引っ越し)」と呼ぶことがありま す。今回は引っ越しの中でも特に、 (A) すべての権威 DNS サーバーのホスト名と IP アドレ スが変更される (B) Webサーバーやメールサーバーなど、権威DNSサ ーバー以外のサーバーのホスト名は変更されず、 IP アドレスのみが変更される 場合について、作業時のトラブル発生を未然に防ぐ、 本来あるべき手順について解説します。 なお、以降では「引っ越し」を、上記
Route53のトラフィック乗っ取り AmazonのRoute53がトラフィック乗っ取りの被害に遭った、と聞くとぎょっとした人が多いのではないでしょうか。AWSの利用者は多いですからね。攻撃の仕組みについて解説します。 www.itmedia.co.jp AWSのクラウドベースのDNSサービスである「Route 53」のDNSトラフィックが何者かに乗っ取られ、「MyEtherWallet.com」のユーザーが仮想通貨を盗まれる事件が発生した。 解説 まず、この問題に関して利用された攻撃手法は「BGPハイジャック」という名前であることをおぼえてください。BGPとはネットワークの中で、ルーティング情報(経路情報)を交換するためのプロトコルです。BGPにて世界中のルーターが会話をすることによって、世界中どんなところにでも、インターネットがつながっていればパケットを届けることができるのです。例えば
DNSトラブルシューティング IIJ 山口崇徳 DNSの関係者(1) ユーザ レジストラ 参照サーバ ルートサーバ レジストリの 権威サーバ 権威サーバ ドメイン 所有者 委譲 委譲 DNS問い合わせ DNS問い合わせ ゾーン 設置 登録 登録 2 DNSの関係者(2) • なんかいっぱいいる… – それぞれ役割が異なる – それぞれの場所で固有のトラブルが発生しうる – どこでトラブルが起きているのか見極めるのが重要 • 自分はその中のごく一部にしか関われない – トラブルの原因は特定できても、それが自分では手の出せないところ にあることも多い • 原因となっているところが直してくれるまで、何もできずに眺めているしか できない – そんなわけで、問題の解決に至らず、原因の特定までで終わってしま うケースも多々あり • むしろその方がはるかに多いような気も… • このセッションの「DNSト
DNS Performance Analytics and Comparison Find the fastest and most reliable DNS for free based on millions of tests How we measure DNS Performance All DNS providers are tested every minute from 200+ locations globally. All tests are over IPv4 with a 1-second timeout. The public data is updated once per hour, but contact us for real-time data.
Connect to 1.1.1.1 using DoH clientsThere are several DoH clients you can use to connect to 1.1.1.1. cloudflaredDownload and install the cloudflared daemon. Verify that the cloudflared daemon is installed by entering the following command:
Introduction dnstap is a flexible, structured binary log format for DNS software. It uses Protocol Buffers to encode events that occur inside DNS software in an implementation-neutral format. Currently dnstap can only encode wire-format DNS messages. It is planned to support additional types of DNS log information. Support for dnstap is included in several DNS servers, including: Knot DNS as of ve
DNS サーバの挙動をテストする 準備 頑張ってテストケースを書く NS レコード SOA レコード その他の RR DNS サーバの挙動をテストする インフラの挙動をテストするためのフレームワークである infrataster という仕組みがあります。サーバ構築時のテストフレームワークは Serverspec が有名ですが、対象をインフラにしたものという乱暴な理解です。 で、インフラといえば DNS なんですが、僕は小心者なので DNS サーバの設定でしくじったりすると、被害が甚大なので、小さな修正でもドキドキしながらオペレーションをしています。また、設定直後はうまく動いているように見えて、実は他のエントリを書き換えてしまい後から障害になってしまう、ということも考えられます。まさに自分が自宅の内部ネットワークのメンテ時に凡ミスして一時的に名前解決ができなくなってツライ目にあってしまったの
Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service Loading... Cloudflare's mission is to help build a better Internet. We're excited today to take another step toward that mission with the launch of 1.1.1.1 — the Internet's fastest, privacy-first consumer DNS service. This post will talk a little about what that is and a lot about why we decided to do it. (If you're interested in
JVM (Java 仮想マシン) には DNS の名前解決の結果をキャッシュする挙動が備わっている。キャッシュするだけならいいのだけれど、このキャッシュでは DNS の TTL を無視してキャッシュするため、名前解決の結果が変わっても JVM からの接続先が切り替わるまでに(TTL から想定される時間以上に)時間がかかる、あるいは全く切り替わらないということがある。この挙動やその制御について調べたので、その話をする。 (以下の話題では Oracle JDK および OpenJDK を対象にして論じるので、それ以外の JVM 実装でどうなってるかは調べていない。適用できる箇所もあればそうでない箇所もありそう) 背景・解説 これらのデフォルト値は名前解決成功時は セキュリティーマネージャーがインストールされている場合のデフォルト値は -1 (ずっと) で、セキュリティーマネージャーがインストー
名前解決を行っているクライアントの国や地域によって、近い場所のサーバのIPを返すといったことは既に行われている。しかし、そのDNSによる負荷分散の方法は標準化されていない。 「DNS load balancing」という提案仕様では、新しくLBレコードを定義し、権威DNSサーバからフルリゾルバに対して負荷分散のための情報を伝達できるようにします。 日本の方が書かれている提案なので緊張感がありつつも、ざっと読んでみたので簡単に書く。 LBレコード LBレコードは、分散のための情報と重みと、分散先を示すを持つ 例えば # <owner> <ttl> <class> LB <weight> <location> <target> example.jp. 3600 IN LB 1 AP ap.example.com. example.jp. 3600 IN LB 1 JP jp1.example.
DNS History: Exploring Your Domain's Past by inspecting DNS trails What insights can DNS history reveal about domain names? As the term suggests, this record tracks all modifications to a domain’s DNS settings over time, offering invaluable information for both security and strategy. That’s why today we will explore the concept of DNS history, the type of DNS records involved, and the various tool
さきほど「DNSの浸透」に関して書いたのですが、それに対して「でもTTLを無視するDNSキャッシュサーバがいるから仕方がない」というような反応が一定数登場しています。 「浸透」の話になると、そのような話がほぼ必ず登場するのですが、実際に「この製品がTTLを無視する」とか「このISPで運営されているDNSキャッシュサーバはDNSプロトコルに違反している」という具体例をいまのところ見た事がありません。 「そういう困ったDNSキャッシュサーバも居るんだよ」とか「でもTTLを越えたあとも旧IPアドレスにアクセスあるもん」という感じの主張が多いです。 そんなところにsumikawaさんから以下のようなTweetを頂きました。 確かに、DNSの世界におけるTTL情報はアプリケーションには届かないので、権威DNSサーバのTTLを事前に小さくしたとしても、アプリケーションが持っているキャッシュは制御ができ
「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定
20181020更新 RFC8484として標準化されました 「DNS Queries over HTTPS」の仕様の標準化が始まっている。 今までもこのテーマはIETFにおいて何度か議論になってきましたが、今回 DNS Over HTTPS (doh) WGの設立に合わせて(まだProposed)、この「DNS Queries over HTTPS」の標準化がマイルストーンとなっている。 今回の「DNS Queries over HTTPS」は、Googleの提供しているDNS over HTTPSとは全然違う仕様である点は注意が必要です。GoogleのものはクエリとレスポンスをJson形式で構造化するが、今回は比較的素のDNSクエリをHTTPSで送り合う仕様である(今後JSON形式をサポートする可能性はあります)。 このプロトコルではHTTP/2を使う必要があります(MUST)。HTTP
DNS による名前解決のオーバヘッドを解決するために DNS キャッシュサーバを導入しても、その上流や権威サーバに対して問合せが頻繁にある場合、応答の遅延が発生する状況があります。 DNS による名前解決がボトルネックとなっている環境のチューニングについて考えるとき、キャッシュサーバのキャッシュにあるレコードの TTL が切れる前にキャッシュサーバが自動的にレコードを更新してくれる機能があれば解決しそうです。 多くのプロバイダでフルリゾルバとして導入されている unbound には prefetch の機能があります。 prefetch という名前からして、キャッシュにあるレコードの TTL が切れる前に unbound 自ら自動的にレコードを更新してくれそうです。 prefetch: <yes or no> (1.4.2-) yesのときには、キャッシュを最新に保つために期限切れにする前
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く