ESP8266mDNS: Improve compliance with DNS-SD RFC6763 #3145
Comments
ccooper21
added a commit
to ccooper21/esp8266-arduino
that referenced
this issue
Apr 17, 2017
- When the "_services._dns_sd._udp.local" meta-query is received, an enumeration of services types is now returned (e.g. "_http._tcp.local") instead of an enumeration of instances (e.g. "MyService._http._tcp.local"). This is consistent with Section 9 of the RFC. - When a response is sent, the response records are now properly partitioned as either answers or additional records. Only response records that were explicitly requested as a result of the questions should be treated as answers. This is consistent with Section 12 of the RFC. - The "MDNSResponder::advertiseServices()" method has been removed as it was declared as "private" and is no longer being called. This method was sending a response on multiple interfaces when available, but this wasn't really necessary since the interface from which the request was received that caused it to be invoked is known.
ccooper21
added a commit
to ccooper21/esp8266-arduino
that referenced
this issue
Apr 24, 2017
- When the "_services._dns_sd._udp.local" meta-query is received, an enumeration of services types is now returned (e.g. "_http._tcp.local") instead of an enumeration of instances (e.g. "MyService._http._tcp.local"). This is consistent with Section 9 of the RFC. - When a response is sent, the response records are now properly partitioned as either answers or additional records. Only response records that were explicitly requested as a result of the questions should be treated as answers. This is consistent with Section 12 of the RFC. - The "MDNSResponder::advertiseServices()" method has been removed as it was declared as "private" and is no longer being called. This method was sending a response on multiple interfaces when available, but this wasn't really necessary since the interface from which the request was received that caused it to be invoked is known.
igrr
pushed a commit
that referenced
this issue
May 1, 2017
- When the "_services._dns_sd._udp.local" meta-query is received, an enumeration of services types is now returned (e.g. "_http._tcp.local") instead of an enumeration of instances (e.g. "MyService._http._tcp.local"). This is consistent with Section 9 of the RFC. - When a response is sent, the response records are now properly partitioned as either answers or additional records. Only response records that were explicitly requested as a result of the questions should be treated as answers. This is consistent with Section 12 of the RFC. - The "MDNSResponder::advertiseServices()" method has been removed as it was declared as "private" and is no longer being called. This method was sending a response on multiple interfaces when available, but this wasn't really necessary since the interface from which the request was received that caused it to be invoked is known.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are a few aspects of the existing ESP8266 MDNS implementation that are not compliant with RFC6763 describing the DNS-based Service Discovery (i.e. DNS-SD) protocol. Specifically:
Section 9 states that when a service type enumeration request is received (i.e. a request with the special
_services._dns-sd._udp.localmeta-query), the response should be a set ofPTRrecords identifying supported service types (e.g._http._tcp.local). Presently, the MDNS implementation responds with a set ofPTRrecords identifying service instances (e.g.MyService._http._tcp.local).Section 12 states that response records that were not explicitly requested by the client should be treated as additional records in the DNS response. This is reinforced by Section 4.1 of RFC1035 describing the DNS protocol. Presently, the MDNS implementation treats all response records as answers to the questions sent by a client, irrespective of the questions actually sent.
The text was updated successfully, but these errors were encountered: