Support IPv6 DNS (was NAT64 example/documentation appears wrong) (TZ-966)

[sgryphon]

Thread is an IPv6 technology, so should support setting any (IPv6) DNS server, not just NAT-mapped IPv4 addresses via a helper method.

e.g. Directly set to the Google DNS64 service, that will give back either IPv6 addressed or NAT64 mapped addresses if the service is IPv4 only:

dnsserver 2001:4860:4860::6464

It is annoying that Thread, an IPv6 protocol, had added support for legacy IPv4 DNS before native IPv6 command support.

Background

The page about NAT64 https://github.com/espressif/esp-thread-br/blob/48b2e47/docs/en/codelab/nat64.rst

Has the following:

For visiting HTTP servers with domain names, the DNS server shall be first configured on the Thread CLI device:

dns64server 8.8.8.8

This command does two things -- do the conversion from an IPv4 address to a NAT64 address (64:ff9b::808:808) and then set that IPv6 address as the DNS server (64:ff9b::808:808). Note that Thread only supports IPv6, so it can only ever use an IPv6 DNS server.

This command just has a helper method to convert IPv4 to IPv6.

However there is no command to set the DNS server directly and it seems strange to provide a helper method for legacy support before there is even a normal DNS setting command.

Setting any DNS command supports both scenarios

Note that a generic dnsserver command would also allow setting a NAT64 address, but you would have to the conversion manually.

e.g. the following would end up with the same configuration as the shortcut dns64server command:

dnsserver 64::808:808

The helper method should be retained, as it simplifies the process of doing the conversion for you. (Although it is still strange to provide the helper method before the base one).

Misleading name and useless results

It appears the name of the command dns64server refers to setting the (IPv6) DNS server to the NAT64 address equivalent of the provided IPv4 address, although this won't actually return DNS64 results.

The server 8.8.8.8, even if accessed via NAT64, still returns IPv4 (or dual-stack) addresses, e.g.

PS C:\Users\sgryp> nslookup v4.ipv6-test.com 64:ff9b::808:808
Server:  UnKnown
Address:  64:ff9b::808:808

Non-authoritative answer:
Name:    v4.ipv6-test.com
Address:  51.75.78.103

The IPv4 address 51.75.78.103 is useless, as it can not be used by a Thread device (which is IPv6 only).

To actually get a DNS64 result (not just set the address of the DNS server via NAT64) you need to use a DNS64 service, e.g.

PS C:\Users\sgryp> nslookup v4.ipv6-test.com 2001:4860:4860::6464
Server:  dns64.dns.google
Address:  2001:4860:4860::6464

Non-authoritative answer:
Name:    v4.ipv6-test.com
Addresses:  64:ff9b::334b:4e67
          51.75.78.103

So, while setting an IPv4 server might allow queries, it is not very useful if it only gets back an IPv4 address that then can't be used. Usually DNS services that do provide usable DNS64 conversions only bother providing IPv6 addresses (not IPv4 ones). This makes the ability to set an IPv4 DNS of dubious value -- it would only be useful for results that have a dual stack answer, e.g.

PS C:\Users\sgryp> nslookup ipv6-test.com 64:ff9b::808:808
Server:  UnKnown
Address:  64:ff9b::808:808

Non-authoritative answer:
Name:    ipv6-test.com
Addresses:  2001:41d0:701:1100::29c8
          51.75.78.103
```

The 2001:41d0:701:1100::29c8 address is usable by a Thread device, whilst the IPv4 51.75.78.103 is not usable, as Thread only supports IPv6.

You could, of course, always take the 51.75.78.103 IPv4 address and manually create the NAT64 address to use (assuming the standard prefix). But that seems complicated (and risky), especially if you DNS64 servers can already provide IPv6 addresses for you.

This would be particularly important if your network environment uses a different prefix that the standard 64:ff9b, where you can't manually convert and would need to rely on DNS providing the correct addresses.

[chshu]

@sgryphon The term dns64server here might be misleading, but if you check its implementation here: dns64, you'll see the actual logic:

It takes an IPv4 address and combines it with the NAT64 prefix to form an IPv6 address, which is then configured as the DNS server. The Thread device will use this IPv6 DNS server address (NAT64 prefix + IPv4 DNS server) to make DNS queries, these queries are reformatted by NAT64 in the Thread BR, allowing them to be sent to the actual IPv4 address configured by this dns64server command.

In this scenario, we assume that public IPv6 connectivity is not available, and NAT64 is required at all times.

[sgryphon]

Ah, thanks for the pointer to the implementation. Yes, I can see how it takes an IPv4 address and converts it to a NAT64 address to use as a DNS server.

I had a search for dns_setserver in the source code, and there doesn't appear to be any way to set it other than via an IPv4 address, i.e. you only support IPv4 DNS, which still seems a bit strange for a protocol that is founded on IPv6.

My suggestion would be to allow the DNS server to be set correctly, so you you can support IPv6 end-to-end scenarios as well (i.e. where you have end-to-end IPv6 network connectivity but may still need to access IPv4 only destinations).

i.e. add a command like the following that can set any DNS server:

dnsserver 2001:4860:4860::6464

It would be important to be able to set either an IPv6 or IPv4 DNS server, so that you can support IPv6 only networks. It would be strange for an IPv6 technology such as thread to not support IPv6 only networks.

Note that you could use this command to replicate the behaviour of the existing command by doing the NAT64 conversion yourself (although the automatic conversion might be nicer), e.g.

dnsserver 64:ff9b::808:808

Also note that IPv4 DNS servers generally won't give back NAT64 addresses, i.e. 8.8.8.8 will only give back the IPv4 address result (and a native IPv6 if available), so you may not find them that useful for NAT64. DNS servers that support NAT64 (i.e. give back the NAT64 converted result), such as Google DNS64, are generally only available via IPv6.

PS C:\Users\sgryp> nslookup v4.ipv6-test.com 64:ff9b::808:808
Server:  UnKnown
Address:  64:ff9b::808:808

Non-authoritative answer:
Name:    v4.ipv6-test.com
Address:  51.75.78.103

PS C:\Users\sgryp> nslookup v4.ipv6-test.com 2001:4860:4860::6464
Server:  dns64.dns.google
Address:  2001:4860:4860::6464

Non-authoritative answer:
Name:    v4.ipv6-test.com
Addresses:  64:ff9b::334b:4e67
          51.75.78.103

---

Should I change the title of this issue, to support IPv6 DNS, or raise a new issue?