JPNIC Blog JPNIC

プライベート用途TLDについてのアドバイザリ -SAC113の紹介-

dom_gov_team 

前回に引き続き、ICANNが公開している技術政策文書シリーズの中からSAC113 SSAC Advisory on Private-Use TLDsを紹介します。

SAC113はICANNのSSACから公開されている、プライベート用途TLDについて運用的・管理的および登録上の側面からの助言を行う文書です。

語彙の説明

各語彙について、本文書内での意味を定義しています。

プライベート用途TLD (private-use TLD)

パブリックDNSルートから解決できるグローバルな名前空間とは別の、プライベートな名前空間で用いられるTLDを指します。パブリックDNSルートから正式な委任を受けていません。

予約済プライベート用途TLD (reserved private-use TLD)

ルートゾーンから委任されたドメイン名と衝突しないように明示的に予約された、プライベートな名前空間用のTLDを指します。

プライベート用途TLDの使われ方と問題点

企業やネットワーク運用者が、パブリックな名前区間に登録されたドメイン名のサブドメインではなく、プライベート用途TLDを使用している理由には以下のようなものが挙げられます。

 

  • 使途が変わる可能性のあるドメイン名について外部から参照されるのを防ぐため。
  • インターネットへアクセスできないときでも確実に名前解決ができるようにするため。
  • インターネットとの接続が意図的に禁止されていたり、接続すると問題が起こるような隔離ネットワーク上でプロダクトを開発・試験するため。
  • 検索リスト処理による望ましくない動作を避けるため。ドメイン名に”.”が存在する場合、リゾルバはそれをFQDNとして扱うため最初にパブリックDNSで名前解決を試みます。例えばwww.corpと入力した場合、リゾルバはwww.corp.example.comと解釈しこのドメイン名をパブリック DNSで名前解決しようとします。SSACでは、運用上プライベートシステムの存在を非公開にしたいという理由で、このようなクエリをパブリックDNSに送信したくない組織があると理解しています。

 

また、2020年にVerisignが管理するルートサーバで行ったクエリの調査では、.home、.internal、.lan、.corp、.localdomain、.dlink、.zyxel-usgといったプライベート用途TLDが実際にクエリされていることが確認されています。詳細な数や想定されるクエリ元についてはここでは割愛しますが、ご興味のある方は原文をご覧ください。

 

