DNS による service discovery 関連の RFC/I-D のまとめ 2023-FEB-10 @r_takashima 1

本資料の目的 n本資料の目的 Ø「仮想基盤、アプリケーション基盤におけるサービスディスカバリ」 を理解する為に、 「DNSにおけるサービスディスカバリ」 は現在どういった文脈でIETFで標準化されているかを調査しはじめた。 が、現時点での動向としては全く前者の目的には合致しないことが判明した。 なんだかもったいないので記録を残し共有することにした。 Ø本資料では、IETF dnssd WG のドキュメントを中心に読み解いていく。 https://datatracker.ietf.org/wg/dnssd/documents/ 2

目次 1. 元々の DNS-SD (RFC 6762, 6763) 2. IETF dnssd WGで標準化されたRFC 3. IETF dnssd WGで議論中のI-D 3

1. 元々の DNS-SD 1-1. RFC 6763 と周辺のRFC 1-2. RFC 6762 Multicast DNS 1-3. RFC 6763 DNS-Based Service Discovery 4

nZeroconf ØIETF zeroconf WG https://datatracker.ietf.org/wg/zeroconf/about/ Øスコープとしては、インタフェース、IPアドレス、サービスディスカバリを含む、幅広い意味でのネット ワークの Zero Configuration を目指していたが、成果物としては RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses にとどまる。 その後の活動として、Apple Bonjour を標準化したものである RFC 6762 Multicast DNSや、 Microsoft LLMNR (RFC 4795）があるが後者は Infomartional かつ絶滅気味。 Ø本資料で”Zeroconf”と言った場合には、IETF zeroconf WGの元々の目指していたスコープを 指す。 1-1. RFC 6763 と周辺のRFC 5

2013にAppleに標準化されたRFC群 1-1. RFC 6763 と周辺のRFC cont. 6 RFC 6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP) RFC 6763 DNS-Based Service Discovery RFC 6761 Special-Use Domain Names RFC 6762 Multicast DNS プライベートアドレス逆引き、 test.、localhost.、invalid. example., example.{com,net,org}等 の特殊用途ドメインを再定義 AppleTalk NBPをIPに移行する際の要件 RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses 2005にzeroconf WG で標準化されたRFC Proposed Standard Proposed Standard Informational Standard Standard

1-2. RFC 6762 Multicast DNS n超概要 Ølocal.、254.169.in-addr.arpa.、[89ab].in6.arpa. ドメインを主な対象としたリンクローカルへのマルチ キャストのDNS通信 ØApple Bonjourや、OSSのAvahi等で利用。というか、Bonjour内のプロトコルを標準化したもの n動作 1. クライアントが同一リンク内のマルチキャストアドレスにDNSクエリを送信 (*) 2. クエリと一致する条件を持つホストが同一リンク内のマルチキャストアドレスにDNS応答を送信 3. DNS応答を受け取った同一リンク内のホスト達は自分の持つキャッシュエントリを更新 (*) (*) 不要なマルチキャスト応答を防ぐ為に、unicast-response bit のオプションも有り 7

1-2. RFC 6762 cont. nパラメータ nその他 üMulticast DNS ドメインにはNS、SOAもなくゾーン転送もない。 üキャッシュエントリの最適化や更新、通信量の削減に関連する仕様が記述されているが省略 8 項目 値 備考 Destination Address 224.0.0.251/FF02::FB Destination Port 5353 Source Port 5353 or それ以外 Src: UDP 5353<> Dst: UDP 5353の場合はサービスディスカ バリの様な継続的なモニタリングパケットになる。 One-shotでの名前解決では、Src: UDP 5353を使わない。

1-3. RFC 6763 DNS-Based Service Discovery n超概要 ØDNSのPTR,SRV,TXTレコードを用いたZeroconf、サービスディスカバリの仕組み ØMulticast DNSとの併用を想定。 Unicastでも他の仕組みと併用する事で利用できる。 本資料ではZeroconfの文脈ではMulticast DNSを前提とする。 9

1-3. RFC 6763 cont. n動作(1)サービスインタンスの検索 1. クライアントは . のPTRレコードを検索する 2. クエリと一致する条件を持つホストが同一リンク内のマルチキャストアドレスにDNS応答を送信 ØPTRの結果としてサービスインタンスの一覧を返す 10

