DNS による service discovery 関連の RFC/I-D のまとめ

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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を使わない。

View Slide

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

View Slide

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

View Slide

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~~

View Slide

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

View Slide

$ 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 接続先のドメイン

View Slide

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

View Slide

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

View Slide

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の文章が冗長な上に例がないのでよくわ
からない・・・)

View Slide

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

View Slide

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

View Slide

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通知の仕組み

View Slide

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

View Slide

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で送信される事になっている為、網全体の速度低下に繋がる

View Slide

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

View Slide

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処理対象となる

View Slide

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

View Slide

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メッセージを送信

View Slide

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)

View Slide

+--------+ Unicast +-----------+ +---------+ +---------+
+--------+ +-----------+ +---------+ +---------+
| | | |
------------ --------------------------------------------
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に指定

View Slide

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に問合せ
11. Discovery Proxyが該当リンク上の「color_standard._ipp._tcp.local.」のSRVをmDNSで検索
12. Discovery Proxyが再度Unicast SRVに変換し、Clientに返答
13. 後はSRVから接続先を確認するだけ 28

View Slide

2-5. RFC 8766 cont.
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.
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 |
+--------+ +-----------+

View Slide

2-5. RFC 8766 cont.
3. Clientは返答から「Building 1.example.com.」を選択
30
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 +-----------+ +---------+ +---------+
+--------+ +-----------+ +---------+ +---------+
| | | |
------------ --------------------------------------------
link#1

View Slide

2-5. RFC 8766 cont.
4. Clientは「_ipp._tcp.Building 1.example.com.」を Unicast PTRでDiscovery Proxyに問合せ (*)
(*) Building 1.example.com.のNSがDiscovery Proxyに設定されている為
31
+--------+ Unicast +-----------+ +---------+ +---------+
+--------+ +-----------+ +---------+ +---------+
| | | |
------------ --------------------------------------------
link#1
_ipp._tcp.Building 1.example.com.のPTRは?
4
_ipp._tcp.Building 1.example.com.
はlink#1の
_ipp._tcp.local.
5

View Slide

2-5. RFC 8766 cont.
6. Discovery Proxyが該当リンク上の「_ipp._tcp.local.」のPTRをmDNSで検索
7. Discovery Proxyが再度Unicast PTRに変換し、Clientに返答
32
+--------+ Unicast +-----------+ +---------+ +---------+
+--------+ +-----------+ +---------+ +---------+
| | | |
------------ --------------------------------------------
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./

View Slide

2-5. RFC 8766 cont.
8. Clientは返答から、「color. _ipp._tcp. Building 1.example.com.」を選択
9. Clientが「color._ipp._tcp. Building 1.example.com.」をUnicast SRVでDiscovery Proxyに問合せ
33
+--------+ Unicast +-----------+ +---------+ +---------+
+--------+ +-----------+ +---------+ +---------+
| | | |
------------ --------------------------------------------
link#1
mono._ipp._tcp.Building 1.example.com.
8 color._ipp._tcp.Building 1.example.com.に繋ぎたい
のSRVは？
9

View Slide

2-5. RFC 8766 cont.
34
+--------+ Unicast +-----------+ +---------+ +---------+
+--------+ +-----------+ +---------+ +---------+
| | | |
------------ --------------------------------------------
link#1
color._ipp._tcp.Building 1.example.com
はlink#1の
color._ipp._tcp.local.
10

View Slide

2-5. RFC 8766 cont.
11. Discovery Proxyが該当リンク上の「color_standard._ipp._tcp.local.」のSRVをmDNSで検索
12. Discovery Proxyが再度Unicast SRVに変換し、Clientに返答
13. 後はSRVから接続先を確認するだけ
35
+--------+ Unicast +-----------+ +---------+ +---------+
+--------+ +-----------+ +---------+ +---------+
| | | |
------------ --------------------------------------------
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
に繋ぎます！

View Slide

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

View Slide

(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

View Slide

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

View Slide

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を利用する際に、有効でないレコー
ドをガベージコレクションする仕組み

View Slide

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 だし省略！

View Slide

参考にした情報
• 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

View Slide

DNS によるservice discovery 関連の RFC/I-D のまとめ

DNS による service discovery 関連の RFC/I-D のまとめ

Ryuichi Takashima

More Decks by Ryuichi Takashima

Other Decks in Technology

Featured

Transcript