HTTPSレコードがRFCになりました | IIJ Engineers Blog
RFC9460が出ました 昨年、このエンジニアブログでHTTPSレコードについてとりあげました。これを書いたときはHTTPSレコードはまだインターネットドラフトだったのですが、2023年11月、ついにRFC9460として標準化されました。 RFCにはなったけど日本語の詳しい記事はまだ少ないし需要あるかなーと思って改めて解説を書きはじめたんですが、だらだらとクソ長くなって書いた本人が読んでも眠くて退屈な内容になってしまいました。ので、書いたものはばっさり捨てました。 そういえばいまから3年前、DNS Summer Day 2021で発表したプレゼン資料がありました。これをRFCになった現在の内容にあわせてアップデートしたほうがてっとりばやいしわかりやすそうです。 ということで、加筆修正した資料を置いておきます。DNS屋さんはとりあえず全部読んでおいてください。Web屋さんは前半だけ理解してお
DNS浸透いうな - それは言葉狩りじゃなくて
DNS リソースレコードを管理していると、「DNS には浸透期間があるため、DNS の設定変更後は24時間〜72時間お待ちいただく必要があります」などと書かれた DNS 事業者の注意書きを見かけることがあります。 ホスティング業者によって「浸透」等が不適切に使われている例 - www.e-ontap.com DNS浸透言ってるところと言っていないところ【レンタルサーバ編】 - ohesotori.hateblo.jp このような記述が蔓延っているために、DNS 利用者の間で「DNS では設定が浸透するまで待たなければならない」という誤解が広まっています。 また、DNS リソースレコードの地理的な伝播状況を可視化するための DNS Propagation Checker なるツールがいくつか存在しています。 https://www.whatsmydns.net/ https://www.ns
「1.1.1.1 は一部の多段 CNAME を解決してくれない」改め「makeshop.jp は 1.1.1.1 をブロックしている」
2023/09/20 追記 以下で有識者からコメントをいただきました。 makeshop.jp は 1.1.1.1 を遮断しているらしく、本記事はまさに makeshop.jp で制作したページが見れないことに起因した話題であったため、多段 CNAME は無関係でした。 コメント頂いた皆様、ありがとうございました！ 1.1.1.1 をブロックしている SaaS があると思わずに首を傾げていた頃の記事 disclaimer Dig Web Interface を用いて振る舞いを観測した結果、 1.1.1.1 のみ異なる結果を返したことから本記事のようなタイトルを付けていますが、 1.1.1.1 の振る舞いが正しい可能性もあります。 ことのはじまり とある SaaS でカスタムドメインを利用するため、 CNAME を以下のように設定したところ、 1.1.1.1 もしくは 1.0.0.1 をネー
ドメイン管理を AWS Route 53 から Cloudflare に移管した - 酢ろぐ！
2022年11月に AWS Route 53 のドメイン更新料が値上げされた。一時期と比較してマシになったとは言えるものの円安傾向にある今日日 $1 の値上げでもドメイン数があると結構厳しいなと思っていた。 先日「Route 53 から Cloudflare にドメイン移管したい」という投稿をみて、「そういえば Cloudflare ってCDNだけじゃなくてドメインも売り出したんだっけ……」と調べてみたところ、本記事の執筆時点のレートで Route 53 を契約し続けるよりも約 700円の差があることがわかった。 Route 53 では comドメインが $13 / year (執筆当時：1,729円/年) Cloudflare では comドメインが $8 / year (執筆当時：1,064円/年) さらに Route 53 ではホストゾーンごとに年600円の管理費と S3 の転送料が
お名前.com から Cloudflare Registrar にドメイン移管した話
こんにちはーむちょこです。 ずっと利用していたお名前.com をやめて、 Cloudflare Registrar にドメインを移管してみました。 背景に興味がない方は、目次から「移管手順」のセクションに飛んでください。 お名前.com をやめる理由 初めてドメインを取ったのがお名前.com でした。 たぶんその頃は日本語サイトでドメインを取ろうと思ったら真っ先に思い浮かぶのがお名前.com だったような気がします。 それからずーっとお名前.com を使い続けていましたが、その間サービスはいろいろと施策を打つわけです。メールたくさん送ってみたりね。 そうして蓄積されたちょっと嫌なイメージと、値上がりのお知らせと、他のサービスも使ってみたいという好奇心に駆られて今回やめてみることにしました。 Cloudflare Registrar を選んだ理由 とりあえず、エンジニアがたくさんいる com
Fastly で Next.js アプリケーションを実行
Fastly の新しい next-compute-js ライブラリを使用することで、Compute@Edge プラットフォーム上で Next.js アプリケーションをホストできるようになりました。これにより、Next.js 開発者のエクスペリエンスが向上し、圧倒的なスピードを誇る Fastly のグローバルエッジネットワークのメリットが得られます。オリジンサーバーも必要ありません。 Next.js は広く普及している JavaScript ベースのサーバーフレームワークで、開発者に優れたエクスペリエンスを提供します。具体的には、フロントエンドのコードを React で作成できるほか、ごくわずかな設定で本番環境に必要な優れた機能 (ハイブリッドの静的レンダリングとサーバーレンダリング、スマートバンドル、ルートプリフェッチなど) を直感的にセットアップできる便利さを備えています。 Next.j
DNSリバインディング(DNS Rebinding)対策総まとめ
サマリ DNSリバインディングが最近注目されている。Google Chromeは最近になってローカルネットワークへのアクセス制限機能を追加しており、その目的の一つがDNSリバインディング対策になっている。Googleが提供するWiFiルータGoogle Nest WiFiはデフォルトでDNSリバインディング対策機能が有効になっている。 DNSリバインディング対策は、攻撃対象アプリケーションで行うべきものであるが、ブラウザ、PROXYサーバー、リゾルバ等でも保護機能が組み込まれている。本稿ではそれら対策機能の状況と対策の考え方について説明する。 DNSリバインディング（DNS Rebinding）とは DNSリバインディングはDNS問い合わせの時間差を利用した攻撃です。DNSのTTL（キャッシュ有効期間）を極めて短くした上で、1回目と2回目の問い合わせ結果を変えることにより、IPアドレスのチ
面倒な準備なしで簡単に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では用意するのが面倒なドメインがあらかじめ用意さ
Public Suffix List の用途と今起こっている問題について | blog.jxck.io
Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ
DNS改竄検知ツールをgolangで作った(Slack通知付き) - Code Day's Night
DNSのNSレコード、MXレコードの改竄を検知（変更検知）し、オプションでSlack通知もできるツールを公開しました。 https://github.com/ichikaway/nschecker Go言語で開発し、LinuxとMacのバイナリもダウンロードできます。 すぐに実行できるため、cron指定しておけば意図しないレコードの変更がわかります。 作った経緯 最近、ドメインハイジャックの事件を目にするよになりました。 DNS設定の改ざんによるドメイン名ハイジャックに注意喚起（JPRS） | ScanNetSecurity 2020年6月にコインチェックのドメインハイジャック事件が起きています。 コインチェックのドメインハイジャックの手法を調査した - Shooting!!! この記事を読むと、改竄されたレコードは、ns-1515.awsdns-"0"61.orgのような一見正しそうだが
趣味GKEのIngressを無料で済ませる - ダルツ海峡冬景色
GKEでサービスを外部公開する際には、 GKE Ingress とそのバックエンド GCP Cloud Load Balancing を使用するのがスタンダードです。が、これには費用 ($18/月~) がかかります。 これをCloudflare DNS + Contourで置き換えて、無料で済ませる方法を説明します。ノードは全台プリエンプティブインスタンスで構いません。 この記事はDoxseyさんによる Kubernetes: The Surprisingly Affordable Platform for Personal Projects を発展させた内容になります。 元記事と同様、紹介する構成は趣味利用にとどめてください。 GKEクラスタ作成 まずGKEクラスタを作成してください。3台以上で構築し、プリエンプティブを有効にするのがオススメです。 ちなみにDoxseyさんの記事ではf1
Route53でのサブドメイン移行で「DNSの浸透」神話の裏側を理解した話 ｜ Developers.IO
実際にこの作業をやってみました。 書き換え自体は、コンソールから直接でも60秒程度で終わりました。 直後に名前解決が上手くできなかったりもしましたが、無事開発環境がwww.hogehoge.comで解決できるようになりました！ $ dig www.hogehoge.com ; <<>> DiG 9.10.6 <<>> www.hogehoge.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13815 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 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 HTTPSの必要性について - Qiita
なぜ今までのDNSでは問題があるのか インターネット上の通信の多くは、ブラウザを利用したウェブによるものです。 セキュリティ向上のため、GoogleやFireFoxといった大手ブラウザベンダーが平文通信であるHTTPから暗号通信であるHTTPSへの移行を推奨し、盗聴・改竄・なりすましといった問題を解決することが出来ます。 しかしながら、そのHTTPS通信をする前のDNSによるドメイン解決は暗号化されておらず盗聴でアクセスするホスト名を把握される、なりすましで偽の応答を返されるといった可能性があります。 それを防ぐための方法の1つが、DNS over HTTPSです。 DNS over HTTPSとは 今までDNSサーバ（フルリゾルバ）の（主に）UDPポート53番に対して行われていたDNSによる名前解決を、TCPポート443番に対するHTTPS(HTTP/2 over TLS)通信上で行うプ
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 に移設してみない?」とタスクが降ってきました。時期としては中途入社後、業務のキャッチアップをしつつ、今まで触ったことがな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Public DNS
DBやめてみた / DNS water torture attack and countermeasures
Basics_of_DNS_that_application_engineers_should_know - Speaker Deck
DNS移転失敗体験談
DNS再入門ー初心者からベテランまで、基礎から見直して見よう。 #oscnagoya #osc_tss_ontap