1-3. RFC 6763 cont. n動作例 (RFC 6763 Section 13.1) Ø“dns-sd.org” で HTTP で提供されているサービスインスタンス一覧を調べる (*) サービスインタンス名は通常のホスト名ラベルの制約を受けずUTFが使える。一方、dig等の通常動作ではUTFは puny code encodingで返そうとする為、場合によってはラベル<64octetsの制限に引っかかる。その場合、dig に +noidnnout をつけないと、文字数制限に引っかかって表示されない 11 $ dig +noidnout +norec ptr _http._tcp.dns-sd.org. @ns1.bolo.net ~~snip~~ ;; QUESTION SECTION: ;_http._tcp.dns-sd.org. IN PTR ;; ANSWER SECTION: _http._tcp.dns-sd.org. 60 IN PTR ¥032*¥032BBC,¥032World¥032news._http._tcp.dns-sd.org. _http._tcp.dns-sd.org. 60 IN PTR ¥032*¥032CNN,¥032World¥032news._http._tcp.dns-sd.org. _http._tcp.dns-sd.org. 60 IN PTR Stuart¥226¥128¥153s¥032Printer._http._tcp.dns-sd.org. ~~snip~~ _http._tcp.dns-sd.org. 60 IN PTR ¥032*¥032Zeroconf._http._tcp.dns-sd.org. _http._tcp.dns-sd.org. 60 IN PTR ¥032*¥032Multicast¥032DNS._http._tcp.dns-sd.org. ~~snip~~

1-3. RFC 6763 cont. n動作(2)サービスインタンスの情報の検索 1. クライアントは .. の SRV, TXT RR を検索する 2. クエリと一致する条件を持つホストが、SRVでIP Address, Port情報を、TXTで付加情報を返す 12

$ dig +norec srv "¥032*¥032Multicast¥032DNS._http._tcp.dns-sd.org." @ns1.bolo.net ~~snip~~ ;; ANSWER SECTION: ¥032*¥032Multicast¥032DNS._http._tcp.dns-sd.org. 60 IN SRV 0 0 80 multicastdns.org. ~~snip~~ $ dig +norec txt "¥032*¥032Multicast¥032DNS._http._tcp.dns-sd.org." @ns1.bolo.net ~~snip~~ ;; ANSWER SECTION: ¥032*¥032Multicast¥032DNS._http._tcp.dns-sd.org. 60 IN TXT "txtvers=1" "path=/” ~~snip~~ 1-3. RFC 6763 cont. n動作例 (RFC 6763 Section 13.1) cont. Ø“dns-sd.org” で HTTP で提供されているサービスインスタンスの SRV RR, TXT RR を調べる ØSRVで出てくる”multicastdns.org."の A RR を見ると、元々サービスインスタンス一覧を PTRで検索した”dns-sd.org”と同じAレコード”96.76.212.165”を持っている。 13 Port 接続先のドメイン

1-3. RFC 6763 cont. nローカルでの動作例 Øローカルでプリントサーバを検索する 1. ユーザは _ipp.tcp.local. に対してPTRでインスタンスを検索する。 ( _ipp = サービス名、.local. は Multicast_ipp検索するリンクローカルのドメイン名 ) 2. それらから利用するプリンタを選択肢、SRV,TXT RRを参照し、接続先、関連情報を取得する 3. SRVで指定されたcolor_printer2.local.のAレコードを検索 4. 192.168.100.1 のSRVで指定されたポート631に接続する 14 _ipp._tcp.local. 60 IN PTR color_expensive._ipp._tcp.local. _ipp._tcp.local. 60 IN PTR color_standard._ipp._tcp.local. _ipp._tcp.local. 60 IN PTR mono._ipp._tcp.local. color_standard._ipp._tcp.local. 60 IN SRV 0 0 631 color_printer2.local. color_printer2.local. 60 IN A 192.168.100.1

1-3. RFC 6763 Cont. n関連情報 üサービス名はRFC 6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry Ø https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml 15

1-3. RFC 6763 Cont. n特別なRR name 16 RR name 役割 役割(日本語) b._dns_sd._udp. A list of domains recommended for browsing. ブラウズすべきドメイン名のリスト db._dns_sd._udp. A single recommended default domain for browsing. ブラウズすべき規定の(1つの)ドメイン名 r._dns_sd._udp. A list of domains recommended for registering services using Dynamic Update. Dynamic updateでサービス登録する時に利用 する時に推奨されるドメイン名のリスト dr._dns_sd._udp. A single recommended default domain for registering services. Dynamic updateでサービス登録する時に利用 する時に推奨される規定の(1つの)ドメイン名 lb._dns_sd._udp. The "legacy browsing" or "automatic browsing" domain(s). ネットワーク管理者がアプリケーション毎にどのド メイン名を使うべきかクライアントOSとやり取りす る為のもの? (RFCの文章が冗長な上に例がないのでよくわ からない・・・)

1-3. RFC 6763 Cont. n実装例 ØBonjour Overview • https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/NetServi ces/Introduction.html#//apple_ref/doc/uid/10000119i ØApple Bonjour Printing Specification • https://developer.apple.com/bonjour/printing-specification/bonjourprinting-1.2.1.pdf • TXTレコードを使う例が分かりやすい ØOpenStack • https://specs.openstack.org/openstack/api-sig/guidelines/dns-sd.html • service catalogの代わりにdns-sdを使う実装。使われているかは知らない ØAvahi • https://www.avahi.org/ ØmacOS “dns-sd” コマンド • man dns-sd 17

2. IETF dnssd WGで標準化されたRFC 2-1. IETF dnssd WGで標準化されたRFC 2-2. RFC 7558 Requirements for Scalable DNS-SD / mDNS Extensions 2-3. RFC 8222 Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-SD 2-4. RFC 8765 DNS Push Notifications 2-5. RFC 8766 Discovery Proxy for Multicast DNS-Based Service Discovery 2-6. RFC 8882 DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements 18

2-1. IETF dnssd WGで標準化されたRFC 19 RFC 7558 Requirements for Scalable DNS- Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions RFC 8765 DNS Push Notifications RFC 8222 Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery RFC 8882 DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements サービス名検索時に用いるドメイン名ラベルの 文字列について Multicast DNS, DNS-SDをリンクローカル以外に 適用する際の考慮事項まとめ Informational Informational Informational Standard RFC 8766 Discovery Proxy for Multicast DNS-Based Service Discovery Standard Multicast DNSで更新のプッシュ通知が できない場合のpub/sub通知の仕組み

2-2. RFC 7558 Requirements for Scalable DNS- Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions n超概要 ØRFC 6762, 6763 をリンクローカルを超えて適用する場合の要件をまとめたもの üMulticast DNS と Unicast DNS の組合せや、ルータを超えたマルチキャスト通信、無線LAN上や メディア種別を跨いだ Multicast DNS の拡張を考慮 üユースケースとしては、パーソナルエリアネットワーク、ホームネットワーク、ホットスポット、スモールビジ ネスネットワーク、エンタープライズネットワーク等となっていて、仮想基盤等は入っていない 20

2-2. RFC 7558 cont. n従来の Multicast DNS/DNS-SD における課題 n要件という程まとまってなかったし Informational なので後略 21 RFC内 Section 課題 要約 2.1 Multi-link Naming and Discovery マルチリンク時の命名規則とサービスディスカバリ 2.2 IEEE 802.11 Wireless LANs 無線LANでのMulticast応答(*) 2.3 Low-Power and Lossy Networks (LLNs) 省電力ネットワークでのMulticast負荷の低減や、電源オフ 状態のデバイスへの考慮 (*) IEEE 802.11ではmulticastは全ての端末がサポートしている最低のbit rateで送信される事になっている為、網全体の速度低下に繋がる

2-3. RFC 8222 Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery n超概要 Ø国際化ドメイン (Internationalized Domain Names for Applications/IDNA)やUnicodeを含むラベ ルの利用についての記述 n前提知識 ü「インターネット上のホスト名」はRFC 952で定義される、所謂、従来のLDH (Letter, digits and hyphens)がルールとして適用される (事が多い) ü「アプリケーションとして利用する場合のドメイン名」にはIDNA2008や他のRFCで定義されるラベルが 使用できる 22

2-3. RFC 8222 cont. nMulticast DNSの場合は? üSRV, TXTレコードで登録されるドメイン名は「インターネットホスト名」ではない üラベルをUTF-8でエンコードする必要がある üpunctuation(句読点、区切り文字)が推奨されている n サービスインスタンス名 ...各部分の要件 23 portion 要件 ü IDNA対応文字列を利用 ü 通常のIDNA対応レゾルバにA/AAAAとして解釈されない様にする必要がある ü 前項の為、LDHフォーマットは避ける必要がある ü スペース、大文字小文字の区別、UTF-8 Encodingを許容する必要がある ü 先頭にアンダースコアが付く ü IDNA処理対象にはならない ü 通常のドメイン名規則に準ずる ü IDNA処理対象となる

2-4. RFC 8765 DNS Push Notifications n超概要 ØサーバサイドからクライアントサイドへDNS登録情報の通知を行う仕組み ØDNS-SDでは特に重要なのでdnssd WGから標準化されたが、DNS-SDに限定されるものではない ØAppleの独自拡張である RFC 8764 Apple’s DNS Long-Lived Queries Protocol も存在するが、 RFC 8765で置き換えられている n前提知識 üMulticast DNSでは、リンクローカルのIPマルチキャストグループへ通知する仕組みがある üUnicast DNSで検索した場合や、Discovery Proxy (RFC 8766; 次節)を経由する場合には、ポー リングなしでプッシュ通知する仕組みを用意する必要がある 24

2-4. RFC 8765 cont. n動作 ØRFC 8490 DNS Stateful Operations (DSO)を利用した、pub/subモデルの通知形式をとる ØクライアントはDiscoveryのプロセスではフルリゾルバに問合せを行い、 SubscriptionのプロセスではDiscoveryで見つかったSRVで指定されたサーバにDSOで接続 25 項目 概要 Transport RFC 8490 DNS Stateful Operations (DSO)、その要求としてTLS over TCP Discovery 1. フルレゾルバにDSOセッションを確立 2. サブスクリプションしたいサービス名のSOA (例:_ ipp._tcp.headoffice.example.com)を検索し、 SOAが存在するドメイン名を取得 3. 2で取得したドメイン名に対し、SRV “_dns-push-tls._tcp.”を検索 4. SRVが存在すれば、サブスクリプション可能 Subscription Discoveryで見つかったSRVに応じて、DSOでSUBSCRIBEメッセージを送信

2-5. RFC 8766 Discovery Proxy for Multicast DNS-Based Service Discovery n超概要 ØMulticast DNSの使いやすさと、Unicast DNSのスケーラビリティを備えた仕組みが必要 Øリンクローカル空間のMulticastで検出したDNSレコードを、Unicast DNSの名前空間で見える様に する「Discovery Proxy」 26 +--------+ Unicast +-----------+ +---------+ +---------+ | Remote | Communication | Discovery | | Network | | Network | | Client |---- . . . ----| Proxy | | Printer | | Camera | +--------+ +-----------+ +---------+ +---------+ | | | | ------------ -------------------------------------------- Multicast-capable LAN segment (e.g., Ethernet)

+--------+ Unicast +-----------+ +---------+ +---------+ | Remote | Communication | Discovery | | Network | | Network | | Client |---- . . . ----| Proxy | | Printer | | Camera | +--------+ +-----------+ +---------+ +---------+ | | | | ------------ -------------------------------------------- Multicast-capable LAN segment (e.g., Ethernet) 2-5. RFC 8766 Discovery Proxy for Multicast DNS-Based Service Discovery n超概要 cont. 1. リンク毎に固有なドメイン名をもつ 2. Discovery Proxy は 1. の権威DNSサーバとなり NS レコードを設定される 27 Unicast ドメイン名 「Building 1.example.com」 1 2 Discovery Proxyは 「Building 1.example.com」のNSに指定

2-5. RFC 8766 cont. nブラウジングを使ってネットワークプリンタを検索する例 1. Clientが 「{b,db,lb}.__dns-sd._udp.example.com. 」を Unicast PTRでexample.comの権威DNSに問合せ 2. example.comの権威DNSは予め設定されたブラウジング用のドメインリストを返答 3. Clientは返答から 「Building 1.example.com.」を選択 4. Clientは「_ipp._tcp.Building 1.example.com.」を Unicast PTRでDiscovery Proxyに問合せ 5. Discovery ProxyがmDNSの名前空間に変換を行う 6. Discovery Proxyが該当リンク上の「_ipp._tcp.local.」をmDNSで検索 7. Discovery Proxyが再度Unicast PTRに変換し、Clientに返答 8. Clientは返答から、「color. _ipp._tcp. Building 1.example.com.」を選択 9. Clientが「color._ipp._tcp. Building 1.example.com.」をUnicast SRVでDiscovery Proxyに問合せ 10. Discovery ProxyがmDNSの名前空間に変換を行う 11. Discovery Proxyが該当リンク上の「color_standard._ipp._tcp.local.」のSRVをmDNSで検索 12. Discovery Proxyが再度Unicast SRVに変換し、Clientに返答 13. 後はSRVから接続先を確認するだけ 28

