今日のワンライナー：meminfoを調べる
某サーバのメモリ使用量に納得がいかないので、わかりやすく表示するワンライナーを書いた。
# cat /proc/meminfo |perl -E 'while(<>){m!^(.+):\s*(\d+)! and $h{$1}=$2} END { @active=qw/MemFree Active(file) Inactive(file) Unevictable Active(anon) Inactive(anon) SReclaimable SUnreclaim KernelStack PageTables VmallocUsed/; map { say "$_\t$h{$_}"; $total+=$h{$_} } @active; say "--"; say "MemTotal\t$h{MemTotal}";say "*Unknown\t".($h{MemTotal}-$total) }'
MemFree 237356
Active(file) 355420
Inactive(file) 171960
Unevictable 15692
Active(anon) 43040
Inactive(anon) 62300
SReclaimable 48644
SUnreclaim 25252
KernelStack 1624
PageTables 7384
VmallocUsed 0
--
MemTotal 993172
*Unknown 24500
Unknownが700MBぐらいになるサーバあって悩んでいます。
以下の記事を参考にさせていただきました。
買ってよかった2021
今週のお題「買ってよかった2021」
去年、Apple Watchを買って
如何に動いてなかったかが可視化されてしまったのを契機に、今年の年明けから朝の時間に運動(ウォーキングのちにランニング)するようにしました。子供たちを学校に送りだして、仕事する前にやってます。
そうだ運動をしよう
坂道・階段があるコースを30分ぐらいで3km弱歩いていたのですが、歩いている途中に音楽聴いたりしたいなということで、骨伝導イヤホンを買書いました。骨伝導なら周りの音も聞こえるので安心です。
買ったのは、AfterShokz Aeropex。
たまにオンラインの会議でも使っていて、今年買ってよかったものではかなり上位。
このAfterShokz Aeropexは充電コネクタがマグネット式となっていて、ケーブルを近づけるだけでカチッとくっついて充電ができるのも便利なのですが、そのケーブルがちょいと短いので、USBの延長ケーブルがあると便利です。
ウォーキングをするようになって体重も減り始めたのでスマホ連携できる体重計を買った。メトリクス大事。
置いている場所のせいかスマホへの自動転送の成功率があまり高くはない（手動で読み込みかけると転送できる）けど、体重その他の数値が取れ、グラフになるのはよい。グラフ大事。
夏に一旦減りがとまったけど、そのあたりからウォーキングからランニングに切り替えて運動強度をあげました。以前から@fujiwaraさんや@mattn_jpさんが走った結果をtwitterにあげているのをみて、勝手に目標とさせてもらっています。
歩くのにはとくに道具は必要ないですが、走るとなるといくつかあった方がいいものがあって、まずはランニングシューズを、また、マウスカバー(!マスク)、上着、手袋、小物を入れて置けるポーチなどを買いました。
![[アシックス] ランニングウェア ランニンググラフィックウーブンジャケット 2011C169 メンズ 001(パフォーマンスブラック) M](https://m.media-amazon.com/images/I/51p10SiKEzL._SL500_.jpg "[アシックス] ランニングウェア ランニンググラフィックウーブンジャケット 2011C169 メンズ 001(パフォーマンスブラック) M")
![[デサント] 手袋 フィールドグローブ スマホ対応 抗菌 抗ウイルス クレンゼ スポーツ ブラック L](https://m.media-amazon.com/images/I/41D9vi3N2+L._SL500_.jpg "[デサント] 手袋 フィールドグローブ スマホ対応 抗菌 抗ウイルス クレンゼ スポーツ ブラック L")
ランニング用のジャケットや手袋は軽くていいですね
この成果もあり、12月には月の走行距離が100kmを超えました。
今月のランニングの合計距離が100km超えた pic.twitter.com/Qt0PhjmTIO
— Dorayaki Maritozzo (@kazeburo) 2021年12月27日
走り初めは、1km走るのに6分以上かかっていたけど、最近は5分切れるようになってきたので調子にのって来年も怪我に気をつけて頑張りたい。
娘の骨折
11月に、娘が左の肘を骨折して、3週間ほどのギブス生活になった。本人大変だっただろうにがんばった。怪我してすぐは病院でもらった白い布の三角巾で腕を吊っていましたが、結んだり外したりが不便で、結び目が首の後ろということもあり、痛がって外してしまうので、病院で使っていいか確認してメッシュでできたアームホルダーを買いました。
(大サイズ（S）) という表記が気になりますが、脱着も楽なのでギブスがとれるまで、多少ほつれて縫ったりもしましたが毎日使えました。
2ヶ月たって骨折は大分よくなっているので安心です。
リフォームしたのでライトを新調
家を少しリフォームして、仕事の机を置く場所ができたので、その上のライトを新調した。レールはそのまま。
INTERFORMという照明・家具のメーカーのもので、おしゃれで気に入っている。
リビングの時計もここで買ったものを使っています。
来年は何買うかな~
クラウドサービスにおける ReDoS 対策
正規表現のマッチングにかかる処理時間が指数的に増えることでDoS脆弱性が発生し、それを利用した攻撃を ReDoS 攻撃と呼びます。
詳しくは、
最近書かれた、立命館コンピュータクラブの記事もよくまとまっております。
クラウドサービスにおける ReDoS 対策
クラウドのサービスでは、お客様にサーバやミドルウェアの設定として正規表現やワイルドカードを入力していただくことがあります。そうした場合に正規表現がReDoSの対象とならないよう、チェックしなければなりません。
さくらのクラウドのエンハンスドロードバランサではコントロールパネルにてワイルドカードを入力する箇所がいくつかあります。ワイルドカードはL7ロードバランサとして利用しているHAProxyの設定では正規表現に変換されて使用されます。
以前は、マッチングの負荷を抑えるため、ワイルドカード文字 * や ? を利用する数を数個に制限しておりましたが、現在ではその制限を緩和し、 ReDoS につながる正規表現をチェックする以下のライブラリを使って負荷になる正規表現にならないか確認しています。
safe-regexのREADMEにも書かれてますが、より正確なチェックをするには別のライブラリがおすすめされています。
また、立命館コンピュータクラブの記事でも紹介されている recheck もあります。
今回はワイルドカードからの変換であり、自由に正規表現が指定できないので safe-regex を利用しています。
ワイルドカード文字の個数制限をやめてReDoSチェックの導入する提案はフロントエンドのエンジニアから頂き、開発も一緒にやりました。さくらのクラウドの開発チームはフロントエンド、バックエンド、基盤などの役割を問わず改善のアイディアを出し合って開発を進めています。
正規表現チェックサーバ
さくらのクラウドのコントロールパネルは JavaScript/TypeScript で作られていますので、上記のライブラリはフロントエンドそのまま使えますが、APIや基盤の制御、ミドルウェアの設定の生成をするサーバ側はPHPやPerlまたはGoといった言語で書かれているので、そのまま使うことはできません。
そこで、davisjam/safe-regex を呼び出すだけのAPIサーバを Node.js で作り hacobune で動作させ、PHP/Perlから利用するようにしました。小さいAPIを作るのは Mackerel の Plugin をインストールするための release Tag キャッシュサーバ と同じアイディアです。
使い方
$ docker run -p 3000:300 ghcr.io/kazeburo/safe-regex-api:latest
$ curl -sSf -XPOST --data-urlencode 'regexp=[a-z]+' localhost:3000/is_safe_regexp
{"error":false,"is_safe":true}
expressのmiddlewareの機能により、form-urlencodedまたはJSONでPOSTできます。
curl -sSf -XPOST -H 'Content-type: application/json' -d '{"regexp":"[a-z]+"}' localhost:3000/is_safe_regexp
{"error":false,"is_safe":true}
安全でない正規表現を送るとis_safe が false となることがわかります
$ curl -sSf -XPOST --data-urlencode 'regexp=(a+)+' localhost:3000/is_safe_regexp
{"error":false,"is_safe":false}
まとめ
hirose31/s3surfer でさくらのクラウド オブジェクトストレージにアクセスする
hirose31さん作のAmazon S3にあるファイルリストの閲覧とファイルのダウンロードにとても便利なツール s3surfer にAPIのエンドポイントURLを切り替えるオプションをつけていただき、さくらのクラウドのオブジェクトストレージにもアクセスできるようになりました。
さくらのクラウドのオブジェクトストレージについてははこちら
こちらのサービスではS3互換のAPIを提供させていただいています。
使い方
Mac/Linuxの場合はGitHubのリリースページからバイナリをダウンロードしてインストールできます。v1.0.3 以降で --endpoint-url オプションが使えます。
さくらのクラウドのオブジェクトストレージのAPI Endpointを指定して起動します。その他のS3互換ストレージでも利用できるかと思います。
% s3surfer --endpoint-url=https://s3.isk01.sakurastorage.jp/
~/aws 以下に credential があるか、AWS_ACCESS_KEY_ID の設定は必要です。
動作イメージ
bucketのファイル一覧を表示するイメージ
ファイルのダウンロードもできました。簡単便利
mkr plugin install 時の403 API rate limit exceededエラーを回避する方法
この記事はMackerel Advent Calendar 2021の14日目の記事です。
最近、さくらのクラウドの一部のサービスの監視にmackerelを導入し始めました！ そして今年もいくつかのmackerel pluginを作成しています。
ログをメトリクスにするプラグイン
インターフェイスごとのエラーや送受信したパケットを可視化するプラグイン
100%上限のCPU使用率グラフ、ロードアベレージをコア数で割ったメトリックを作成するプラグイン
そのほか、mackerel-plugin-axslogにも新しい機能が増えています。
この記事は既存のサーバにこれらのmackerel pluginをansibleで導入していった際に出たエラーと回避策のお話です。
mkr plugin install時のrate limitエラー
次のようにAnsibleのplaybookを書き、mackerelプラグインのインストールを実行していたところ、
- name: install mkr plugins
become: yes
shell: "mkr plugin install --upgrade {{ item }}"
with_items:
- kazeburo/mackerel-plugin-linux-memory
- kazeburo/mackerel-plugin-axslog
- kazeburo/mackerel-plugin-linux-netdev
- kazeburo/mackerel-plugin-linux-usage
- kazeburo/mackerel-plugin-log-counter
GitHubのAPIのrate limitに引っかかりました
failed: [192.168.0.1] (item=kazeburo/mackerel-plugin-axslog) => {"changed": true, "cmd": "mkr plugin install --upgrade kazeburo/mackerel-plugin-axslog", "delta": "0:00:00.071010", "end": "2021-11-01 17:12:53.402650", "item":
"kazeburo/mackerel-plugin-axslog", "msg": "non-zero return code", "rc": 1, "start": "2021-11-01 17:12:53.331640", "stderr": "\u001b[0;31m error\u001b[0m Failed to install plugin while making a download URL: GET
https://api.github.com/repos/kazeburo/mackerel-plugin-maxcpu/releases/latest: 403 API rate limit exceeded for 203.0.113.147. (But here's the good news: Authenticated requests get a higher rate limit. Check out the
documentation for more details.) [rate reset in 12m04s]", "stderr_lines": ["\u001b[0;31m error\u001b[0m Failed to install plugin while making a download URL: GET https://api.github.com/repos/kazeburo/mackerel-plugin-maxcpu/releases/latest: 403 API
rate limit exceeded for 203.0.113.147. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) [rate reset in 12m04s]"], "stdout": "", "stdout_lines": []}
これはmkrがプラグインの’最新のバージョンを調べるために、GitHubのAPIにアクセスしているところで発生します。
回避策はmackerelのマニュアルで紹介されています。
mkr plugin installはGithubから最新のリリースを探すためにGithub APIを利用します。そのため、Githubの設定画面から取得できるアクセストークンを指定しておかなければ、Github APIのRate Limitの制限にあたり、インストールが失敗する可能性があります。
もうひとつは明示的にバージョンを指定する方法です
mkr plugin installではGithub Releasesのリリースタグが明示的に指定された場合、GithubのAPIにアクセスしないため、Rate Limitの制限にかかることはありません。そのため、サーバプロビジョニングツールから利用するときは、リリースタグを明示的に指定することをおすすめします。
今回、セットアップしている環境ではすぐに用意できるアクセストークンはなかったため、前者の方法は取りにくく、後者を行うことになります。
- name: install mkr plugins
become: yes
shell: "mkr plugin install --upgrade {{ item }}"
with_items:
- kazeburo/mackerel-plugin-linux-memory@v0.0.6
- kazeburo/mackerel-plugin-axslog@v0.3.1
ただ、pluginを作成した直後はバージョンアップ回数が増えるため、都度バージョンをあげるのは面倒です。（今回は自前のプラグインのため最新バージョンでも問題がないことがわかっている前提がありますが、安定した運用のためにはバージョン固定がベストプラクティスです）
そこで、releaseTagを取得してキャッシュするサーバを書きました
releaseTag キャッシュサーバ
readmeもないですが作成しました。
実行すると次のレスポンスが得られます。
% curl -sSf 127.0.0.1:8080/kazeburo/chocon|jq .
{
"release": "v0.12.5",
"has_error": false,
"erorr": "",
"assets": [
{
"name": "chocon_0.12.5_checksums.txt",
"download_url": "https://github.com/kazeburo/chocon/releases/download/v0.12.5/chocon_0.12.5_checksums.txt"
},
{
"name": "chocon_darwin_amd64.zip",
"download_url": "https://github.com/kazeburo/chocon/releases/download/v0.12.5/chocon_darwin_amd64.zip"
},
{
"name": "chocon_linux_amd64.zip",
"download_url": "https://github.com/kazeburo/chocon/releases/download/v0.12.5/chocon_linux_amd64.zip"
},
{
"name": "chocon_linux_arm.zip",
"download_url": "https://github.com/kazeburo/chocon/releases/download/v0.12.5/chocon_linux_arm.zip"
},
{
"name": "chocon_linux_arm64.zip",
"download_url": "https://github.com/kazeburo/chocon/releases/download/v0.12.5/chocon_linux_arm64.zip"
}
]
}
結果は5分キャッシュされるように作り、mkrのソースコードを参考にGITHUB_TOKENの環境変数がセットされていれば使うようにしています。
サーバは趣味全開で作り、フレームワークは github.com/gofiber/fiber、キャッシュの有効活用のために golang.org/x/sync/singleflight を使ってます。
これをさくらのクラウドの Hacobune にデプロイし、Ansibleのplaybookを
- name: install latest mkr plugins
become: yes
shell: "mkr plugin install --upgrade {{ item }}@$(curl -fs 'https://example.com/{{ item }}?plain')"
with_items:
- kazeburo/mackerel-plugin-linux-memory
- kazeburo/mackerel-plugin-linux-netdev
- kazeburo/mackerel-plugin-linux-usage
- kazeburo/mackerel-plugin-log-counter
- kazeburo/mackerel-plugin-maxcpu
のようにしました。
これでRate Limitエラーは避けられ、常に新しいバージョンをいれることができました。
まとめ
今後も必要なpluginを揃え、メトリクスを充実させながら、mackerelを使ってクラウドの安定運用やっていきます。
HAProxyにコントリビュートした話
さくらインターネット Advent Calendar 2021 10日目の記事です。
日頃、運用や新機能の開発を行っているさくらのクラウドの「エンハンスドロードバランサ」はL7のロードバランサのソフトウェアとしてHAProxyを使っています。
こちらの記事でシステム構成について紹介しております。
また、本blogにてlibslzによるHTTPレスポンスのGZIP圧縮の紹介もしています。
この記事はHAProxyの運用で問題を発見し解決した話と、HAProxyにissue報告した話になります。
発見から問題特定まで
とある作業後、エンハンスドロードバランサのL7ロードバランサであるHAProxyのうちの一つのプロセスが異常にCPUを使っているのを発見しました。
このHAProxyのプロセスはCPU 1コアを使い切っている状態になっておりました。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28007 haproxy 20 0 570272 11612 924 S 99.0 0.2 0:31.57 /usr/local/sbin/haproxy
エンハンスドロードバランサでは、1つのロードバランサ設定ごとにhaproxyのプロセスが割り当てられます。他を確認したところ、特定の１つの設定でのみ起きている問題で、他のお客様の設定では発生しておりませんでした。
負荷の原因としてロードバランサへの攻撃や定期的な突発アクセスを想定し、アクセスログの調査をしましたが、そのような形跡はありませんでした。
次にtopコマンドで観察していると、CPUがbusyとなる状態は定期的に発生し、10秒程度継続して元にもどるように見えたので、同じ間隔で設定されている実サーバへのヘルスチェック時になにか起きていそうだと当たりをつけ、今度は strace でそのタイミングを捉えてみると、次のようなトレースが取得できました
[pid 28015] connect(31, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("198.51.100.123")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 28015] epoll_ctl(30, EPOLL_CTL_ADD, 31, {EPOLLIN|EPOLLOUT|EPOLLRDHUP, {u32=31, u64=31}}) = 0
[pid 28015] clock_gettime(CLOCK_THREAD_CPUTIME_ID, {89, 485590665}) = 0
[pid 28015] epoll_wait(30, [{EPOLLOUT, {u32=31, u64=31}}], 200, 2556) = 1
[pid 28015] clock_gettime(CLOCK_THREAD_CPUTIME_ID, {89, 485637316}) = 0
[pid 28015] recvfrom(31, 0x7f14740342d0, 16320, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
[pid 28015] sendto(31, "HEAD /health-check.html HTTP/1."..., 93, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 93
[pid 28015] epoll_ctl(30, EPOLL_CTL_MOD, 31, {EPOLLIN|EPOLLRDHUP, {u32=31, u64=31}}) = 0
[pid 28015] clock_gettime(CLOCK_THREAD_CPUTIME_ID, {89, 485774729}) = 0
[pid 28015] epoll_wait(30, [{EPOLLIN|EPOLLRDHUP, {u32=31, u64=31}}], 200, 2554) = 1
[pid 28015] clock_gettime(CLOCK_THREAD_CPUTIME_ID, {89, 485839265}) = 0
[pid 28015] recvfrom(31, "<!DOCTYPE HTML PUBLIC \"-//IETF//"..., 16320, 0, NULL, NULL) = 565
#ここで止まる
この結果から、ヘルスチェックのため実サーバである 198.51.100.123 のポート443に対してアクセスし、このタイミングでCPU負荷が上がる状態に陥っていることがわかり、また、(おそらく)SSL有効なポートに対して生TCPでアクセス(お客様の設定の間違いのようですが)してしまった結果、HTTPのレスポンスヘッダがなく、いきなりエラーを知らせるHTMLが返ってきていることもこのトレースからわかりました。
HTTPSのポートにHTTP通信を行った際に、HTTPレスポンスヘッダがなくコンテンツが返るのはイレギュラーのようで、手元にあるいくつかのWebサーバ調べましたが、Nginxなど大体のWebサーバはHTTPヘッダを返しています。
検証とパッチ作成
このHTTPヘッダを返さない実サーバが問題を引き起こしているのではないかということで、Go言語で同じ動きをするサーバを作成し、手元で動かして検証しました。
動かしたGoのサーバはこれです。Goは雑(すぐ)にかけていいですね
問題が再現できるhaproxyの最小限の設定を作成し
global
log stdout format raw local0
defaults
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
frontend 113300002882-163.43.241.14:80
mode http
bind 0.0.0.0:8080
default_backend 113300002882-backend-default
backend 113300002882-backend-default
mode http
option httpchk GET /live
server 127.0.0.1:12345 127.0.0.1:12345 check inter 10s
ヘルスチェックのコードにてprintf debugで問題箇所の特定を行い、以下のpatchを作成しました。
1日がかりで結構時間かけた割には、変更は30文字にも満たないpatchとなりました。
問題の原因としては、通信が切れたにもかかわらず、HTTPヘッダを探すためヘルスチェックのタイムアウトまで次のパケットを読み込もうとしてループしてしまうことで、このpatchで通信が切れていた場合、次のデータをまたずに即時エラーとするようにしています。
このpatchを、エンハンスドロードバランサの開発環境に適用し、busy loopが解消していること、また他の問題のでないことを確認し、順次本番環境へも導入していきました。
勝利の瞬間です
haproxyへのコントリビュート
HAProxyはOSSですから、この問題についてissueをあげてコントリビュートをすることにしました。
登録したissueはこちら
送ったpatchは少し内容が変わりましたが、問題箇所の認識は間違ってなかったようで
取り込まれて、haproxy 2.4.8 に含まれる形でリリースされました。
http://www.haproxy.org/download/2.4/src/CHANGELOG
- BUG/MEDIUM: tcpcheck: Properly catch early HTTP parsing errors
これが今回の修正にあたります。
非常にニッチなものではあり、感想も月並みではありますが、サービスの中で使用しているOSSに対するissue報告とコントリビュートができて良かったです。
OSSなソフトウェアの開発・運用上発見した問題があれば、今後とも積極的にコントリビュートしていきます。
さくらのクラウド DNSアプライアンスで HTTPS RR を試してみた
さくらインターネット Advent Calendar 2021 7日目の記事です。
DNSコンテンツサーバ機能を提供するさくらのクラウドの「DNSアプライアンス」では、2021年9月からHTTPSリソースレコード・SVCBリソースレコードをサポートしています。
こちらの紹介記事になります。
HTTPSリソースレコード(HTTPS RR)とは、DNSでHTTPSサーバに接続する際のALPNなどのパラメータを渡すことができる新しいDNSのレコードタイプで、CNAMEと異なりZone APEXにも設定ができるのが特徴です。また、HTTPSレコードがある場合、初回からHTTPS接続を行うHSTS(HTTP Strict Transport Security)としても利用されます。CDNのcloudflareやiOSのSafariではすでにデフォルトで使われております。
HTTPS RR・SVCB RRについては以下の記事も参考になります
HTTP RRの仕様は近いうちにRFCになるかと思います。
HTTP/3対応のサーバの準備
まず、実験に使うサーバを用意します。
さくらのクラウドの仮想サーバを1台作成します。今回はOSにRocky Linux 8.5を使いました。
サーバ起動後、必要なポートを開けます
$ sudo firewall-cmd --permanent --add-service=http $ sudo firewall-cmd --permanent --add-service=https $ sudo firewall-cmd --permanent --add-port=443/udp $ sudo firewall-cmd --reload
今回の実験ではWebサーバとしてHTTP/3が利用できる Caddy というサーバを使います。
CaddyはGoで書かれており、HTTPS周りの設定を自動で行ったり、Let's EncryptやZeroSSLから証明書を取得してインストールしてくれるなど便利なやつです。
Caddyのインストールはこちらにドキュメントがあります。今回はdnf/rpm系OSなので、
$ sudo dnf install 'dnf-command(copr)' $ sudo dnf copr enable @caddy/caddy $ sudo dnf install caddy $ sudo systemctl start caddy $ sudo systemctl enable caddy
この手順でインストールと起動ができました。
Caddyのデフォルトの設定は /etc/caddy/Caddyfile にあり、コメントを除くと
:80 {
# Set this path to your site's directory.
root * /usr/share/caddy
# Enable the static file server.
file_server
}
のようになってました。癖のある設定ファイルですが、 /usr/share/caddy をドキュメントルートして、静的なファイル配信を行うサーバが port 80 で起動します。
ブラウザからIPアドレスでアクセスするとやや斜めに傾いたデフォルトのページがみれました。
これでCaddyのセットアップは一旦OKです。
DNSレコードの登録
まずは、通常のAレコードからさくらのクラウドのコントロールパネルから追加します。
次に、HTTPSレコードも登録
HTTP RRでは、Svc Priorityに 0 を入れるとエイリアスモードとなります。Zone APEXに指定する際などに使います。今回はエイリアスではないので適当な数値 10 を入れています。
Target Nameはホスト名になりますが、. (ドット) を入れることで同名のAレコードを参照するよう指定できます。
Svc ParamsにサーバにHTTPS接続する際のパラメータを入力します。
alpn=h3,h3-29,h2 ipv4hint=198.51.100.133
CaddyはHTTP/3(h3, h3-29)、HTTP2に対応しているのでALPNをこのように指定しました。ipv4hintのIPはAレコードのIPアドレスと同じです。
登録ができたら、Google Public DNSを使って確認してみます。
{
"Status": 0,
"TC": false,
"RD": true,
"RA": true,
"AD": false,
"CD": false,
"Question": [
{
"name": "caddy.nomadscafe.tokyo.",
"type": 65
}
],
"Answer": [
{
"name": "caddy.nomadscafe.tokyo.",
"type": 65,
"TTL": 30,
"data": "10 . alpn=h3,h3-29,h2 ipv4hint=198.51.100.133"
}
],
"Comment": "Response from ."
}
Caddyの設定
デフォルトではポート80をlistenしているだけなので、HTTPSが利用できるよう設定を変更します。
{
servers :443 {
protocol {
experimental_http3
}
}
}
caddy.nomadscafe.tokyo {
log
root * /usr/share/caddy
file_server
}
これでサーバを再起動すると、HTTP/3を有効にして caddy.nomadscafe.tokyo の証明書取得も行ってくれました。
ブラウザからのHTTPSのアクセスも問題なくできました。Firefoxの開発ツールでHTTP/3で通信していることも確認できました。
Firefoxでは、HTTPS RRの使用が、DNS over HTTPS (DoH)を使用したときに限られています。about:networking とURL入力欄に打ち込むとDNS照会ツールが使えるので、これを使って確認します。
まず、DoHを使用しない場合
HTTP RRは空っぽです。次に DoHを有効にした場合 (cloudflareを使いました)
HTTP RRの欄にHTTPSレコードに入力したものが表示されました。
Aレコードを消して HTTPS レコードを試す
このままでは HTTPS レコードを使ってアクセスしているのか分かりにくいので、Aレコードを消してみることにしました。
svc.nomadscafe.tokyo として新しいAレコードを置き、caddy.nomadscafe.tokyo の Target Nameをそちらに向け、caddy.nomadscafe.tokyo の Aレコードを削除しました。
IPアドレスがUNKOWNになりましたが、HTTPS レコードは表示されます。DoHの有効のFirefoxブラウザでのアクセスもできました。
ただし、リロードを繰り返すとタイミングによって名前解決に失敗したエラーがでることがあります。これは about:config で network.dns.force_waiting_https_rr を true にすることで出なくなりますが、Aレコードがないのがおそらく異常なので、この設定を常用する必要はありません。
macOS CatalinaのSafariはHTTPS RRに対応していないのでアクセスができません。
macOS Big SurやiOS 15のSafariでは特に設定なくアクセスできました。
Chrome(96.0.4664.93)は対応していないのかDoHを有効にしてもアクセスできませんでした。
まとめ
ということで、HTTPSリソースレコードを使って、実験をしてみました。現状メリットが大きいものではないですが、今後使われるようになっていくのでしょう。お試しあれ~
