openthread
mDNS implementation questions.
Describe the bug A clear and concise description of what the bug is.
Thread 1.3 Certification Test 2.15 is failing for the BR DUT on step 12 and all other steps related to a PTR query for a subtype.
It seems that the current native mDNS implementation is not adding any other RRs, except for subtype's specific PTR when answering for a subtype PTR query. Certification testing seems to be checking if the base service RR are present, a service name check seems to be performed.
A comparation has been done with dns-sd implementation:
Found out that in Core::ServiceEntry::PrepareResponseRecords is determined which RR should be added to the message.
Would it be a bad idea that for a specific subtype PTR record that has to be added to an answer, the corresponding base SRV, TXT, AAAA records to be MarkToAppendInAdditionalData(). In this way, an mDNS browse from AIL will generate the same output as a DNS browse from OT side.
Another issue that our team discoverd is that a service registration can be performed using an mDNS host that has not been previously verified unique on the network.
There was already an 'Ubuntu' host registered on the network in this case, but no error on registration.
Comparing to dns-sd implementation, it seems that a service registration using dns-sd -R, is adding the host to the Queries and also to the Authoritative section:
In the current implementation, the service will be present when issuing mdns services, but the host is not. A simple browse query will result in:
but the target is not reachable, a NSEC record will be issued for an AAAA query.
Services remain also present when a host in unregistered. Should those be deleted in those scenarios? What do you think?
To Reproduce Information to reproduce the behavior, including:
- Git commit id
- IEEE 802.15.4 hardware platform
- Build steps
- Network topology
Expected behavior A clear and concise description of what you expected to happen.
Console/log output If applicable, add console/log output to help explain your problem.
Additional context Add any other context about the problem here.
Thanks, @Cristib05.
I'm surprised that cert tests mandate specific behaviors for additional record generation, as RFC 6763 frames these as recommendations.
We intentionally omitted additional records for sub-type PTR browse queries to reduce message size and traffic. These queries usually aim to identify devices with a particular function and are often accompanied by a base type browse (which would include those records).
We can modify the code to include additional records for sub-type PTR queries. I'll submit a PR for this shortly.
Another issue that our team discoverd is that a service registration can be performed using an mDNS host that has not been previously verified unique on the network.
Regarding this, the service and host registration APIs in native mDNS are intentionally independent of each other. This design choice aligns more closely with how they are used by Advertising Proxy. Callers can first attempt to register the host before registering services under the same host name.
It seems that the current native mDNS implementation is not adding any other RRs, except for subtype's specific PTR when answering for a subtype PTR query. Certification testing seems to be checking if the base service RR are present, a service name check seems to be performed.
I'm surprised that cert tests mandate specific behaviors for additional record generation, as RFC 6763 frames these as recommendations.
@Abhayakara @EskoDijk , should we relax this check in the Thread Test Specification?
But let me understand correctly: we register a service mdns register service my-service _http._tcp my-host 8333 and my-host doesn't exist but we get no error; this is an acceptable behaviour? I find that both un-intuitive and wrong. Shouldn't it be better to return an error code that would point to the fact that a user should first register the host and then the service?
@jwhui @abtink The current 1.3 test plan does not mandate additional records to be generated (I checked R6). It may be that some of the test scripts aren't yet updated to R6 -> for that a TSTBED JIRA issue can be filed ; @radua-nxp can you do this?
@jwhui @abtink The current 1.3 test plan does not mandate additional records to be generated (I checked R6). It may be that some of the test scripts aren't yet updated to R6 -> for that a TSTBED JIRA issue can be filed ; @radua-nxp can you do this?
@Cristib05 is working on this!