Thanks for your reply. However from the border router itself it should be possible to use both "dns resolve4" (for IPv4 addresses synthesized as IPv6 via NAT64) and "dns resolve" (for IPv6 adresses), right?

Which does not work for me. With the default dns config (as printed above) I get via ot-ctl:

> dns resolve4 ipv4.google.com
DNS response for ipv4.google.com. - Error 28: ResponseTimeout
^C

> dns resolve ipv6.google.com
DNS response for ipv6.google.com. - Error 28: ResponseTimeout
^C

The fd75:edf9:c135:67c8:d5d2:f716:a540:b072 shown in the dns config output should be assigned to a Border Router and be reachable.

Currently there is only one node, it's the BR itself (OTBR). Do I have to enable the built-in resolver somehow?

But I still don't understand why a DNS server pointing to itself is intended behaviour? It can only lead to endless querying of itself, right?

Not at all. It will not cause any loop. These are different components/modules running on the same device as part of the same stack or firmware. The DNS client is its own module, and the DNS server is its own. It is perfectly fine for one module to send a message that is received by another component running on the same device or stack.

We would not expect to get into a loop when issuing a ping on a machine to one of its own addresses. That is the same situation here.

Wouldn't it be more sensible – in absence of an upstream DNS – to query one of the well-known DNS resolvers (Quad9 etc.)?

Not really. As I said, the OpenThread DNS client is highly configurable (at runtime or through a set of OPENTHREAD_CONFIG_* build-time configs). This allows project integrations to configure it in whatever way makes sense for their use case. However, most people simply use the default Docker image, expecting it to work for them and their use-case directly.

We try to ensure the default general configuration (e.g., the one used by the default Docker image) is what makes the most sense for common use cases.

As I mentioned, OPENTHREAD_CONFIG_DNS_CLIENT_DEFAULT_SERVER_ADDRESS_AUTO_SET_ENABLE is a DNS client configuration (which is enabled). It explicitly asks the device to discover Border Routers within the mesh that provide DNS/SRP service and set them as the DNS config for the DNS resolver/server address to use by the client.

The main way the OT DNS client on the device is used is for local service discovery (DNS-SD) (similar to mDNS). This is essential for many use cases, such as running Matter on the device. For this, we would need to connect to a BR providing a DNS resolver service (with Discovery Proxy).

Why does OTBR not update its config if it receives a RA with valid RDNSS records?

It does! You are expecting the dns config (which shows the DNS client config) to be updated, which should not be the case. Check the CLI command br rdnsstable, which lists the RDNSS addresses. The OTBR implementation handles the case where multiple RDNSS addresses are discovered. It tries sending the query to all of them.

Ok, fair enough. It lists my home router's DNS resolver addresses:

> br rdnsstable
2a02:3100:29c0:5e00:6b4:feff:fe14:327f, lifetime:1200, ms-since-rx:168700, router:fe80:0:0:0:6b4:feff:fe14:327f (M:1 O:1 S:0)
fda1:e58f:849e:0:6b4:feff:fe14:327f, lifetime:1200, ms-since-rx:168700, router:fe80:0:0:0:6b4:feff:fe14:327f (M:1 O:1 S:0)
Done

But why does it then not resolve addresses? Naively speaking, it knows the resolver address(es), so what's keeping it from querying one of the address(es)?

And why does it run into a timeout, rather than failing immediately?

> dns resolve4 ipv4.google.com
DNS response for ipv4.google.com. - Error 28: ResponseTimeout
^C

> dns resolve ipv6.google.com
DNS response for ipv6.google.com. - Error 28: ResponseTimeout
^C

(note: I have to abort via Ctrl+C, it doesn't terminate by itself)

The short answer is I do not know. Probably need to debug further to understand. There can be various factors causing this, such as network or setup issues (e.g., are the RDNSS addresses correct? Are they reachable from the OTBR Docker? Is NAT64 set correctly? etc).

Yes, the addresses listed by "ot-ctl br rdnsstable" are correct. I can use dig on them from my host. How can I – in the absence of tools like ping and dig – test if they are reachable from within the container?

NAT64 seems to work as it should, because I can for example "ot-ctl ping 9.9.9.9" and it gets synthesized into an IPv6 address and round-trips as expected. However I can't ping any (non-synthesized) IPv6 address, such as the addresses listed by "br rdnsstable".

Is there more I can check?

Is my assumption correct that the addresses returned by "ot-ctl br ipaddr" should contain my public /56 prefix (assigned by my Internet provider) at least for one address?

But why does it then not resolve addresses? Naively speaking, it knows the resolver address(es), so what's keeping it from querying one of the address(es)?

The OpenThread DNS Client will not work on the TBR's OpenThread instance. On the posix platform, the Thread network interface is presented as a standard network interface and OpenThread sits under the host network stack. So there are effectively two separate IP stacks running (one on the host and one in OpenThread) and both share the same set of IP addresses.

If you introduce a separate Thread device and run dns resolve4 ipv4.google.com from that, it should work. In this case, the DNS Response will be properly routed back through the TBR to the Thread device and the OpenThread DNS Client on that device will properly receive the message.

Now I wonder if OTBR is compiled to support DHCPv6 PD at all? I get

> br pd state
Error 35: InvalidCommand

The documentation of that command states:

OPENTHREAD_CONFIG_BORDER_ROUTING_DHCP6_PD_ENABLE is required.

How can I query a list of compile-time options chosen by the Docker image? If PD is not supported then that could explain all of my troubles.

This is a description of what I think I need to get to work. It's from the Espressif version of OTBR, but I think it should be very close.

https://docs.espressif.com/projects/esp-thread-br/en/latest/codelab/dhcpv6_pd.html

If I try any of the br pd commands, I always get InvalidCommand.

DHCPv6 PD is currently off by default:

• https://github.com/openthread/ot-br-posix/blob/79a67341b9f4c19ed0e1e815b00a06c74d861317/etc/cmake/options.cmake#L229

The openthread/border-router Dockerfile is here:

• https://github.com/openthread/ot-br-posix/blob/main/etc/docker/border-router/Dockerfile

DHCPv6 PD is currently off by default

Thanks for confirming this. But how are nodes supposed to communicate with off-mesh IPv6 addresses (or even the Internet) if it doesn't use PD to receive a publicly routable prefix?

It was my understanding that the openthread/border-router:latest Docker image can be used for this as-is. Am I wrong and I need to compile my own Docker image?

The PD implementation is still a work in progress and not yet fully integrated int openthread/border-router image.