What is the KeyTrap vulnerability? のところを読むと以下のように書いてあります（ChatGPT訳）。
KeyTrap脆弱性については、攻撃者が多数のDNSKEYおよびRRSIGレコードを含むDNSゾーンを作成し、標準準拠のDNSSECバリデータが一致して検証する一組の組み合わせを見つけることを期待して、可能なDNSKEYおよびRRSIGレコードの全ての組み合わせを試みます。バリデータが実行する作業量に明確な制限を設けていない場合、無駄な作業に膨大なリソースを費やすことになります。この攻撃は非対称的で、攻撃者は比較的少ない労力でリゾルバに多大な労力を強いることができます。
特に古いバージョンのBINDに対してこの攻撃は極めて効果的で、DNSSEC検証は歴史的にほぼすべての処理と同じスレッドで行われていました。BINDのこの設計上の欠陥と、検証のための無制限の努力が組み合わさり、攻撃者がBINDのクエリ処理を長時間ブロックすることを可能にしました。これは遅いCPUでは数分またはおそらく数時間にも及ぶことがあります。
これを読むとあまりにもシンプルで驚くと思います。要は大量の公開鍵と大量の署名をレスポンスとして送りつけると、リゾルバーは全ての組み合わせを試そうとするので処理に時間がかかる、以上！という内容です。この時点ではATHENEから論文などは公開されていなかったのですが、正直これだけで攻撃可能なぐらいだと思います。
⇧ 認証のための鍵を大量に送り付けて、処理に時間がかかるように仕向けてサーバーの処理を長時間ブロックするからして「KeyTrap」と。
マルチスレッドを導入して解決できる問題なのかは分からんのだけど、今のところ、有効な手立てが見つけられていない状態っぽい...
docker-compose restartは、docker-compose.ymlの変更を反映しない
何やら、
全ての停止中および実行中のサービスを再起動します。
docker-compose.yaml 設定ファイルに変更を加えていたとしても、この再起動コマンドの実行後には反映されません。
⇧ ということらしい。
あくまで、停止しているDockerコンテナを再起動するだけと。
docker-compose upは、docker-compose.ymlの変更を反映する
何やら、
もしサービス用のコンテナが存在している場合、かつ、コンテナを作成後にサービスの設定やイメージを変更している場合は、 docker-compose up -d を実行すると、 設定を反映するためにコンテナを停止・再作成します（マウントしているボリュームは、そのまま保持します）。Compose が設定を反映させないようにするには、 --no-recreate フラグを使います。
⇧ ということらしい。
デフォルトだと、Dockerコンテナを再作成してから起動するので、docker-compose.ymlの変更が反映されるのですと。
オプションによって、反映させなくもできるみたい。
docker-compose upで一部のコンテナだけdocker-compose.ymlの変更を反映したい
で、Docker Composeを利用している場合、複数のDockerコンテナを起動させるパターンが一般的な気がするのですが、一部のDockerコンテナだけに、docker-compose.ymlの変更を反映したいこと、あるあるだと思うのですが、
⇧ 可能らしい。
ただ、結局のところ、docker-compose.ymlを利用して作成したDockerコンテナなのかとかの判断が難しいんよな...
普通に、
docker-compose ps
⇧ とかで表示されるDockerコンテナだけが、docker-compose.ymlを使って稼働したDockerコンテナと見なせば良いのか？
ただ、
各設定ファイルはプロジェクト名を持っています。 -p フラグでプロジェクト名を指定できます。フラグを指定しなければ、Compose は現在のディレクトリの名前を使います。詳細は COMPOSE_PROJECT 環境変数 をご覧ください。
COMPOSE_PROJECT_NAME
プロジェクト名を設定します。このプロジェクト名としての値とサービス名が、起動するコンテナの名前に付けられます。たとえば、プロジェクト名は myapp で、 db と web という2つのサービスがあるとすると、Compose は myapp_db_1 と myapp_web_1 という名前のコンテナを個々に起動します。
https://docs.docker.jp/compose/reference/envvars.html#compose-project-name
この設定はオプションです。 COMPOSE_PROJECT_NAME の指定が無ければ、デフォルトではプロジェクトがあるディレクトリ名をプロジェクト名として扱います。 -p コマンドラインのオプション もご覧ください。
https://docs.docker.jp/compose/reference/envvars.html#compose-project-name
⇧ 確か、プロジェクト名を付けている場合って、
docker-compose -p ${DOCKER_PROJECT_NAME} ps
⇧ プロジェクト名を指定しないと表示されなかった気が...
⇧ 「-p」オプションを使ったコマンド例を載せてくれれば良いものを...
一応、
⇧ 環境変数を.envファイルとかで設定できて、「COMPOSE_PROJECT_NAME」とかも設定できるっぽいのだけど、もし、仮に、.envファイルとかに設定せず、docker-compose upとかのコマンド実行時にプロジェクト名を指定されてたりすると、確認が難しいというね...
何だろう、docker psとかして、docker inspect [コンテナ名]とかで表示される情報からプロジェクト名とか特定できるんかな？
そもそも、公式が取得できる情報の個々の項目の説明をしてくれていなんよね...
何故か、
⇧ Ubuntuがサンプルを載せてくれてるけども...
Dockerの公式のドキュメントで個々の項目の説明を載せてくれるべきだとは思うんだが...
ちなみに、
⇧ docker-compose.ymlの中で、別のymlを読み込むことができる模様。
う～む、Docker何も分からん...
職場の方に教えていただき、Compose fileを指定で確認するのが良さそう。
docker-compose -f [Compose file] ps
⇧ のような感じ。
ちなみに、「Compose file名（デフォルトは、docker-compose.yml）」のルールはと言うと、
⇧ 特に決まっていなくて、どんな名前でも良いとあるのだけど、公式のドキュメントではその点に触れていなさそうなのよね...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
