You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug A clear and concise description of what the bug is.
In captures it was observed that the DNS resolver on the OTBR (reference release) is not accessible via TCP on port 53 on the ML-EID address that's being published as the Thread Service Registry in the Unicast DNS/SRP Dataset. Test cases expect TCP service on port 53, for reference device and also for DUT.
To Reproduce Information to reproduce the behavior, including:
I couldn't yet reproduce due to an issue (TCP CLI commands are not provided in ot-reference-release FTD dongle).
So we may be wrong with our interpretation here - but reporting it anyway to raise awareness.
Git commit id: ot-reference-release?
IEEE 802.15.4 hardware platform: Nordic
Build steps: ot-reference-release?
Network topology: see TSTBED-376
Expected behavior A clear and concise description of what you expected to happen.
BR has port 53 TCP open for DNS resolver service.
Note that the BR possibly did have its AIL (Ethernet link) address available with TCP port 53 for DNS service. From current / first test results analysis it wasn't fully clear yet if that really was the BR or if it was another device (Eth_1) on AIL. However, this is not so useful for Thread devices because they don't know this address - they will use the ML-EID provided in the Unicast Dataset.
Console/log output If applicable, add console/log output to help explain your problem.
TSTBED-376
Additional context Add any other context about the problem here.
Test case 11.2 (DUT==BR) and 11.4 (reference device == BR).
The text was updated successfully, but these errors were encountered:
See also related issue Thread SPEC-1322. Current spec text actually states that the BR does not offer DNS-over-TCP service on port 53, if the port published in Unicast Dataset is != 53. So the OTBR implementation does conform to this.
See also related issue Thread SPEC-1322. Current spec text actually states that the BR does not offer DNS-over-TCP service on port 53, if the port published in Unicast Dataset is != 53. So the OTBR implementation does conform to this.
There was more info added to SPEC-1339 which shows that DNS-over-TCP service needs to be available on port 53, regardless of the port of the Unicast Dataset. The finer detail here is that SRP-over-TCP registration is not available if the Unicast Dataset advertised port is != 53, because the TCP port in that case is to be used for TLS.
Describe the bug A clear and concise description of what the bug is.
In captures it was observed that the DNS resolver on the OTBR (reference release) is not accessible via TCP on port 53 on the ML-EID address that's being published as the Thread Service Registry in the Unicast DNS/SRP Dataset. Test cases expect TCP service on port 53, for reference device and also for DUT.
To Reproduce Information to reproduce the behavior, including:
I couldn't yet reproduce due to an issue (TCP CLI commands are not provided in ot-reference-release FTD dongle).
So we may be wrong with our interpretation here - but reporting it anyway to raise awareness.
Expected behavior A clear and concise description of what you expected to happen.
BR has port 53 TCP open for DNS resolver service.
Note that the BR possibly did have its AIL (Ethernet link) address available with TCP port 53 for DNS service. From current / first test results analysis it wasn't fully clear yet if that really was the BR or if it was another device (Eth_1) on AIL. However, this is not so useful for Thread devices because they don't know this address - they will use the ML-EID provided in the Unicast Dataset.
Console/log output If applicable, add console/log output to help explain your problem.
TSTBED-376
Additional context Add any other context about the problem here.
Test case 11.2 (DUT==BR) and 11.4 (reference device == BR).
The text was updated successfully, but these errors were encountered: