hatena.ne.jp ドメインのゾーンを AWS Route 53 に引っ越した話 - Hatena Developer Blog
こんにちわ、株式会社はてなのシステムプラットフォーム部で SRE をやっている id:nabeop です。この記事ははてなエンジニア Advent Calendar 2018 の14日目の記事です。昨日は id:Pasta-K でした。 今日は hatena.ne.jp ドメインのゾーンを AWS Route 53 に移設するにあたって、AWS 初心者がどんなことを考えながら移設したかという話です。DNS ゾーンの移設の手順などについては既に様々な情報があるので、そちらを参照してください。 そもそもの始まり 僕は2018年3月に はてな に中途入社しました。入社して1ヶ月くらいたった4月のある日、「ねぇ、hatena.ne.jp というゾーンを AWS Route 53 に移設してみない?」とタスクが降ってきました。時期としては中途入社後、業務のキャッチアップをしつつ、今まで触ったことがな
再定義できない世界になりつつあるネットの新秩序 - 雑種路線でいこう
個人でEV SSL証明書が欲しい話 - Speaker Deckを読んで驚いたんだけど、いつの間にかFirefoxにはEVSSL証明書のルート認証局がハードコーディングされて、それを書き換えるにはブラウザをビルドし直す必要があるらしい。（というかリビルドしても追加した証明書でアドレスバーが緑色にならなかったみたい。何が足りないのかな？）ルート証明書そのものは後から足せるのだが敢えてハードコードした理由は想像できる。ルート証明書なんて後から侵入者なりマルウェアが簡単に足すことができるし、現にそういった攻撃はこれまで行われてきたからだ。 ついでにFirefoxが近々DHCPで降ってくるDNSを信用するのを止めて、DNS over HTTPSでCloudflareに問い合わせるという。これもまたDNS履歴を監視する国だとか、日本も含めてWeb検閲のためにDNSをいじってる国があって、そういった影
DNS over HTTPSを使ってDNSレコードを外形監視 - LIVESENSE ENGINEER BLOG
こんにちは、インフラグループの水野です。 みなさん、DNSのレコードの監視を行っていますか？ DNSレコードの変更ミス等を検知することはもちろん、自分たちの運営しているサービスの名前解決がユーザ側でどのように見えているのかというのを確認することは大切です。 しかしながら、DNSレコードを外形監視してくれる監視ツールは数が少なく中々コレといったものがありません。 外部からの監視をしたいがためにパブリッククラウドに監視専用のインスタンスを建てるのももったいないです。 弊社ではメインの監視ツールとして Mackerel を利用していますが、MackerelにはURL外形監視はありますが、DNS外形監視はありません。 別途 pingdom のDNS外形監視を利用していましたが、pingdomではIPアドレスとのマッチしかできません。 IPアドレスもひとつしか登録できないため、ELBのようにIPアド
DNSの仕組みと調査方法について - embryo
仕事で外部のエンジニアに依頼したドメイン移行が正しく動作していなかったため、良い機会と思いDNSについて調べました。 名前解決の方法 そもそも名前解決とは何かというと、ドメインとIPアドレスを紐付けることです。手法として以下の2つが上げられます。 /etc/hostsに直接対応を記述する方法 /etc/resolve.confにDNSサーバーのIPアドレスを記述し、問い合わせる方法 今回はDNSサーバーによる名前解決について説明していきます。 DNSによる名前解決 ドメインツリーによる負荷分散 全世界に無数に存在するドメインの解決を一台のネームサーバーで担当するのは不可能です。そこでDNSでは下記のように、各階層に意味を持たせ、下位のドメインを管理させることで分散型の構造を構築しています。 ドメインツリー キャッシュサーバーによる高速化 クライアントからDNSサーバーに対してドメインを問い
F5 Networks Japan K.K. - 積極的な取り組みでサイトの安定性と信頼感No.1*を獲得
F5のサイト サポート ポータル F5製品およびサービスに関するセルフサービス ヘルプの記事 DevCentral 弊社主催のコミュニティでつながり、学ぶ My F5 サブスクリプションおよび登録キーの管理 Partner Central F5パートナーのためのリソースおよびサポート ポータル LearnF5 Learn to use F5 products F5へのお問い合わせ F5販売担当部へのお問い合わせ 詳しくは、F5の営業担当社にお問い合わせください F5サポートへのお問い合わせ お近くのサポート担当者にお問い合わせください プロフェッショナルサービスへのお問い合わせ F5ソリューションを最適化するためのサポートを受ける 無料トライアル 複数の環境にわたりアプリケーションの安全性、速度、信頼性を確保するこれらの製品を、無料でお試しください。 F5 Distributed Clou
BINDによるDNSサーバーの構築
※追記 2005/8/8：bind-9.3.1.tar.gzでも以下の説明で動作確認OK ■chroot 環境で動作させるための準備 仮にサーバーに侵入されたとしても、被害の拡大を最小限に抑えるために、named 専用のアカウントを用意し、jail 環境で動作させる設定を行います。まず、/etc/group に重複しないグループIDでnamed というグループを作成します。 次に、ユーザーの作成を行います。-d オプションをつけて、chroot させたいディレクトリを指定します。つまり、/var/named 以下が named の住居となり、これ以上、上位の階層へアクセスできなくなります。また、named ユーザーにシェルを提供しないよう、-s オプションを指定し、/bin/false とでもしておきます。
DNS over QUICの提案仕様が出た - ASnoKaze blog
2020/04/28 追記 仕様の名前が少々変わりましたが、WG Draftとなり作業は引き続き続けられています。 「Specification of DNS over Dedicated QUIC Connections」 QUICの標準化とアプリケーションレイヤ IETFでQUICの標準化が活発に行われており、トランスポート・TLS・HTTP各レイヤのドラフト仕様の改定が進められております。 標準化を行うにあたって当初より、DNSのトランスポートとしてQUICを使用したいという話題は出ていましたが、QUICワーキンググループのチャーターでは、まずはQUICのアプリケーションレイヤとしてHTTPの標準化を行ってから他のアプリケーションプロトコルについて進める旨書かれている。 とはいえDNS over QUICをやりたい人はいるようで、4/11にインターネットドラフトが出されている。共著者
facebookの13億ユーザーを支えるロードバランサーの話 - stanaka's blog
最近、SREが話題ですね。 tech.mercari.com www.wantedly.com ということでSREについて調べてたら、SREconなんてものが開催されていたので中を見てたら、「Building a Billion User Load Balancer」というタイトルでFacebookのDNS〜LBまでの話があったので、そのメモです。 Building a Billion User Load Balancer | USENIX tl;dr tinydns + IPVS で Facebook規模はいける httpsの接続確立はかなり重い(RTTの4倍 = RTT 150msとするとGETまで600ms)ので、太平洋越えとかは厳しい httpsを終端させるCDNとかは活用の可能性ありそう (国内だけを考慮するなら影響は軽微かも) メモ L4 LB shiv (IPVS + pyt
インターネット10分講座：DNSキャッシュポイズニング - JPNIC
今回の10分講座は、最近になって新たな攻撃方法が発見され、対応の緊急性が高まったDNSキャッシュポイズニングについて解説します。 DNSの問い合わせの流れ まずはじめに、DNSではクライアントがどのようにドメイン名の情報を得るのか、その流れについて説明します（図1）。 エンドユーザーのPCなどのDNSを利用するクライアントから、問い合わせを行うネームサーバに対し、問い合わせを依頼します。 依頼を受けたネームサーバは、問い合わせ内容を元に、ルートサーバから委任をたどりながら順に問い合わせを行い、目的のドメイン名情報を持つ権威サーバから結果を取得します。 依頼を受けたネームサーバは、問い合わせの結果をクライアントへ返答します。 図1：DNS 問い合わせ DNSのキャッシュ 問い合わせを処理するネームサーバは、処理の途中で得たドメイン名の情報を一時的にローカルに保存することができます。この処理を
JP WHOIS -JPRS
このWHOISサービスはJPRSが 提供するドメイン名登録情報検索サービスです。 ご利用にあたっては、以下の文書をご覧ください。 → JPドメイン名登録情報等の公開・開示に関する規則 → gTLD等ドメイン名登録情報等の公開・開示に関する規則 → JPRS WHOIS ご利用ガイド WHOISについての一般的な説明は「 Whoisとは？」をご覧ください。
LinuxはローカルにDNSキャッシュを持たないことを初めて知った - 元RX-7乗りの適当な日々
先日、とあるLinuxマシンをセットアップした時に、"apt-get upgrade"で最新のモジュールをダウンロード・更新していたところ、途中でモジュールがダウンロードできなくなってしまった。 調べてみると、通信はできるけど名前解決が出来ていないことが分かった。 で、しばらくすると名前解決が行えるようになり、ダウンロードが再開された。 Windowsでは暗黙で，Mac OS XではlookupdがDNS解決の結果をキャッシュしていますが，Linuxではキャッシュを行わず，都度DNSサーバへ問い合わせを行ってしまいます。 第20回 いろいろなキャッシュ：dnsmasq, cache proxy：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社 とのことなので、どうやら、小さいサイズ(数KB〜数十KB)のファイルを連続してダウンロードしていることで、DNSサーバに軽
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【図解】httpプロキシサーバの仕組み(http GET/https CONNECTメソッド)や必要性・役割・メリットデメリット・DNSの名前解決の順序
https://www.semanticscholar.org/paper/Public-DNS-system-and-Global-Traffic-Management-Huang-Maltz/78730413a28bf4102f1f28a5f460dcf677bd2a46?p2df