.internal
@jj1lfc: @flano_yuki 一点付け加えておくと，議論の元になったアドバイザリ (SAC113) では，プライベート用途ドメイン名が予約された場合でも，すでに委任されたドメイン名のサブドメイン (つまり自社ドメイン名からサブドメインを出す) を使うのが最善とされています→ って書かれてて調べた
プライベート用途TLDのアドホックな使用に起因する問題についての最適なアプローチは、名前空間の中に専用の空間を用意することです。今日選択したプライベート用途TLDが後にルートゾーンに委任されないことを保証することはできません。永続的に専用の名前空間を用意することは、コーディネーションに基づかないアドホックなプライベート用途TLD使用の問題を抑制できると考えられます。
確かに懸念されている
Claude.iconに聞いてみる
SAC113が懸念していた「アドホックな私的TLD使用」の問題は、実はもう解決されています。SAC113の勧告を受けてICANNが4段階の選定プロセスを進めた結果、2024年7月29日にICANN理事会が.INTERNALをDNSルートゾーンへの委任から永久に予約する決議を可決しました。これはSAC113が2020年9月に「プライベート用途のために予約する文字列をDNSトップレベルで特定・予約すべき」と勧告したことへの直接の対応で、その文字列は絶対に委任されないという条件付きです。選定プロセスでは最終的に「INTERNAL」が私的用途トップレベルドメインの提案文字列として特定されました。 ICANN + 2
つまり wsoft.internal は、.corp や .home や .dlink のような「後で誰かに取られるかもしれないアドホックな私的TLD」ではなく、ICANNが公式に「絶対にルートゾーンに委任しない」と決めた文字列を使っていることになります。SAC113が心配していたコリジョンリスクは、この選択に関しては構造的に排除されています。
一点補足しておくと、「internal」と「alt」(RFC 9476) は別の目的で予約されていて、altは非DNSコンテキスト用、internalはプライベートDNSコンテキストでのDNSプロトコル利用を意図したものなので、Unboundで普通に名前解決する今回の用途にはinternalの方が適切です。ただし正式なIETF仕様はまだドラフト段階(draft-davies-internal-tld)で、Board決議による予約が実体という状況です。 IETF
実務上の注意点としては、.internal はパブリックCAからの証明書発行ができません(ドメイン検証がグローバルDNSに解決できることを前提にしているため)。もし内部サービスにLet's EncryptなどでDNS-01チャレンジ経由の正規TLS証明書を当てたいなら、サブドメインに乗せる選択肢の方が有利です。逆にプライベートCAで完結させる前提なら .internal の方が短く書けて意図も明確です。
これか〜いいことしてくれた