ところが、現状のアドホックなプライベート用途TLDの使い方にはいくつか問題があります。これらは当然内部的、もしくはパブリックなインターネットに干渉しない限定されたネットワーク空間での使用が意図されたものですが、実際にはグローバルなDNSインフラに影響して以下のような問題を起こしています。

 

  • TLDがICANNから委任されている場合に名前衝突を起こし、予期せぬ挙動を起こす(SAC045、SAC062、SAC066も参照[1])。
  • 外部からの名前解決時に、オンパス攻撃による安全性の低下と機密性の侵害の可能性がある。
  • ドメイン名がどのようなコンテキストで使用されるのかユーザーにもサービスにも不明確な場合に、名前の曖昧さを引き起こす。
  • グローバルに信頼されている認証局がTLD内のドメイン名に対して発行した証明書に起因するセキュリティリスク(SAC057も参照[2]
  • クリーンな境界内での名前解決のコンテキストにおけるデバッグが困難であること。
  • ルートサーバが実際に委任されていないTLDのクエリを受けるなど、不必要なDNSの負荷の発生。

プライベートIPアドレス空間

ここで成功的な先行例として、IPv4におけるプライベートIPアドレスを見てみます。プライベートIPアドレスは、パブリックなインターネットにおいてサポートされていないことを明確化した上で、プライベートネットワークでのニーズを満たしています。また、複数のネットワークが合併した場合にはプライベートIPアドレス空間が衝突する可能性がありますが、その影響の範囲は合併するネットワークの間にのみ発生し、他のネットワークやパブリックなインターネットに広範な影響を与えることはありません。

 

とはいえ、ネットワークの合併に際して慎重に計画を立てたとしても、プライベートIPアドレス空間の衝突が発生する場合には移行にも継続的な運用にも多大なコストを要することが一般的です。これはプライベート用途TLDでも同じことがいえます。プライベート用途TLDの使用を選択した事業者はその決定がもたらすコストの可能性を理解すべきであり、プライベート用途TLDではなく登録済みの自分のドメイン名のサブドメインを使用することで、そのコストを回避できる可能性があることも理解すべきです。

 

このようにプライベートIPアドレスとプライベート用途TLDには類似点がありますが、いくつかの相違点も挙げられます。1点目として、IPアドレスは人間向けの識別子として使用することを意図していないが、ドメイン名は多くの場合人間向けの識別子であることがあります。そのため、使用するドメイン名の選択には人間とコンピュータの間のインタフェースを考慮する必要があります。2点目として、そもそもプライベートIPアドレスが定義された目的の一つはIPv4アドレスの枯渇が差し迫っていたことであり、TLDにはそのような危機がないことです。3点目として、1990年代にIPv4アドレスを調達できなかった人々にとって、他に取り得るアドレス衝突緩和戦略がなかったことです。そして4点目として、IPには長期的に問題を解決するためのアーキテクチャ変更の必要性とその計画について明確なコンセンサスがあったが、TLDに対してそのようなコンセンサスはないことが挙げられます。

SSACからの提言

プライベート用途TLDのアドホックな使用に起因する問題についての最適なアプローチは、名前空間の中に専用の空間を用意することです。今日選択したプライベート用途TLDが後にルートゾーンに委任されないことを保証することはできません。永続的に専用の名前空間を用意することは、コーディネーションに基づかないアドホックなプライベート用途TLD使用の問題を抑制できると考えられます。

 

すなわち、ICANNが予約済プライベート用途TLDとして使用する文字列を特別に予約することを提言します。

 

この予約された文字列の選定基準として、SSACは以下を提案します。

 

  1. 有効なDNSラベルであること。
  2. 既にルートゾーンに委任されていないこと。
  3. 現存する他のTLDと紛らわしい類似性がないこと。
  4. 比較的短く、記憶しやすく、意味のある文字列であること。

 

ただし、SSACはあくまで、ほとんどの場合においてグローバルに登録されたドメイン名のサブドメインを使用することが最良の選択肢だと考えています。これが現実的でない場合のために選択肢の一つとして、予約された文字列のサブドメインを使用することを提案しています。また、他の選択肢も存在すると思われるし、将来的にはもっと多くの選択肢が考案されるでしょう。その選択は、利用可能なすべての選択肢を考慮に入れ、具体的な要件を考慮した上で注意深く行われるべきです。

勧告

勧告1: SSACはICANN理事会に対し、セクション4.1で指定した基準で文字列を選定し、プライベート利用のためにトップレベルで予約することを勧告します。この文字列は絶対に委任されるべきではありません。

まとめ

非中央集権的で自由な名前空間を持つDNSだからこそ、ネットワーク設計者はグローバルな名前空間とプライベートな名前空間が衝突する可能性を考慮する必要があります。実際に、名前空間を分離したからといってその目的を達成できているとは限らず、プライベート用途TLDがルートサーバにクエリされていることも本文書で示されました。ネットワークや名前空間の設計において、どのような目的で名前空間を分離するのか、その目的の達成には本当にプライベート用途TLDを用いるのが最適解なのか、広い目で選択肢を集めることが重要です。また、将来的にはその選択肢として、ICANNによる予約済プライベート用途TLDの使用が加わるかもしれません。

なお、2023年9月10日に開催されたICANN通常理事会の中で、本文書の勧告1について文字列の選択を行うように動き始めています。詳細はJPNIC Webにも掲載しています。

[1] SAC045 Invalid Top Level Domain Queries at the Root Level of the Domain Name Systemはルートサーバへの無効なTLDクエリについてまとめている文書、SAC062 SSAC Advisory Concerning the Mitigation of Name Collision Risk及びSAC066 SSAC Comment Concerning JAS Phase One Reporton Mitigating the Risk of DNS Namespace Collisionsは名前衝突リスクの最小化についてまとめている文書です。

[2] SAC057 SSAC Advisory on Internal Name Certificatesは内部的なドメイン名に対する証明書発行についてまとめている文書です。

この記事を評価してください

この記事は役に立ちましたか?
記事の改善点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、 お問い合わせ先 をご利用ください。