Views: 19
OpenPeppolが目指す方向:分散型DNSディスカバリー(NAPTR)への移行
1. 背景
OpenPeppolは現行のPeppol eDeliveryネットワークにおいて、SML (Service Metadata Locator)を中心としたディスカバリモデルを採用しています。
しかし、下記のような問題点が指摘されています。
-
SMLが協調中央点となり、単一障害点 (SPOF[1])を生じる
-
参加者数の増大とともにSMLの運用負荷が増大
-
国別の自立運用に対応しにくい
これらの認識から、OpenPeppolは「DNS分散型ディスカバリー」への移行を目指しています。
2. 従来の方式:CNAMEアドレス解決
従来のPeppolディスカバリでは、SMLから得られた情報をもとに、CNAME (Canonical Name)レコードを用いてSMPサーバのドメイン名を取得する方式が採用されています。CNAMEレコードは、ドメイン名の別名情報を提供し、最終的にSMPサーバのAレコード(IPアドレス)を解決します。
この流れにより、Participant IDに紐づくSMPサーバをDNSベースで発見できる仕組みとなっていますが、SMLという中央リポジトリに依存しているため、依然として単一障害点や柔軟性の課題が残っていました。
3. OpenPeppolの分散型ディスカバリー模式
3.1. 現在の流れ(CNAME方式)
3.2. 目標とする流れ(Naming Authority Pointer NAPTR方式)
注1:NAPTRディスカバリーではNAPTRとSRVレコードだけでなく、最終的に接続するためにIPアドレスを取得するQuery A/AAAAステップも必須となる。
注2:送信先がエンドポイントのC4となる3コーナーモデルだが、AS4プロトコルの受信ソフトを用意しているC4は期待できないので従来同様にC3が代理受信しC4に転送する形態と思われる。
4. CNAME方式とNAPTR方式の比較
項目 | CNAME方式 | NAPTR方式 |
---|---|---|
中央依存 |
必須(SML必須) |
不要(完全分散型が可能) |
柔軟性(複数プロトコル対応) |
低い(基本HTTP系に固定) |
高い(AS4, REST, 将来gRPCにも対応可能) |
フォールトトレランス |
SMLに障害があると全体停止 |
権威DNSサーバーに分散され、局所障害に限定 |
標準化準拠性 |
Peppol独自仕様に近い |
OASIS BDX-Location準拠、国際標準互換 |
ドメイン管理の柔軟性 |
中央SMLに登録されたドメインに限定 |
DNSのサブドメイン分散管理が可能 |
5. NAPTRディスカバリーとは
Participant IDを基に、DNSに対しNAPTR[2]クエリを発行し、サービス種別やプロトコル情報を含むレコードを取得する手法です。
eDEC更新:移行に伴う想定影響
-
AP(Access Point)およびSMPサービスの両方が影響を受ける
-
移行作業のタイミングが非常に重要である
-
幸いなことに、EC(欧州委員会)のSMLソリューションは既にU-NAPTRレコードを生成している
例:Participant ID「9915:test」をSMK環境で解決する場合、次のNAPTRアドレスが使用される:
EH5BOAVAKTMBGZYH2A63DZ4QOV33FVP5NSDVQKLUCFRAAYOODW6A.iso6523-actorid-upis.acc.edelivery.tech.ec.europa.eu
Linuxコマンドラインからのクエリ例:
dig -t naptr {fullDomainName}
レスポンス例(1行にまとめられたDNSレコード)
EH5BOAVAKTMBGZYH2A63DZ4QOV33FVP5NSDVQKLUCFRAAYOODW6A.iso6523-actorid-upis.acc.edelivery.tech.ec.europa.eu. 60 IN NAPTR 100 10 "U" "Meta:SMP" "!.*!http://test-infra.peppol.at!" .
上記参考資料中の注意事項:
-
APプロバイダはこのテーマについて既に検討を開始してよいが、現時点では何も変更しないこと
-
SMPプロバイダは、移行計画が確定するまで対応を控えること
6. NAPTR導入後の受信構成モデル
NAPTRによる分散型ディスカバリーが導入されても、Peppolの基本設計である4コーナーモデルは維持されるものと思われます。
多くのC4(エンドユーザー企業)は自らAS4受信用サーバを持たないため、受信用AP(C3)を通じて受信する実態運用となります。このため、運用上は「3コーナーモデル」に近い構成になると思われます。
この構成では:
-
C4は受信AP(C3)にAS4受信を委託
-
C2は受信AP(C3)のエンドポイントへUBLメッセージを送信
-
C3はC4に対してメッセージを引き渡す
7. NAPTR導入のメリットと課題
7.1. メリット
-
中央SMLに依存しないため、単一障害点(SPOF)の排除
-
複数プロトコル(例:AS4, RESTなど)への柔軟な対応
-
DNSベースのため、エンドポイント更新が迅速
-
地域ごとの分散管理が可能(各国ドメイン運用)
-
新規サービスやプロバイダ間競争の促進
7.2. 課題
-
既存のAPソフトウェアのDNSクエリ機能強化が必要
-
NAPTR/SRV/Aレコードの運用・設定ノウハウ不足
-
一部小規模事業者にとってDNS管理負荷が増加
-
セキュリティ面でのDNSベース運用リスク(DNSSEC対応など)
-
従来の4コーナーモデル運用との整合性維持の検討
7.3. GENAプロジェクトとの関連
Peppolネットワークの分散型ディスカバリーへの移行は、欧州委員会が推進するGENA(Generic eDelivery Access)プロジェクトとも整合しています。
GENAでは、中央集権的なSML依存を回避し、eDeliveryネットワーク全体をより分散化・自立的に運用できるインフラ構築が目指されています。
NAPTRベースのディスカバリー方式は、GENAにおける分散型アクセス設計方針とも一致しており、Peppolが次世代グローバルeDeliveryインフラの一環を担うための重要な布石と位置付けられます。
さらにGENAでは、単なる分散型ディスカバリーに留まらず、ネットワーク全体の信頼性を確保するためのTrust Framework構築も検討されています。
従来は、プロバイダーがD4のKYCに責任を持っていましたが、NAPTR方式ではName Serverはこの要求水準のKYCを担保できない問題もあります。このTrust Frameworkでは、以下が重視されます:
-
参加者(エンティティ)認証と識別の標準化
-
信頼できる証明書とメタデータ発行手続き
-
参加者の属性情報(役割、スコープ)管理
-
攻撃防御(DNSSEC、メタデータ署名等)を考慮したエコシステム設計
これらにより、単純なDNS分散だけでなく、信頼性を維持したeDeliveryネットワークを実現しようとしています。
参考:
– eInvoicing Documentation
– https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/GENA+Project
GENAについては、こちらの記事もご確認ください。
『eB2B: OpenPeppolと他のEDIシステムの連携に関する解説』
これらにより、単純なDNS分散だけでなく、信頼性を維持したeDeliveryネットワークを実現しようとしています。
8. 日本におけるNAPTR運用上の注意点
Peppol分散型ディスカバリーで要求されるNAPTRレコード管理について、日本国内の一般的なレジストラサービス(例:お名前.com、Xserver)では標準対応していないのが現状です。
そのため、NAPTRレコードを設定するには:
-
専用のプロフェッショナルDNSホスティングサービス(AWS Route 53、Cloudflare DNSなど)を利用する
-
もしくは独自にDNSサーバを運用する
必要があります。
今後Peppolネットワークに参加する事業者は、ドメイン取得時に「NAPTRレコードが管理できる環境」を確保しておくことが必要かもしれません。
下記は、ChatGPTが提示した未確認情報です。PAやEIPAでの調査が必要でしょう。
サービス名 | NAPTRレコード対応 | 備考 |
---|---|---|
お名前.com |
× |
管理画面で設定不可、個別交渉も難しい |
Xserver |
× |
設定不可 |
ConoHa DNS |
× |
設定不可 |
AWS Route 53 |
○ |
標準機能で設定可能 |
Cloudflare DNS |
○ |
標準機能で設定可能(無料プランでも可能) |
Google Cloud DNS |
○ |
標準機能で設定可能 |
SakuraのVPS/Baremetal DNS |
△ |
手動ゾーンファイル編集で可能(高度な運用要) |
9. EUとの比較と日本における課題
CEF(Connecting Europe Facility)は、欧州委員会が推進するインフラ支援プログラムであり、欧州域内における交通、エネルギー、デジタルネットワーク(eDelivery、eID、eInvoicingなど)を横断的に整備・接続することを目的としています。
特にデジタル分野(CEF Digital)では、以下のビルディングブロックが提供されています:
-
eDelivery(標準化された安全なデータ交換インフラ)
-
eID(相互運用可能な電子ID認証)
-
eSignature(電子署名と検証インフラ)
-
eSeal(電子印鑑)
-
eArchiving(電子保存)
これらにより、加盟国間および事業者間で相互運用可能なデジタル環境が整備され、PeppolネットワークやGENAプロジェクトもこのインフラ支援を基盤に整備が進められています。
一方で日本では、これに相当する包括的なデジタル共通基盤(国家レベルの標準eID、eSeal、eDeliveryインフラ)が未整備であり、将来的な国際連携に向けた大きな課題となっています。
さらに、EUではeIDAS規則に基づき、Qualified Trust Service Provider(QTSP)制度が整備されています。QTSPは、各国政府に認定された高信頼の電子署名・電子証明書発行事業者であり、法的効力を持つQualified Electronic Signature(QES)を発行することができます。これにより、高度な本人確認や電子証明、電子署名の信頼性が制度的に保障されています。
一方で日本では、これに相当する包括的なデジタル共通基盤(国家レベルの標準eID、eSeal、eDeliveryインフラ)が未整備であり、将来的な国際連携に向けた大きな課題となっています。
なお、日本においてはデジタル庁が発行するGビズIDを活用することが考えられます。GビズIDは法人・個人事業主向けの共通認証基盤であり、もしデジタル庁がISO/IEC 6523(国際識別子体系)に基づく発番機関として登録されれば、GビズIDを国際標準に準拠した参加者IDとして利用できる可能性があります。
これに加え、GビズIDに対して電子証明書(eシール)を発行し、電子文書への付与を義務化することで、ディスカバリー時に信頼できるエンティティ情報を確保できるようになり、NAPTRベースの分散型ディスカバリー環境でもEU並みの信頼性を持つ運用が実現可能となります。
10. 参照先URLと概要
-
https://docs.oasis-open.org/bdxr/BDX-Location/v1.0/BDX-Location-v1.0.html
→ OASISが策定したBDX-Location仕様。NAPTR、SRV、A/AAAAレコードを用いたメタデータサービスディスカバリ標準を定義。Peppol分散型ディスカバリーの技術基盤となる。 -
https://openpeppol.atlassian.net/wiki/pages/viewpageattachments.action?pageId=3892150275&preview=%2F3892150275%2F3891167248%2FService%20Provider%20Community%20Meeting%20November%2019th%202024.pdf
→ 2024年11月に開催されたOpenPeppol Service Provider Community Meeting資料。NAPTR方式移行に伴う影響、U-NAPTRレコード運用状況、AP/SMPプロバイダへの移行計画に関する議論がまとめられている。
11. 用語集
11.1. ディスカバリ関連
- SML
-
Service Metadata Locator. 参加者IDからSMPを検索するための中央レジストリサーバー。
- SMP
-
Service Metadata Publisher. ドキュメントに対応するサービス資料を供給するサーバ。
- NAPTR
-
Naming Authority Pointer Record. DNSにおいてサービス種別や次の解決先を示すためのポインタ型レコード。
- CNAME
-
Canonical Name Record. DNSでドメイン名の別名を定義するレコード種類。
11.2. 通信関連
- Endpoint
-
AS4やRESTなどで連絡を受け付けるサーバの端点。
- DNS
-
Domain Name System. ドメイン名をIPアドレスに変換する分散型データベースシステム。
- SRV Record
-
DNSにおけるサービスロケーションレコード。特定サービスの提供サーバ情報を提供。
コメントを残す