论文部分内容阅读
摘 要：基于DNS的服务发现（DNS-SD）是一种可以使用标准DNS编程接口、数据包格式和服务器浏览机制。DNS-SD定义了如何命名和排列dns记录，即指针（Ptr）、服务定位器（Srv）、IPv6地址（AAAA）和文本（Txt），目的是方便在子域中的服务发现。DNS-SD不改变DNS消息、操作代码、记录类型或任何其他DNS协议值的结构。广义地说，DNS-SD服务器包含服务列表，服务具有<Instance>.<ServiceType>.<Domain>的标准格式。
关键词：DNS;服务发现
1.分布式DNS服务发现
mDNS多播DNS（mDNS）将DNS规范扩展到没有基础设施的网络，其中设备查询本地域，通过多播而不是通过单播查询DNS服务器。
mDNS在DNS规范中添加了一个.local域，一个公开的多播端口和地址，并定义了如何管理单个查询的多个结果。在基于分布式dns服务发现中，设备可以使用mDNS通告发布有关它们提供的服务和资源的信息，这些通告具有与标准dns查询格式相同的格式，但被发送到IPv6多播地址FF02：FB。这些通告可以包括具有域名的服务类型和名称（PTR记录）（在mDNS的情况下是本地域）、主机名和端口（SRV记录）、地址（AAAA记录）以及设备的扩展描述（TXT记录）。
在楼宇自动化控制中，智能灯将通过在其mDNS通告中包含ptr、srv和txt记录来发布其服务。PTR记录定义了服务与服务实例的映射，例如服务为_light._sub.coap._udp.test.local，其中coap._udp为服务的类型，定义了所使用的协议（例如，CoAP/UDP），_light为服务的子类型表示被访问的资源（比如灯）。test.local为本地域，其服务的实例是LIGHT1_bc._sub.coap._udp.test.local，其中LIGHT_bc为实例的名称，可以为同一服务定义多个ptr以启用不同的查询格式。
服务实例LIGHT1_bc的SRV记录描述了如何访问服务。这包括主机名URI（例如，light1.test.local）、端口（例如，5683）、优先级（其中零表示最大优先级），以及具有相同优先级的记录的相对权重。
txt记录总是与srv一起定义的，以便提供更多的描述。TXT记录提供了资源的路径（path=/lt/1/on）和资源类型（rt=ipso.lt.on）。
一旦相关的客户端（如智能开关）拥有记录中包含的所有信息，它将使用所获得的信息（解析后）来访问灯资源。
如果客户端没有收到mDNS通告，分布式DNS服务发现还允许通过向多播地址发送标准DNS查询来发现服务器中的服务。比如查找其本地域中的任何灯，dns查询将只包含ptr，ptr用来表示智能开关只希望找到匹配特定的服务（_light._sub._coap._udp）的设备，智能灯将用服务实例（例如，LIGHT1_bc）的PTR记录答复智能开关。智能开关接收智能灯服务的实例后，需要解析出智能灯的URI。为此，智能开关会请求智能灯提供服务实例对应的SRV和TXT，SRV和TXT将提供IP地址、端口、路径和其他相关的信息。最后，客户端设备智能开关就可以使用获得的信息与已发现的智能灯的功能进行交互。
2.集中式DNS服务发现
在集中式DNS服务发现中，假定DNS-SD服务器可在网络基础结构中使用。DNS-SD服务器存储其子域中的设备提供的服务。与CoAP RD类似，这些设备先必须在DNS-SD中注册它们的服务。但与CoAP RD不同的是，没有定义标准的DNS注册消息。注册消息的最常见实现来源于苹果的Bonjour，它重用mDNS发布消息来在DNS-SD中注册服务描述，因此DNS-SD以mDNS为基础，如果DNS-SD地址未知，注册消息可以通过多播地址发送（这和mDNS类似），如果DNS-SD地址已知，可以直接发送到DNS服务器的单播地址。或者，设备可以通过浏览公开的服务_b._DNS-SD.udp.local（_b为服务的子类型，DNS-SD.udp为服务的类型）来发现DNS-SD服务器地址。最后，当DNS-SD服务器处于不同的子网中时，必须使用全局DNS-SD进程。
目前，全局DNS-SD无法自动发现远程服务器的地址。因此，假设DNS-SD服务器地址已经已知，例如通过IPv6路由器通告，智能灯将单播发送发布消息到全局DNS服务器以注册服务。因为远程DNS-SD服务器与智能灯不在同一个子网，服务器将无法观察该网络内的服务和资源的变化，例如，如果由于连通性的丢失而无法再到达智能灯。为了解决这个问题，IETF定义了一种称为动态DNS更新的同步机制[1]。动态dns更新利用dnsd服务器记录中增加生存期参数。每t分钟更新一次的记录（t=30分钟是建议的值）。如果资源在此时间范围内未更新，则將从DNS-SD中删除该资源。此外，IETF还定义DNS长寿命查询，允许客户端观察服务注册中的任何更改[2]。
最后，DNS-SD可以在公开的服务_services._dnssd._udp._local（_services为服务的子类型，DNS-SD.udp为服务的类型）下自动注册所有服务。这允许浏览在目录中注册的所有服务，CoAP的/wellknow/core与此类似，一旦注册过程结束，任何设备都可以通过DNS查询查找到DNS-SD服务器的服务。与分布式DNS不同，来自DNS-SD服务器的单个响应包括网络中与请求类型匹配的所有注册服务。在接收到服务实例后，解析过程必须通过全局DNS-SD服务器执行。
参考文献
[1] P. Vixie，S. Thomson，Y. Rekhter and J. Bound. Dynamic Updates in the Domain Name System（DNS UPDATE），Internet Engineering Task Force，RFC 2136. 1997
[2] S. Cheshire，M. Krochmal，K. Sekar. DNS Long-Lived Queries
关键词：DNS;服务发现
1.分布式DNS服务发现
mDNS多播DNS（mDNS）将DNS规范扩展到没有基础设施的网络，其中设备查询本地域，通过多播而不是通过单播查询DNS服务器。
mDNS在DNS规范中添加了一个.local域，一个公开的多播端口和地址，并定义了如何管理单个查询的多个结果。在基于分布式dns服务发现中，设备可以使用mDNS通告发布有关它们提供的服务和资源的信息，这些通告具有与标准dns查询格式相同的格式，但被发送到IPv6多播地址FF02：FB。这些通告可以包括具有域名的服务类型和名称（PTR记录）（在mDNS的情况下是本地域）、主机名和端口（SRV记录）、地址（AAAA记录）以及设备的扩展描述（TXT记录）。
在楼宇自动化控制中，智能灯将通过在其mDNS通告中包含ptr、srv和txt记录来发布其服务。PTR记录定义了服务与服务实例的映射，例如服务为_light._sub.coap._udp.test.local，其中coap._udp为服务的类型，定义了所使用的协议（例如，CoAP/UDP），_light为服务的子类型表示被访问的资源（比如灯）。test.local为本地域，其服务的实例是LIGHT1_bc._sub.coap._udp.test.local，其中LIGHT_bc为实例的名称，可以为同一服务定义多个ptr以启用不同的查询格式。
服务实例LIGHT1_bc的SRV记录描述了如何访问服务。这包括主机名URI（例如，light1.test.local）、端口（例如，5683）、优先级（其中零表示最大优先级），以及具有相同优先级的记录的相对权重。
txt记录总是与srv一起定义的，以便提供更多的描述。TXT记录提供了资源的路径（path=/lt/1/on）和资源类型（rt=ipso.lt.on）。
一旦相关的客户端（如智能开关）拥有记录中包含的所有信息，它将使用所获得的信息（解析后）来访问灯资源。
如果客户端没有收到mDNS通告，分布式DNS服务发现还允许通过向多播地址发送标准DNS查询来发现服务器中的服务。比如查找其本地域中的任何灯，dns查询将只包含ptr，ptr用来表示智能开关只希望找到匹配特定的服务（_light._sub._coap._udp）的设备，智能灯将用服务实例（例如，LIGHT1_bc）的PTR记录答复智能开关。智能开关接收智能灯服务的实例后，需要解析出智能灯的URI。为此，智能开关会请求智能灯提供服务实例对应的SRV和TXT，SRV和TXT将提供IP地址、端口、路径和其他相关的信息。最后，客户端设备智能开关就可以使用获得的信息与已发现的智能灯的功能进行交互。
2.集中式DNS服务发现
在集中式DNS服务发现中，假定DNS-SD服务器可在网络基础结构中使用。DNS-SD服务器存储其子域中的设备提供的服务。与CoAP RD类似，这些设备先必须在DNS-SD中注册它们的服务。但与CoAP RD不同的是，没有定义标准的DNS注册消息。注册消息的最常见实现来源于苹果的Bonjour，它重用mDNS发布消息来在DNS-SD中注册服务描述，因此DNS-SD以mDNS为基础，如果DNS-SD地址未知，注册消息可以通过多播地址发送（这和mDNS类似），如果DNS-SD地址已知，可以直接发送到DNS服务器的单播地址。或者，设备可以通过浏览公开的服务_b._DNS-SD.udp.local（_b为服务的子类型，DNS-SD.udp为服务的类型）来发现DNS-SD服务器地址。最后，当DNS-SD服务器处于不同的子网中时，必须使用全局DNS-SD进程。
目前，全局DNS-SD无法自动发现远程服务器的地址。因此，假设DNS-SD服务器地址已经已知，例如通过IPv6路由器通告，智能灯将单播发送发布消息到全局DNS服务器以注册服务。因为远程DNS-SD服务器与智能灯不在同一个子网，服务器将无法观察该网络内的服务和资源的变化，例如，如果由于连通性的丢失而无法再到达智能灯。为了解决这个问题，IETF定义了一种称为动态DNS更新的同步机制[1]。动态dns更新利用dnsd服务器记录中增加生存期参数。每t分钟更新一次的记录（t=30分钟是建议的值）。如果资源在此时间范围内未更新，则將从DNS-SD中删除该资源。此外，IETF还定义DNS长寿命查询，允许客户端观察服务注册中的任何更改[2]。
最后，DNS-SD可以在公开的服务_services._dnssd._udp._local（_services为服务的子类型，DNS-SD.udp为服务的类型）下自动注册所有服务。这允许浏览在目录中注册的所有服务，CoAP的/wellknow/core与此类似，一旦注册过程结束，任何设备都可以通过DNS查询查找到DNS-SD服务器的服务。与分布式DNS不同，来自DNS-SD服务器的单个响应包括网络中与请求类型匹配的所有注册服务。在接收到服务实例后，解析过程必须通过全局DNS-SD服务器执行。
参考文献
[1] P. Vixie，S. Thomson，Y. Rekhter and J. Bound. Dynamic Updates in the Domain Name System（DNS UPDATE），Internet Engineering Task Force，RFC 2136. 1997
[2] S. Cheshire，M. Krochmal，K. Sekar. DNS Long-Lived Queries