In our application, it’s necessary to configure the network parameters, which we do using a configuration script.
Currently, we are facing an issue with the manual DNS configuration. The problem occurs when we set a specific DNS, as domain resolution does not work. This issue is only happening on some of our terminals. However, when we switch to a public DNS, the requests are resolved correctly.
To investigate, we tested by configuring other devices with the same network parameters as the affected terminals, and they responded without any issues.
We would appreciate any suggestions or ideas to resolve this discrepancy.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
It seems you’re encountering issues with DNS resolution on some of your Toradex Verdin iMX8M Mini modules running TorizonCore, where manually configured DNS servers fail to resolve domain names, but public DNS servers work correctly. Here are some steps to help diagnose and resolve this issue:
Verify NetworkManager Configuration: Since TorizonCore uses NetworkManager to manage network settings, ensure that the DNS settings are correctly configured. You can check the current DNS settings using the nmcli command:
nmcli dev show | grep IP4.DNS
Ensure that the DNS servers listed are the ones you intend to use.
Check DNS Server Reachability: Use the ping command to verify that the DNS server is reachable from the affected terminals:
ping <your_dns_server_ip>
If the server is unreachable, there might be a network configuration issue or a firewall blocking access.
Test DNS Resolution: Use the nslookup or dig command to test if domain names can be resolved using the specified DNS server:
nslookup example.com <your_dns_server_ip>
If this fails, the issue might be with the DNS server itself or its configuration.
Compare with Working Devices: Since other devices with the same network parameters work fine, compare their network configurations with the affected terminals to identify any discrepancies.
Check for Network Conflicts: Ensure there are no IP address conflicts or subnet mismatches that could affect DNS resolution.
Firewall and Security Settings: Verify that there are no firewall rules or security settings on the network or the device that might be blocking DNS traffic.
By following these steps, you should be able to identify the root cause of the DNS resolution issue and apply the necessary fixes. If the problem persists, consider reviewing any recent changes to the network or device configurations that might have introduced this issue.
I hope this helps resolve your DNS configuration issue.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Were you able to resolve this issue with the help of @ToradexAI ?
Since you can apply the same configuration on other devices, one thing that might help is verifying whether NetworkManager is overriding your settings through resolv.conf. Did you check this?
Unfortunately, we were unable to resolve the issue with the help of @ToradexAI.
When running the command nmcli dev show | grep IP4.DNS, the DNS configuration appears to be correct. Our client also reviewed their network to ensure that firewall rules are not blocking communication. Additionally, we tested with another device configured with the same network settings, and it was able to connect to the internet without any issues.
So far, we’ve observed that when performing a traceroute to the DNS server, the first hop shows the gateway IP address as 172.17.0.1, but no further destinations are reached.
To ensure proper DNS resolution, we confirmed that the resolv.conf file is correctly updated with the appropriate DNS address. Also all tests were conducted from the host machine itself.
Thanks for confirming that resolv.conf is correctly updated.
You mentioned that this issue is only happening on some terminals. Do you have another Verdin module with the same software and network configuration that is working correctly? If so, we could compare the network settings or logs to identify any differences.
Additionally, could you check the output of ip route and nmcli device status to verify the default route and connection state? This might help us pinpoint the issue.