2-5. RFC 8766 cont. nブラウジングを使ってネットワークプリンタを検索する例 1. Clientが 「{b,db,lb}.__dns-sd._udp.example.com. 」を example.comの権威DNSに問合せ 2. example.comの権威DNSは予め設定されたブラウジング用のドメインリストを返答 29 1 {b,db,lb}.__dns-sd._udp.example.com.のPTRは? b._dns-sd._udp.example.com. PTR Building 1.example.com. b._dns-sd._udp.example.com. PTR Building 2.example.com. b._dns-sd._udp.example.com. PTR Building 3.example.com. b._dns-sd._udp.example.com. PTR Building 4.example.com. db._dns-sd._udp.example.com. PTR Building 1.example.com. lb._dns-sd._udp.example.com. PTR Building 1.example.com. 2 +--------+ Unicast +-----------+ | Remote | Communication |example.com| | Client |---- . . . ----| 権威DNS | +--------+ +-----------+

2-5. RFC 8766 cont. nブラウジングを使ってネットワークプリンタを検索する例 3. Clientは返答から 「Building 1.example.com.」を選択 30 b._dns-sd._udp.example.com. PTR Building 1.example.com. b._dns-sd._udp.example.com. PTR Building 2.example.com. b._dns-sd._udp.example.com. PTR Building 3.example.com. b._dns-sd._udp.example.com. PTR Building 4.example.com. db._dns-sd._udp.example.com. PTR Building 1.example.com. lb._dns-sd._udp.example.com. PTR Building 1.example.com. 3 「Building 1」の情報が知りたい! +--------+ Unicast +-----------+ +---------+ +---------+ | Remote | Communication | Discovery | | Network | | Network | | Client |---- . . . ----| Proxy | | Printer | | Camera | +--------+ +-----------+ +---------+ +---------+ | | | | ------------ -------------------------------------------- Multicast-capable LAN segment (e.g., Ethernet) link#1

2-5. RFC 8766 cont. nブラウジングを使ってネットワークプリンタを検索する例 4. Clientは「_ipp._tcp.Building 1.example.com.」を Unicast PTRでDiscovery Proxyに問合せ (*) 5. Discovery ProxyがmDNSの名前空間に変換を行う (*) Building 1.example.com.のNSがDiscovery Proxyに設定されている為 31 +--------+ Unicast +-----------+ +---------+ +---------+ | Remote | Communication | Discovery | | Network | | Network | | Client |---- . . . ----| Proxy | | Printer | | Camera | +--------+ +-----------+ +---------+ +---------+ | | | | ------------ -------------------------------------------- Multicast-capable LAN segment (e.g., Ethernet) link#1 _ipp._tcp.Building 1.example.com.のPTRは? 4 _ipp._tcp.Building 1.example.com. はlink#1の _ipp._tcp.local. 5

2-5. RFC 8766 cont. nブラウジングを使ってネットワークプリンタを検索する例 6. Discovery Proxyが該当リンク上の「_ipp._tcp.local.」のPTRをmDNSで検索 7. Discovery Proxyが再度Unicast PTRに変換し、Clientに返答 32 +--------+ Unicast +-----------+ +---------+ +---------+ | Remote | Communication | Discovery | | Network | | Network | | Client |---- . . . ----| Proxy | | Printer | | Camera | +--------+ +-----------+ +---------+ +---------+ | | | | ------------ -------------------------------------------- Multicast-capable LAN segment (e.g., Ethernet) link#1 _ipp._tcp.local.のPTRはmDNSで検索すると color._ipp._tcp.local. mono._ipp._tcp.local. 6 Unicastドメイン名に変換して応答 color._ipp._tcp.Building 1.example.com. mono._ipp._tcp.Building 1.example.com. 7 s/local./Building 1.example.com./

2-5. RFC 8766 cont. nブラウジングを使ってネットワークプリンタを検索する例 8. Clientは返答から、「color. _ipp._tcp. Building 1.example.com.」を選択 9. Clientが「color._ipp._tcp. Building 1.example.com.」をUnicast SRVでDiscovery Proxyに問合せ 33 +--------+ Unicast +-----------+ +---------+ +---------+ | Remote | Communication | Discovery | | Network | | Network | | Client |---- . . . ----| Proxy | | Printer | | Camera | +--------+ +-----------+ +---------+ +---------+ | | | | ------------ -------------------------------------------- Multicast-capable LAN segment (e.g., Ethernet) link#1 color._ipp._tcp.Building 1.example.com. mono._ipp._tcp.Building 1.example.com. 8 color._ipp._tcp.Building 1.example.com.に繋ぎたい color._ipp._tcp.Building 1.example.com. のSRVは？ 9

