Basics_of_DNS_that_application_engineers_should_know - Speaker Deck「アプリケーションエンジニアが知るべきDNSの基本」というタイトルで、builderscon tokyo 2018 で登壇するスライドです
ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
.ioドメイン不調に伴うMackerelの死活監視アラートの誤報の発生とそれに対する対応について - Mackerel ブログ #mackerelio
Mackerelサブプロデューサーの id:Songmu です。表題の件、ユーザーの皆様には度々ご迷惑をおかけしており大変申し訳ありません。 本件の詳細に関する説明と、今後の対応に関してお知らせいたします。 死活監視のアラート誤報に関して Mackerelでは、mackerel-agentから一定時間メトリック投稿が途絶えた事をもって、サーバーがダウンしたと判断し、死活監視アラートを発報する仕組みになっています。 現在、 mackerel.io ドメインの名前解決が不安定になっております。それに伴い、 mackerel.io ドメインの名前解決が一定期間失敗し、Mackerelへのアクセスが一時的にできない環境において、 mackerel-agent がMackerelへのメトリック投稿をおこなうことができず、Mackerelシステム側でサーバーがダウンしたと判断してしまい、死活監視のアラ
はじめてさわる人のためのDNS（ドメインネームシステム）入門 - Suikolog
ご注意（2019年10月17日追記） この記事に紹介されているDNS「DOZENS」ですが、2019年10月末日をもってサービスを終了します。「ムームードメイン」や「お名前.com」「Google Domains」といったサービスの中で使えるDNSや、AWSの「Amazon Route 53」といったサービスのご利用をご検討ください。 基本的にレコードの設定方法はここで紹介されているものとほぼ共通していますので、設定の参考になさってください。 あなたはDNS（ドメインネームシステム）の設定をさわったことはありますか？ 私のようなウェブデザイナーであっても、制作するサイトをホスティングするサーバやサイトの独自ドメインを用意・手配するとなると、その設定は避けては通れないところです。今回は「黒い画面なんてムリムリ」「サーバ周りのことはできるだけ触りたくない」そんなあなたに、DNS設定の入り口に立
The Performance of Open Source SoftwareHigh Performance Networking in Chrome
The Performance of Open Source Software High Performance Networking in Chrome Ilya Grigorik History and Guiding Principles of Google Chrome Google Chrome was first released in the second half of 2008, as a beta version for the Windows platform. The Google-authored code powering Chrome was also made available under a permissive BSD license–also known as the Chromium project. To many observers, this
ソーシャルメディアの読み込みはDNSプリフェッチのまとめ設定がお得 | ゆっくりと…
zenback の読み込みコードが非同期化され、かつ 平均20%+の速度アップが図られた そうで、ユーザーとしては嬉しい限りです。 zenback に限らずソーシャルメディアの導入は、必然的に外部サービスを多用することになります。どのサービスも、スクリプトや画像、トラッキング用コードなどのリソースを、その特性に合わせて 2〜4 程度のホスト／ドメインに分散させているのが普通です。 こういった分散化は並列に読み込みめるリソース数を増やし、クッキーのあり／なしを区別できるので高速化に寄与します。が、利用するサービス数が多くなると、いわゆる「DNS ルックアップ」にかかる時間が無視できなくなり、さすがにデメリットの方が目立ってきます。 例えば本サイトの場合、最終的に25以上の異なるホスト／ドメインから 有象無象 のリソースを読み込んでいるのですが、「DNS ルックアップ」の合計だけで1秒を超える
One Step Ahead: Improving Performance with Prebrowsing
We all want our websites to be fast. We optimize images, create CSS sprites, use CDNs, cache aggressively, and gzip and minimize static content. We use every trick in the book. But we can still do more. If we want faster outcomes, we have to think differently. What if, instead of leaving our users to stare at a spinning wheel, waiting for content to be delivered, we could predict where they wanted
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Understanding DNS with ActionDispatch::HostAuthorization