要約

  • ENUMはE.164番号からDNS keyを作り、NAPTR ruleを処理してURIを出力する。そのURIは利用候補となるservice contactであり、完了したcommunication sessionではない。
  • 信頼できるcall recordは、番号利用権のvalidation、DNSSEC、選択されたNAPTR、生成URI、接続先認証、signaling、双方向mediaの観測を分離して残す。

運用画面にE.164番号を入れる。区切り記号が除かれ、数字が逆順に並び、e164.arpaの名前ができる。NAPTR RRSetはDNSSEC検証を通り、clientはSIP URIを生成した。画面は成功を示す。しかし次の名前解決先が古い、providerがINVITEを拒む、端末が鳴らない、あるいはsignalingが成立しても音声が片方向だけ、ということは起こり得る。

ENUMの答えが誤っていたとは限らない。「resolved」を「connected」に置き換えた表示が、URI以後の工程を消している。

RFC 3761はPatrik FältströmとMichael Meallingの共同著作として2004年にStandards Trackで公開された。2011年にはScott Bradner、Lawrence Conroy、Kazunori FujiwaraによるRFC 6116がこれをobsoleteにした。後者はFältströmとMeallingが編集した文書の更新であると明記する。ENUMは改訂を重ねた共同標準であり、一人の所有物でも現場判断でもない。

この仕組みが約束するのは、電話番号からDNSを用いてURIを発見できることだ。DNSが電話交換機、番号割当機関、会話の証人になるわけではない。

正しいkeyと現在の番号利用権

RFC 6116は最初にApplication Unique Stringを作る。完全なE.164番号から空白、括弧、ハイフンなどを除き、先頭のplus signを残す。First Well Known Ruleはplus signを除き、数字を逆にし、一桁ごとにdotを挟み、末尾に.e164.arpa.を付ける。こうしてENUM用のDNS keyが得られる。

この変換が正しいことは、問い合わせ方が仕様どおりだと示すだけである。queryを発した人物を認証せず、番号の現在のassigneeも示さない。番号移転、validationの遅れ、権限のない入力元は別問題だ。syntaxの正しさは制度上のprovenanceを補えない。

keyからNAPTRを問い合わせる。terminal ruleは最終出力を作り、non-terminal ruleは次のdomain nameと次のqueryを生む。DDDS loopの期待出力はabsolute URIである。ENUMの終了点はaddress expressionであって、call stateではない。

RFC 3403はruleをORDER、PREFERENCE、FLAGS、SERVICES、REGEXP、REPLACEMENTに分ける。どのrule groupを先に処理し、同順位の候補をどう並べ、値をどう解釈・書換えたかが選択理由になる。URIだけ保存すれば、その理由は失われる。

一つのruleが返っても判断は残る

RFC 6116の「ENUM algorithmは常に一つのRuleを返す」という記述は、電話の実行結果ではない。applicationは一部のEnumserviceだけを実装し、private recordや不正なrecordを捨て、複数URLを利用者に示すことができる。application固有の知識も選択に入る。

RRSetはORDER、次にPREFERENCEでsortする。同じ値のrecordについてDNS packet内の順序を安定した優先順位とみなしてはいけない。同じ集合でもresolverによって並びが変わり得る。

registrantの好みも命令ではない。RFCは、最も低いpreferenceのcontactでも利用者に選ばれ得るため、支援する意思のあるcontactだけをzoneに置くよう求める。これは現在の到達性、clientのscheme対応、次のproviderによる承認を保証しない。

auditには全NAPTR、TTL、order、preference、service、flag、rewriteを残す。clientが対応するEnumserviceと、各候補を採用・無視・拒否した理由も必要だ。最終URIだけでは、policyに従ったのか、tieがあったのか、cacheが古かったのか、compatible candidateがなかったのか判定できない。

番号の権利は上流で検証される

ENUM domainは通常のfirst-come型domainと違い、E.164 assignmentに結び付く。RFC 4725はNumber Assignment Entity、番号を使う権利を持つassignee、ENUM registrant、Validation Entity、registry、registrar、DNS provider、application providerを分離する。

Validation Entityはregistrantがassignee本人か、その承認を受けた者かを確認する。initial validationだけでは委任期間全体を覆えない。番号の状態や所有が変わればrevalidationし、条件が消えればdelegationをrevokeする必要がある。

この履歴が各NAPTR応答に自動添付されるわけではない。resolverは署名DNS dataを検証できても、直近のnumber portability、validation method、local policy decisionを知らない。「nameが存在した」と「registrantが今も番号を管理している」は別のclaimである。

古いrecordが直ちに不正行為を示すわけでもない。TTLの残存、zoneごとの更新時刻、revoke伝播の遅れがあり得る。調査にはassignment version、validation時刻と方法、expiry、delegation change、clientが実際に受け取ったdataが必要だ。

DNSSECはservice peerまで認証しない

RFC 6116はDNSSECでDNS dataのauthenticityを確認し、多くの攻撃を緩和できるとする。同時に、DNSSEC付きENUM lookupでaddressを得ても、そのaddressのentityが意図したservice peerである保証にはならないと明記する。

service setupの中でpeerを別途認証しなければならない。外部で得たaddressやidentity dataは代替にならない。DNSSECは「署名されたDNS chainのdataか」を答えるが、「後で応答するsoftwareは誰か」を先取りしない。

cacheはさらに時間差を持ち込む。RFCのSIP例では、ENUM URIの後にSIP domainのNAPTR、SRV、host addressを順に調べ、ようやくuser agentがsessionを試みる。それぞれのzoneとTTLは異なる。各recordが真正でも、組合せが同じ時点を表さないことがある。

DNSSEC statusだけでなく、signature validity、resolver、cache age、negative answer、下流query chainを保存する。その後、signaling attemptを実際に認証したpeerへ結び付ける。

voice URIは次のprotocolの入口

RFC 4415はvoice:tel Enumserviceを登録した。生成されたtel: URIはinteractive voice callを開始するために使える。dialerはPSTN/PLMNへ直接、またはIP providerとgatewayを介してcallを置く。

「開始できる」はcapabilityの境界である。clientはtypeとsubtypeを支援し、providerは認証、認可、routing、accept/rejectを行う。遠端はring、redirect、timeout、answerのいずれにもなり得る。mediaはその後に別pathを確立する。NAPTR resultにはこれらの状態がない。

SIP URIならRFC 3261の別protocolへ渡される。SIPはprospective participantを探し、sessionを作成・変更・終了する。authentication、authorization、invitation、provisional/final response、ACK、dialog stateを持つ。ENUMは入力URIを提供するだけで、そのstate machineを実行しない。

signalingのacceptも会話の証明ではない。双方向音声、人の応答、利用時間、billing resultにはmediaとapplicationの観測が要る。privacyに配慮し、内容ではなく必要最小限の状態を保存すべきである。

receiptを順番に接続する

前半はoriginal number、normalization、DNS key、resolver、query time、DNSSEC、RRSet、TTL、non-terminal rewriteからなる。次にclient capability、candidate、selection reason、final URIを記録する。

後半はdownstream resolution、authenticated peer、provider authorization、signaling request、transaction ID、responses、ACK、termination reasonである。その後に初めて、想定media endpointの双方向packetとusable windowを述べられる。

一段が成功し、次段が失敗するのは矛盾ではない。この粒度が、失効delegationと古いcache、unsupported serviceとunreachable host、wrong peerとunauthorized caller、成立signalingとone-way audioを区別する。

出典