DNSのリソースレコードはRFCで定義されています。
有名どころとしては、RFC 1035においてA、CNAME、NS、MX、TXT、SOA、PTRといった基本レコードが一通り実装され、その後RFC 2782において優先度や負荷分散のためのSRVレコードが、RFC 3596においてIPv6のためのAAAAレコードが追加されています。
ところで現在、DNSリソースレコードって何種類あるか知っていますか？
実はDNSに関連したRFCは100以上も提出されており、これまでに発行されたリソースレコードの総数はなんと80を超えています。
そして今年、新たに4つのリソースレコードを追加するRFC 8567が提出されました。
以下はRFC 8567、Customer Management DNS Resource Recordsの日本語訳です。
Customer Management DNS Resource Records
顧客宅内機器管理のためのDNSリソースレコード。
Abstract
増え続けるエンドツーエンドにおいて高いユーザ体感品質(Quality of Experience、QoE)を維持するためには、もはや顧客宅内機器(Customer Premises Equipment、CPE)までをも含む包括的なネットワーク管理が必要となってきます。
顧客宅内機器管理は世界共通の責任であるため、信頼性が高く、パブリックにアクセス可能で、信頼できるインフラであるDomain Name System(DNS)こそが、これらを管理するには理想的な存在です。
このドキュメントは、DNSでCPEを管理するために追加される4種類の新しいDNSレコードタイプについて説明します。
その目的は、プロバイダ間の協力と、顧客との協力によって、より高いQoEを提供することです。
Copyright Notice
Copyright (c) 2019 IETF。
この文書は、BCP 78およびIETF文書に対するIETFライセンスに従います。
1. Introduction
こんにちのインターネットの大部分は、住宅用ネットワークで構成されています。
これらのアクセスネットワークおよびそのプロバイダは、今やクリティカルなインフラストラクチャです。
また、住宅用ブロードバンドの速度と信頼性を保証する重要な研究が行われています。
残念なことに、顧客宅内機器CPEは、顧客をインターネットに接続する一連のネットワーク機器類の中で、最も脆弱な部分のひとつです。
顧客は自分たちのCPEに対して、ファームウェア更新などの予防的保守を行うことは、ほとんどありません。
多くの場合、CPEの認証資格情報はデフォルトのまま使用されています。
このため、インターネット中に存在する多数のサービス拒否攻撃ボットネットMIRAIによって悪用されてきました。
このRFCが必要である主な理由は、顧客が自分のネットワークを管理できるとは信頼できないことであり、従ってパスクリティカルなCPEはほとんど無いということです。
ブロードバンドアクセスの正常性を顧客各自で維持することが困難であることを考えると、CPEの管理は、顧客ではなくインターネットサービスプロバイダ(ISP)が行うべきです。
CPE管理をさらに複雑にするのはISPの選択であり、米国人の半数がその恩恵を受けることができます。
顧客はプロバイダを自由に切り替えることができますが、経歴、請求、技術情報などの詳細は受け継がれません。
従ってISPは、技術的観点からも課金の観点からも、顧客のISPの移行を確実にシームレスに行うメカニズムが必要です。
最後に、ISP、広告主、法執行機関などは、インターネット上でのユーザの行動を追跡するための様々な、そして重要な動機を持っています。
RFC 7043ではEUI48およびEUI64リソースレコード(Resource Record、RR)を使用してCPEを一意に識別し、サードパーティのトラッキングを適切にサポートします。
しかし、このメカニズムは単に新しいネットワーク機器をひとつ追加しただけで無効になってしまいます。
このRFCでは、顧客のQoEとネットワーク全体のセキュリティを向上させることを目的とした、包括的なE2EのCPE管理を取り上げます。
RFC 1034およびRFC 1035のDNSの仕組みを利用し、共有CPE管理を可能とするための新たなRRを提出します。
1.1. Terminology
MUST、MAYなどの使用法についてはRFC 2119、RFC 8174を参照のこと。
2. Customer Management Resource Records
個人へのブロードバンドインターネットサービスの普及は、顧客に多大な利益をもたらしますが、同時にISPは困難な課題に直面することになりました。
ネットワーク上のCPEデバイスの管理とセキュリティの確保を行いながら、機密の顧客IDや請求を適切に管理する方法です。
このRFCでは、IPSの顧客情報管理を助けるために4種類のRRを紹介します。
このセクションでは、各RRの目的とフォーマットについて解説します。
2.1. The PASSWORD Resource Record
PASSWORDリソースレコードは、ひとつのRRでCPEのログイン認証情報を提供することによって、CPEデバイスのリモート管理を容易にします。
これらの資格情報は、CPEの認証が許可されたサービスプロバイダによって使用されます。
認証されたユーザは重要なソフトウェアやアップグレードをインストールし、ネットワークのセキュリティと健全性を高めることができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| USERNAME |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PASSWORD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PASSWORD RDATA Format
USERNAME
CPEを特定するためのユーザ名。
ASCII文字列16文字以下でなければならず(MUST)、句読点を含んではいけません(MUST NOT)。
PASSWORD
USERNAMEに対応するパスワード。
レコードサイズ制限のため、32ビット以上のパスワードには対応していません。
複数の機器を所有するアカウントは、機器毎に別のパスワードを設定するべき(SHOULD)です。
2.2. The CREDITCARD Resource Record
CREDITCARDリソースレコードには、CPEに紐付いたホストの所有者の請求情報が納められています。
IPSに新規加入した際、ISPは、自動引き落としなどの目的のために請求の詳細を登録してもよい(MAY)です。
さらに、顧客がその他の組織に定期支払いサービスなどを申し込んだ際に、該当のサービスはこのレコードに対して請求の詳細を問い合わせることができます(MAY)。
セキュリティの姿勢がバラバラな複数の組織がそれぞれ請求情報を保存するのではなく、RR一カ所に集約して保存することによって、悪意のあるユーザによるデータ詐取のための攻撃手段を減らすことができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CARDNUMBER |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPIRE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CREDITCARD RDATA Format
CARDNUMBER
IPSへの請求に使用する16桁のクレジットカード番号。
句読点やスペースを含んではいけません(MUST NOT)。
ASCIIの数値のみ使用可能です。
このフィールドは16桁固定長であるため、American Expressのカードを使用してはいけません(MUST NOT)。
EXPIRE
有効期限を表す2桁の月と2桁の年。
句読点やスペースを含んではいけません(MUST NOT)。
ASCIIの数値のみ使用可能です。
CHECKSUM
CARDNUMBERフォールドのビットエラーから保護するため、チェックサムを使用しなければなりません(MUST)。
チェックサムにはLuhnアルゴリズムが使用されます。
左端の数値から順にその数値を足していきますが、偶数桁は2倍して足します。
合計値をCHECKSUMフィールドに格納します。
照会者はCREDITCARDリソースレコードへのリクエストを行ったのち、同じアルゴリズムでチェックサムを算出し、それがCHECKSUMと等しいことを検証します。
2.3. The SSN Resource Record
SSNリソースレコードは、ホスト名をアメリカ合衆国の社会保障番号および該当顧客の生年月日にマッピングします。
複数のユーザに紐付けられているCPEの場合は、各ユーザごとに個別のSSNリソースレコードを登録する必要があります(SHOULD)。
米国外で住宅用ブロードバンドサービスを使用する場合は、DNSおよびサービスプロバイダの管理上の負担を軽減するため、SSNと互換性のある識別子を採用しなければならなりません(SHOULD)。
アメリカ合衆国内国歳入庁は、SSNリソースレコードに問い合わせてホストの所有権を確認することがあります(WILL)。
さらに、CREDITCARDリソースレコードと併用することで未払いの税金徴収を自動化することもできます(MAY)。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOCIAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIRTHDATE |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SSN RDATA Format
SOCIAL
ホストに関連付けられているユーザの社会保障番号。
32ビット符号無し整数フォーマットです。
BIRTHDATE
SOCIALのユーザの生年月日を表す64ビットのUNIXタイムスタンプ。
UNIXタイムスタンプは全てのインターネットユーザより前に存在しているため、このフィールドはISPが顧客情報を書き込むのに十分な範囲を持っています。
64ビットのタイムスタンプは2038年問題も無く、実用的範囲内でのリソースレコードの使用に耐えうる十分な桁数です。
2.4. The SSNPTR Resource Record
SSNPTRリソースレコードは、SSNリソースレコードの逆の機能を提供します。
社会保障番号を元にホスト名を解決します。
プライマリアカウント所有者だけではなく、ISPがサービスを提供している全ての顧客に対し、DNSはSSNPTRリソースレコードを返さなければなりません(SHOULD)。
SSNPTRリソースレコードの持つ利点のひとつは、人口調査を遠隔実行できることです。
例として全加入者の情報を持つ住宅用ISPを挙げると、全てのSSNに対してSSNPTRクエリを実行すると、全ての個人のホストが返却され、ひとつのCPE内に存在する家族の人数を簡単に把握することができます。
さらに時尾ロケーションサービス、もしくはRFC 1876が提供するLOCリソースレコードを用いることで、各自治体の人口を把握し、適切な予算配分や公共政策を決定することができるようになります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ DNAME /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SSNPTR RDATA Format
DNAME
DNS内のホスト名を表します。
3. Related RR Types
部分的にしか対応していない機能や、あるいは全く対応していない機能をサポートするためにDNSに新たなリソースレコードを導入する行為は、既に十分に確立された手法です。
RFC 2539ではDiffie-Hellman公開鍵を公開するためのKEYリソースレコードが導入されました。
RFC 2782ではSRVリソースレコードが導入され、ネットワーク管理者が各種サービスの位置を公開する簡単な方法が提供されました。
RFC 2915はドメインを正規表現で記述できるNAPTRレコードを定義し、RFC 3402のようなDDDSの元になっています。
RFC 2539でDNSには暗号化という目的が追加されたため、IPsec暗号化のためのIPSECKEYリソースレコードがRFC 4025で追加されました。
RFC 4255ではSSHサーバの公開鍵を検証するためのSSHFPリソースレコードが追加されました。
DNSで公開鍵のフィンガープリントを配布するという考え方を推し進めた結果、RFC 4398ではX.509やPGPの証明書を配布するCERTリソースレコードが追加されました。
RFC 4701はFQDNの名前衝突を防ぐために、DHCIDリソースレコードを提供します。
RFC 6698ではTLSAリソースレコードにCA証明書を格納し、ドメインで使用しなければならないTLS証明書を限定します。
またRFC 6844のCSSリソースレコードは、証明書を発行することが許可される認証局を指定します。
RFC 7043で追加されたEUI48とEUI64リソースレコードは、MACアドレスに対するAレコードのようなもので、TCP/IPモデルの境界を超えようとしています。
4. IANA Considerations
このRFCはIANAのアクションを必要としません。
5. Security Considerations
PASSWORD、CREDITCARD、SSN、SSNPTRといった各フィールドの完全性を維持するため、DNSSECと共に使用されるべき(SHOULD)です。
DNSSECにより、これらのリソースレコードが信頼できる送信元から発信されたものであり、攻撃者による偽物の応答でないことが保証されます。
Acknowledgements
ISPが顧客に向けて期待を裏切らない品質のサービスを提供できるようにするために、network neutrality legislationを廃止してくれた連邦通信委員会に感謝します。
また、ブログ記事やIETF講演で、DNSリソースレコード規格標準の不足を指摘したBert Hubertに感謝します。
Authors' Addresses
Erik C. Rye
Robert Beverly
感想
家庭内ネットワークを適切に管理している個人なんて存在しませんからね。
ましてや今はレンタルサーバなんて言葉も滅びつつあり、Webサーバもその他のサーバも、あるいは個人の所有するデータですらクラウドで管理する時代です。
ネットワーク機器の管理も、名前のとおりネットワークに任せてしまうのが、もはや自然の成り行きというものでしょう。
でもクレカ番号を直接載せてしまうのはさすがにちょっと怖いですね。
このあたりはクレカ番号そのものではなくクレカ会社から発行されたトークンを保存するといった、PCI DSSのような仕組みを導入してほしいところです。
あと社会保障番号とかのあたりは思いっきりアメリカローカルなので、他国事情にも適応できるように、もう少々余裕を持たせた設計をしてほしいところですね。