2-5. RFC 8766 cont. nブラウジングを使ってネットワークプリンタを検索する例 10. Discovery ProxyがmDNSの名前空間に変換を行う 34 +--------+ Unicast +-----------+ +---------+ +---------+ | Remote | Communication | Discovery | | Network | | Network | | Client |---- . . . ----| Proxy | | Printer | | Camera | +--------+ +-----------+ +---------+ +---------+ | | | | ------------ -------------------------------------------- Multicast-capable LAN segment (e.g., Ethernet) link#1 color._ipp._tcp.Building 1.example.com はlink#1の color._ipp._tcp.local. 10

2-5. RFC 8766 cont. nブラウジングを使ってネットワークプリンタを検索する例 11. Discovery Proxyが該当リンク上の「color_standard._ipp._tcp.local.」のSRVをmDNSで検索 12. Discovery Proxyが再度Unicast SRVに変換し、Clientに返答 13. 後はSRVから接続先を確認するだけ 35 +--------+ Unicast +-----------+ +---------+ +---------+ | Remote | Communication | Discovery | | Network | | Network | | Client |---- . . . ----| Proxy | | Printer | | Camera | +--------+ +-----------+ +---------+ +---------+ | | | | ------------ -------------------------------------------- Multicast-capable LAN segment (e.g., Ethernet) link#1 color._ipp._tcp.local.のSRVは color._ipp._tcp.local.IN SRV 0 0 631 printer1.local. 11 color._ipp._tcp. Building 1.example.com. のSRVは color._ipp._tcp. Building 1.example.com. IN SRV 0 0 631 printer1. Building 1.example.com.. 12 s/local./Building 1.example.com./ 13 printer1. Building 1.example.com.:631 に繋ぎます！

2-5. RFC 8766 cont. nその他 üDiscovery Proxyは基本的に外部からのUnicastクエリをトリガーとするオンデマンド動作 üDNS Push Notificationとの組合せ利用は可能 Ø初回検索時は即応性の為、既存のmDNSテーブルから返答 Ø同時にmDNS検索を行い、差分があればPushで追加情報として通知 üUnicast DNSとMulticast DNSの互換性の為、ユーザの視認性が高い RFC 8222のルールを利用 したものと従来のLDH形式のものの2種類のドメイン名をサポートする事が必要(SHOULD) ü例) アプリケーション等から選択させることを前提とした 「ビル 1 2.example.com」と LDH形式の「bldg-1-2.example.com」の複数レコードの設定 36

2-6. RFC 8882 DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements n超概要 ØAbstract ü DNS-SD (DNS-based Service Discovery) normally discloses information about devices offering and requesting services. This information includes hostnames, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS-based Service Discovery at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy-respecting discovery service. ØDNS-SDで晒される情報、特に公衆ネットワークに関する考慮、ということなので省略 37

3. IETF dnssd WGで議論中のI-D 38

3. IETF dnssd WGで議論中の I-D 39 Advertising Proxy for DNS-SD Service Registration Protocol An EDNS(0) option to negotiate Leases on DNS Updates Service Registration Protocol for DNS- Based Service Discovery WG draft Waiting for WG Chair Go-Ahead : Proposed Standard WG draft WG draft Waiting for WG Chair Go-Ahead WG Active Internet-Drafts (2023-JAN-10) DNS updateとDNS-SDでMulticast DNSを使 わずに Service Registration する仕組み。 WiFiとIoTがターゲット レガシーなクライアントが SRP + Multicast DNS でサービス検索する仕組み DNS updateを利用する際に、有効でないレコー ドをガベージコレクションする仕組み

3. IETF dnssd WGで議論中の I-D cont. 40 DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP) Multicast DNS conflict resolution using the Time Since Received (TSR) RR Related Internet-Drafts (2023-JAN-10) Automatic Replication of DNS-SD Service Registration Protocol Zones individual individual individual Øまだ invidual だし省略！

参考にした情報 • IETF Extensions for Scalable DNS Service Discovery (dnssd) WG • https://tex2e.github.io/rfc-translater/ • http://www.dns-sd.org/ • DNSプロトコルの進化 2020 (IETFでの標準化) JPRS藤原さん 41