NAPTR_record
Name Authority Pointer ( NAPTR ) は、インターネットのドメイン ネーム システムにおけるリソース レコードの一種です。
NAPTR レコードは、インターネット テレフォニーのアプリケーションで最も一般的に使用されます。たとえば、Session Initiation Protocol (SIP) でのサーバーとユーザー アドレスのマッピングなどです。NAPTR レコードとサービス レコード (SRV) を組み合わせることで、複数のレコードを連鎖させて、新しいドメイン ラベルまたはUniform Resource Identifier (URI) を生成する複雑な書き換えルールを形成できます。
NAPTR レコードの DNS タイプ コードは 35 です。
コンテンツ
1 根拠
2 例
3 サポート
4 参考文献
根拠
Uniform Resource Name ( URN ) は、人の名前や電話番号などの抽象的な識別子に使用されるUniform Resource Identifier ( URI ) のサブセットです。URN を意味のあるものにするには、何らかの具体的なリソースにマップする必要がUniform Resource Locator ( URL ) は、コンピューターのホスト名やローカル ファイルなどのリソースを記述するためによく使用されます。
NAPTR レコードは、URN の標準化に役立ちます。NAPTR レコードは、一連の URN、URL、およびプレーンドメイン名をマッピングし、マッピングされたリソースとの通信に使用できるプロトコルをクライアントに提案します。各 NAPTR レコードには、サービス名、一連のフラグ、正規表現ルール、順序値、設定、および置換パターンが含まれています。複数のレコードをカスケードに連鎖させて、決定論的な方法で URI を書き換えることができます。これらのカスケード ルールは、RFC2915 および RFC3403 で標準化されています。
例
NAPTR レコードの一般的な用途はSession Initiation Protocolであり、IP ネットワーク経由でテレフォニー セッションをルーティングするために使用されます。たとえば、米国の電話番号 1-800-555-1234 の SIP URN はtel:+1-800-555-1234であり、そのドメイン名は 4.3.2.1.5.5.5.0.0.8.1.e164.arpa です。その名前を照会する SIP クライアントは、次を受け取る場合が
$ORIGIN 4.3.2.1.5.5.5.0.0.8.1.e164.arpa。IN NAPTR 100 10 “U” “E2U+sip” “!^.*$!sip:[email protected]!” .IN NAPTR 102 10 “U” “E2U+email” “!^.*$!mailto:[email protected]!” .
最初のレコードの順序値は 100 で、102 よりも小さいため、優先されます。優先順位 100 は、他に順序 100 のルールがないため、重要ではありません。サービス名 E2U+sip は、電話番号から SIP-URI へのクエリでレコードを使用できることを示すENUM文字列です。クライアントは正規表現!^.*$!を適用します。sip:[email protected] ! これは、URN tel:+1-800-555-1234全体をsip:[email protected]に置き換えます。フラグUは、置換文字列が SIP URN であり、それ以上のルールを適用しないことを示します。
SIP URN を解決するために、クライアントはexample.comで 2 回目の NAPTR ルックアップを実行します。
$ORIGIN example.com.IN NAPTR 100 10 “S” “SIP+D2U” “!^.*$!sip:[email protected]!” _sip._udp.example.com.IN NAPTR 102 10 “S” “SIP+D2T” “!^.*$!sip:[email protected]!” _sip._tcp.example.com.
最初の例のように、クライアントは注文値が最も低い最初のレコードを選択します。正規表現ルールは、クエリの URN を、今回はドメイン名_sip._udp.example.comに置き換えます。フラグSは、結果のドメイン名がSRV レコードを指していることを示します。したがって、クライアントは_sip._udp.example.comで終了し、SRV レコードを取得してテレフォニー コールを開始できます。
サポート
ベンダー
製品
NAPTR サポート?
ISC 練る はい
CZ.NIC ノット DNS はい
シスコシステムズ CNR はい
ダニエル・J・バーンスタイン DJBDN 汎用レコード、またはパッチ
ブルーキャット ネットワーク 威厳 はい
効率的なIP SOLIDサーバー
はい
グーグル Google Cloud DNS はい
インフォブロックス Infobloxトリンジック アプライアンス
はい
マイクロソフト Windows Server 2003 DNS サーバー
いいえ
マイクロソフト Windows Server 2008 R2 DNS サーバー
はい
マイクロソフト Azure DNS いいえ NS1 mDNS と DDI
はい
PowerDNS / Open-Xchange PowerDNS はい
NLネットラボ NSD はい
アマゾン ウェブ サービス アマゾン ルート 53 はい
サム・トレンホルム
マラDNS のバージョン 1.4
ユニックスサービス、LLC。
unxsBind はい
サイモン・ケリー
Dnsmasq はい
F5ネットワークス F5 Networks BIG-IP DNS
はい OVH DNS はい
DNS.com 51DNS DNS
いいえ
シトリックス システム NetScaler GSLB
はい
スノム Snom VoIP 電話 はい
イーリンク イーリンク電話 はい
VoIP ダイヤル
はい
クラウドフレア Cloudflareの権威DNS はい
ワイヤレス ブロードバンド アライアンス オープンローミング
はい
複数の NAPTR レコードを返す応答は通常、通常の 512 バイトのパケット サイズ制限よりも大きく、それ以外の場合は UDP ではなく TCP への効率の悪いフォールバックが必要になるため、 NAPTR 実装は一般にEDNSも実装します。
参考文献
^ ミーリング、M; Daniel， R （2000)、RFC2915: The Naming Authority Pointer (NAPTR) DNS Resource Record、IETF Network Working Group
^ Mealling， M （2002)、RFC3403: Dynamic Delegation Discovery System (DDDS)、パート 3: ドメイン ネーム システム (DNS) データベース、IETFネットワーク ワーキング グループ
^ Sollins， K (1998)、RFC2276: 統一リソース名解決のアーキテクチャ原則、IETFネットワーク ワーキング グループ
^ van der Berg， Rudolf （2010-01-13)， ENUM: Dragging telephone numbers into the Internet Age ， Ars Technica
^ 「CloudDNS ドキュメント」. 2018 年4 月 25 日閲覧。
^ 「MaraDNS の更新」. 2009 年1 月 17 日閲覧。