Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manual/DHCP DNS Server (TZ-544) #54

Closed
jeroen79 opened this issue Jan 5, 2024 · 12 comments
Closed

Manual/DHCP DNS Server (TZ-544) #54

jeroen79 opened this issue Jan 5, 2024 · 12 comments

Comments

@jeroen79
Copy link

jeroen79 commented Jan 5, 2024

Is there a way to set the dns server used but the border router?, it seems to use a google dns server by default.

Using the dns server from DHCP6 would also be acceptable, but using google is just wrong, it won't be able to resolve local hostnames.

@github-actions github-actions bot changed the title Manual/DHCP DNS Server Manual/DHCP DNS Server (TZ-544) Jan 5, 2024
@zwx1995esp
Copy link
Collaborator

So you want to use BR to resolve local service? Or what is your demend? Could you please show me some detials about that?

@jeroen79
Copy link
Author

jeroen79 commented Jan 5, 2024

Yes i want it to resolve local hostnames eg: server.home.local, and just by able to change the dns server it uses this would be possible, but i can't find any configuration options for it.

My home router is ipv6 capable and it can properly resolve it, i just need to be able to make the border router and all other thread devices use it.

@zwx1995esp
Copy link
Collaborator

So you mean that the local dns service resolving shown like this link? For the thread device in the thread network(not BR device), the dns server should be the BR device. Notice that all the commands shown in the link is related to the OT device, and these commands are implemented in the openthread stack.

As for the BR, it is also a WiFi device, if you want to resolve the service on the wifi interface, you can just use the mdns API to query the target service.

@zwx1995esp
Copy link
Collaborator

And for the thread device, there is a config to set the DNS server, which can be set by idf.py menuconfig

(Top) → Component config → OpenThread
(8.8.8.8) DNS server address (IPv4)

But I don't believe this feature is related to the local service, this server is configured on the BR, and using to access the service on the global network.

@jeroen79
Copy link
Author

That dns server is only uses for the DNS64 feature i think, i did also set it but it had no effect.

I did manage to force my router to redirect dns to itself, but i think in the future the dns server should be from dhcpv6 or at least configurable in menuconfig, defaulting to a google dns seems wrong to me.

@zwx1995esp
Copy link
Collaborator

Hi @jeroen79 Sorry for the delay.

Beside on my understanding, your demand is that you want to resolve the a local service, so does your local service publish by mDNS? If yes, our BR support the proxy that helps Thread device to query the service on the Wi-Fi interface. For the details you can refer to this link which is metioned before.

If your service surely published via a local dns server, I think you can change the DNS server address to your local server address, and then you can just ping the server on thread device, the BR will also resolve the address via local DNS. Which you mention that it seems to use a google dns server by default and defaulting to a google dns seems wrong to me, we set the google dns server via menuconfig, you see

(Top) → Component config → OpenThread
(8.8.8.8) DNS server address (IPv4)

And if you want to change the DNS server, you need to modify this config.

@jeroen79
Copy link
Author

jeroen79 commented Feb 5, 2024

Hi,

No my dns server does not use mdns, its a normal lan dns server., is that not sufficient?

(Top) → Component config → OpenThread
(8.8.8.8) DNS server address (IPv4)

This setting also does not seem to have any effect, if i understand correctly it is only for ipv6->ipv4 conversion.

There is another way way the system seems to force the google ipv6 dns server, but so far i have not had the time to figure out where is comes from.

@zwx1995esp
Copy link
Collaborator

zwx1995esp commented Feb 6, 2024

No my dns server does not use mdns, its a normal lan dns server., is that not sufficient?

Ok, got that.

(Top) → Component config → OpenThread
(8.8.8.8) DNS server address (IPv4)

This setting also does not seem to have any effect, if i understand correctly it is only for ipv6->ipv4 conversion.

There is another way way the system seems to force the google ipv6 dns server, but so far i have not had the time to figure out where is comes from.

No, for the thread device, if it wants to resolve some service address, the device will try to send the query packet to the DNS server IPv4 embedded IPv6 address, this address constructs by a NAT64 prefix and an IPv4 address. The query packet will first send to BR and BR will deconstruct the address and get the target DNS IPv4 address. And send the packet to the DNS server. If your local server is surely a DNS server, this should be works.

Could you please try to ping the DNS server address on the thread device(not on the BR)? Maybe we need to confirm that the connection between Thread device and DNS server are well.

On the thread device, yuou can just ping command:

> ping <your local IPv4 DNS server addr>

For exapmle:
> ping 192.168.1.1

@zwx1995esp
Copy link
Collaborator

zwx1995esp commented Feb 6, 2024

Hi, I did a quick test for your scenario. As the previous comments, I set the DNS server using my host address 192.168.1.102 which is a local address, and using the command curl http://www.baidu.com on thread device to curl some websites, for curling that website, the first step is to send a DNS query for the ip address of the website. I see the DNS query packet surely send to the host on wireshark.

Topology:

[thread device] <----> [thread BR] <========>[AP,local network] <=====> [my linux host]

The IPv4 address of BR is 192.168.1.100:

image

you can see the result, the packet surely sends to the host(192.168.1.102:53),:
image

@chshu
Copy link
Collaborator

chshu commented May 17, 2024

@jeroen79 could you help to close the issue if it has been resolved?

@jeroen79
Copy link
Author

You can close it, i have switched to just using wifi for now, i wasn't satisfied with the current stability of thread on esp32. i might pick it up again later.

@chshu
Copy link
Collaborator

chshu commented May 23, 2024

@jeroen79 The issue you've described appears to be a functional one, and we have a solution for you. Could you provide more details about the stability concerns? We are happy to assist you in resolving any stability issues you may be experiencing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants