https://yuru-sre.connpass.com/event/317749/ の LT 資料です
不要な DNS リソースレコードは消そう / Delete unused DNS records
https://yuru-sre.connpass.com/event/317749/ の LT 資料です
HTTPSレコードがRFCになりました | IIJ Engineers Blog
RFC9460が出ました 昨年、このエンジニアブログでHTTPSレコードについてとりあげました。これを書いたときはHTTPSレコードはまだインターネットドラフトだったのですが、2023年11月、ついにRFC9460として標準化されました。 RFCにはなったけど日本語の詳しい記事はまだ少ないし需要あるかなーと思って改めて解説を書きはじめたんですが、だらだらとクソ長くなって書いた本人が読んでも眠くて退屈な内容になってしまいました。ので、書いたものはばっさり捨てました。 そういえばいまから3年前、DNS Summer Day 2021で発表したプレゼン資料がありました。これをRFCになった現在の内容にあわせてアップデートしたほうがてっとりばやいしわかりやすそうです。 ということで、加筆修正した資料を置いておきます。DNS屋さんはとりあえず全部読んでおいてください。Web屋さんは前半だけ理解してお
どうしてもドメインを永久保持できない企業向け 企業はどうドメインを捨てるべきか - Web > SEO
コロナ禍中に取得された地方自治体のドメインがオークションで高値売買され、中古ドメインとして悪用されるなど、公的機関のドメイン放棄問題が注目されています。 11月25日のNHKニュース7でドメイン流用の件が報じられました。私も取材を受け少しご協力をしています。 www3.nhk.or.jp 公的機関のドメイン放棄問題の理想の解決は、今後は lg.jp、go.jp などの公的機関しか使えないドメインだけを使うようにすることです。 ただ今回の問題はコロナ禍初期の大混乱時、非常にスピーディにサイト立ち上げが求められていた時の話です。 信頼が求められる lg.jp などのドメインの利用には厳格なルールがあるのも当然です。あの混乱時期にルール改定も難しかったと思います。新規ドメインが選ばれた事は仕方がない事と思っています。 ただ、コロナ禍が落ち着いた今、無責任に放棄されるのは明らかな問題です。 今回の
Project Googrename: Google Workspace で 14 年運用されたドメインエイリアスをプライマリドメインに変更 & 全ユーザーを安全にリネームする - クックパッド開発者ブログ
コーポレートエンジニアリング部の id:sora_h です *1。今回は 3 ヵ月ほど前に実施した、Google Workspace テナントのプライマリドメイン変更について、記録を兼ねて説明します。 クックパッドは 2009 年頃 *2 より Google Workspace *3 を利用しています。当社の対外的なメールアドレスは cookpad.com ですが、Google ではプライマリドメインとして cookpad.jp が設定されています。各ユーザーには cookpad.com のアドレスを別名 (エイリアス) として登録されていて、メールアドレスとしては cookpad.com を利用、ただ Google へログインする時だけ cookpad.jp を利用する運用になっていました。想像が出来ると思いますが、これが様々な面で不便・混乱を発生させていました。どうしてこうなった… *
1.1.1.1：パブリックDNSへのブロッキング命令に抗うCloudflare | p2ptk[.]org
1.1.1.1：パブリックDNSへのブロッキング命令に抗うCloudflare投稿者: heatwave_p2p 投稿日: 2022/9/182022/9/18 TorrentFreak ウェブブロッキングの拡大を目指す著作権者たちは、DNSリゾルバをターゲットにし始めている。そのメインターゲットの1つがインターネットインフラ企業のCloudflareだ。同社はCDNサービスの顧客のウェブサイトへのブロッキング命令には従う一方で、同社の1.1.1.1 DNSリゾルバのドメイン遮断は行き過ぎだと考えているようだ。 海賊版対策としてのウェブサイト・ブロッキングは、世界中でますます一般的になってきている。 既に数十カ国で、ISPが裁判所から海賊版サイトブロッキングを命じられている。また、そうしたブロッキングが業界間の合意に基づく自主規制と言うかたちで実施されることもある。 Cloudflareへ
![1.1.1.1：パブリックDNSへのブロッキング命令に抗うCloudflare | p2ptk[.]org](https://cdn-ak-scissors.b.st-hatena.com/image/square/6f1a7bf36efab1b3b1503fa86fcaa16fc2430b47/height=288;version=1;width=512/https%3A%2F%2Fp2ptk.org%2Fwp-content%2Fuploads%2F2022%2F09%2Fabstract-1278017_e.jpg)
DNS前史：HOSTS.TXTとドメイン名ができるまで
こんにちは、技術開発室の滝澤です。 先月（2022年7月）、『Software Design 2022年8月号』の特集記事『WebエンジニアのためのDNS速習講座』に『第2章：DNSの構成要素と名前解決のしくみ』という記事を寄稿しました。第1章でも滝澤が趣味で作成した資料『ドメイン名の歴史』が参考文献として掲載されていました。よい機会なので、ドメイン名ができるまでの歴史について文章としてまとめようと思い、この本ブログ記事を書きました。 なお、筆者自身はインターネットの原型であるARPANETや80年代のインターネットをリアルタイムには体験してはいないため、RFC（Request for Comments）やインターネット上にある当時のホストのアーカイブを元に調査した内容をまとめたものになります。 ARPANETの時代 1969年から1980年代初期にかけてのインターネットの原型となったAR
面倒な準備なしで簡単にDNSの実験が行える「mess with dns」
プログラマーのジュリア・エバンスさんが、DNSを使った実験が行えるサイト「mess with dns」を公開しています。 mess with dns https://messwithdns.net/ New tool: Mess with DNS! https://jvns.ca/blog/2021/12/15/mess-with-dns/ DNSを用いた実験には「DNSレコードを作成することに抵抗がある、あるいはドメインを持っていない」「DNSクエリが見えないため何が起こっているのかを理解するのが難しい」「どういった実験を行うべきかわからない」といった問題があります。こういった問題を解消し、実際にどのような実験を行えばいいかを例示しながらDNSの動作を学ぶことができるというのが、「mess with dns」です。mess with dnsでは用意するのが面倒なドメインがあらかじめ用意さ
Clubhouse リアルタイム配信の仕組みについて (妄想編)
Cloubhouse はすでに OSS である Janus Gateway に切り替えており Agora は使用していないようです ライセンス Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0 前提 @suthio_さんがつぶやいていたのがきっかけ https://twitter.com/suthio_/status/1353945619577008128?s=20 招待してくれた @dmnlk さんに感謝 DNS パケット見ただけ 他の方の解析は見ていない クライアント側の処理は知らない 気が向いたら更新している 著者 商用 WebRTC SFU 開発者 WebRTC プロトコルスタック実装者 End to End Encryption プロトコルスタック実装者 IRIAM 配信サーバ設計者 妄想 求人にメディアサーバ
MySQL 8.0.22 DNS SRV レコードサポート - tmtms のメモ
MySQL 8.0.22 の新機能で DNS SRV レコードのサポートというのがあったので試してみた。 https://dev.mysql.com/doc/refman/8.0/en/connecting-using-dns-srv.html MySQLサーバー3台 (a.example.com, b.example.com, c.example.com)とそれに接続するためのクライアントの計4台を docker-compose で作成する。 Dockerfile FROM ubuntu RUN apt update RUN apt install -y mysql-client libmysqlclient-dev gcc unbound bind9-dnsutils RUN rm -f /etc/unbound/unbound.conf.d/root-auto-trust-ancho
技術書典4で販売された「DNSをはじめよう」をフォローする感じの記事にしたい - Qiita
はじめに 技術書典4にて「DNSをはじめよう」が販売され、400部あったはずの紙の本の在庫がなくなり、その後まもなくしてダウンロード用のカードも溶けるようになくなるという現象が発生しました。 自分も午後に会場入りして買いに行ったら「ダウンロード版も売り切れた」と言われショックを受けるものの、ダウンロード版については追加生産をしているとの事なので、ほどなくして再度ブースを伺ったら無事に買う事ができました。 尚、今現在もBOOTHにてPDF版が販売されています。 内容については「さぁDNS！」…の前にドメイン名の取得から丁寧に書いており、ドメイン名の取得からDNS設定の流れを体感するにはちょうどいい本ではないかなと。 なお、ドメインを利用する為にはレジストラやどこかのリセラー経由で登録料を払いドメイン名を登録してもらう必要があり登録手順も様々であるなか、お名前.comからの取得を例にして説明し
障害から学ぶクラウドの正しい歩き方について考える - そーだいなるらくがき帳
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
どうして俺の回線が何百ギガもアップロードしてるの？と思った時に読む話 - 朝日ネット 技術者ブログ
はじめまして、朝日ネットでISPのインフラ保守を行っているa-fujisakiと申します。セキュリティ担当の一人としてお客様の所有されている機器がインターネット越しに悪用される事を防ぐ仕事をしています。 本記事では、インターネットが遅い、調べてみるとネットに接続した機器がアップロードを何百ギガと繰り返している、一旦電源を落として再接続すると復旧するがすぐ元に戻る、といった症状が発生している場合の理由と対策について解説します。 各種の症状について頻度を★マークで示しております。 時刻同期（NTP）サービスの公開による踏み台被害 DNSサービスの外部公開による踏み台被害 LDAPサービスの外部公開による踏み台被害 UPnPサービスの外部公開による踏み台被害 このような被害にあわないために 採用情報 時刻同期（NTP）サービスの公開による踏み台被害 NTP monlistの脆弱性を悪用したリフレ
著名Public DNSの日本直近バックエンドとEDNS Client Subnetのクエリログ｜Guest
1か月ほど前に「Cloudflare Resolver(1.1.1.1)でArchive.todayにアクセスできなワケ」を書いたが、最近また同じような話題で盛り上がっているようだ。 そこで著名なPublic DNSのバックエンドとECS (EDNS Client subnet)の有無について、権威DNSサーバを立ち上げてクエリログを確認してみた。 テスト条件テスト用DNSサーバ―にはICS BIND 9.12.4をインストールし、持て余していたgTLD（記事中ではexample.netに置き換えている）のゾーンを設定した。 テスト用クライアントにはWebARENAのVPSクラウド(157.65.27.7)にホスティングされているCMANインターネットサービスのnslookup(dig)テストを利用した。 Google Public DNS (8.8.8.8)client 173.194.
政府によるインターネットの検閲とSNIについて
しかし今回一般の人の目にも触れる形でSNIやHTTPSのことが報じられた結果、エンジニアも含めて明らかに技術に関して勘違いをしているのではないかと感じる発言を見ることがありました。このまま放置するのも良くないと感じているので、Q&Aという形でSNIやHTTPSに関する誤解を少しでも解ければと思います。 Q&AQ: そもそもSNIって何？以前書いた記事にも書かれているので是非読んでみてください。 簡単に説明すると、HTTPSではSSL/TLSを利用して通信が暗号化されます。なので1つのIPアドレスで複数の証明書を扱おうとした場合、最初の通信時にどの証明書を利用すればいいか分かりません。そこでSNIが必要になります。 SNIは最初の通信時に今から通信したいサーバーネーム（ドメイン名と考えてください）をサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。SNIは現在の一般的なブラウ
ACM証明書をEメール検証からDNS検証に切り替える – サーバーワークスエンジニアブログ
PS課の杉村です。AWS Certificate Manager(以下、ACM)ではEメール検証とDNS検証の2通りの方法でSSL/TLS証明書(DV)を発行することができます。 DNS検証はサービスリリース当初には無かった選択肢ですので、自動更新の理由でEメール検証の証明書をDNS検証に切り替えたい場合があるかもしれません。 参考: AWS Certificate Managerで発行した証明書の自動更新条件 では、一度Eメール検証で発行したACM証明書をDNS検証に切り替える方法はあるのでしょうか。 発行済の証明書を単に変更することはできない のっけから矛盾的ですが、既に一度Eメール検証で発行したACM証明書をDNS検証に"変更"ことはできません。 同じドメイン名でDNS検証で証明書を新規発行し、ELB/CloudFront等側にセットする証明書を切り替えることはできます。 ELB等の
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 に移設してみない?」とタスクが降ってきました。時期としては中途入社後、業務のキャッチアップをしつつ、今まで触ったことがな
Let's Encrypt 証明書の自動更新システムを作る - Hatena Developer Blog
この記事は はてなエンジニア Advent Calendar 2018 11日目の記事です． こんにちは，システムプラットフォーム部でSREをしているid:cohalzです． はてなでは証明書を自動更新してくれる仕組みを作っており，今回はその紹介をします． はてなの証明書自動更新といえば，はてなブログの独自ドメインにおける証明書自動更新システムのことを思い浮かべる人もいるかも知れません． 今回紹介するのは，そのシステムとは違う，開発チーム用に向けて作成したシステムとなります． ここではブログの方のシステムについて紹介は行いませんが，少し前にGeekOut様にてはてなブログのHTTPS化に関する記事が公開されましたのでそちらをご覧ください． geek-out.jp ブログのシステムと何が違うのか まずはじめに，何故ブログと別のシステムを作成したかについて説明します． 大きな違いはシステムで使
[新機能]Route53 リゾルバー登場! オンプレミス-VPCの相互名前解決が簡単に実現できるようになりました! ｜ DevelopersIO
Route 53 リゾルバー Route 53 のマネジメントコンソールを開くと Resolver が追加されています｡ Dashboard Inbound endpoints インバウンドエンドポイントを作成します｡ VPCにはAWS側のVPCを指定してください｡SGはRoute53エンドポイント用に作成したものを選択します｡ エンドポイントを作成するAZ, サブネットはオンプレミスと通信が可能(サブネット範囲やルーティングを考慮する)な所を選びます｡ Outbound endpoins アウトバウンドエンドポイントを同様に作成します｡ ルール オンプレミス側のドメインonpremises.internalがリクエストされた時にオンプレミス側のDNS(Unbound)へ転送(Forwarding)が必要です｡この設定をRoute 53 Resolverではルールと言います｡ オンプレミス
![[新機能]Route53 リゾルバー登場! オンプレミス-VPCの相互名前解決が簡単に実現できるようになりました! ｜ DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/c5287a23631f9589f74e1c272658f6053d2bd763/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAmazon_Route_53.png)
Intra - DNS-over-HTTPSによってインターネットを安全に使う
DNSをハッキングされてフィッシングに使われたり、アクセスできなくなったりするようなインシデントが多数起こっています。DNSはインターネット黎明期から存在しており、セキュリティレベルが現在のものとはそぐわなくなっているのかも知れません。 そこで元Google傘下のJigsawが開発しているのがIntraになります。IntraはDNS-over-HTTPSによってDNSとのやり取りを暗号化し、安全にインターネットが利用できるようになります。 Intraの使い方 起動しました。最初は保護は無効になっています。 利用する際にはVPN接続が使われます。 これで有効になりました。安全にインターネットへのアクセスができます。 利用しているとグラフが動きます。 Intraは安全なDNSサーバとその送受信を保護することによってアクセス先を書き換えられたり監視されるのを防ぐことができます。最新のAndroi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PDF]サブドメインテイクオーバーの概要と その防止策 2021年2月5日 第1回フィッシング対策勉強会 株式会社日本レジストリサービス（JPRS） 森下 泰宏