Only public DNS working

[Isaga]

Hi everyone,

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.

Software summary

Bootloader: U-Boot
Kernel version: 5.15.148-6.6.1-devel+git.23a8e831749d #1-TorizonCore SMP PREEMPT Thu Jun 6 16:07:46 UTC 2024
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/97aecdfa8d25bbbbbbe111188a87cad2b0d7a58c8d96a231b0e53e1626d96c23/0
Distro name: NAME=“TorizonCore”
Distro version: VERSION_ID=6.6.1-devel-20240822192531-build.0
Distro variant: VARIANT=“Docker”
Hostname: Atizapan1N104

Hardware info

HW model: Toradex Verdin iMX8M Mini on Verdin Development Board
Toradex version: 0057 V1.1B
Serial number: 15034756
Processor arch: aarch64

[ToradexAI]

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. Check for Network Conflicts: Ensure there are no IP address conflicts or subnet mismatches that could affect DNS resolution.

6. 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:

Issue using the torizoncore-builder deploy... command

Hardware: Colibri iMX6DL with Viola Carrier Board Rev 1.2 Torizon version 6 Hi there, We are currently seeing an error while trying to use the torizoncore-builder deploy… command i.e. $ torizoncore-builder deploy custom-branch --remote-host 192.168.0.xx --remote-username torizon --remote-password xxx --reboot The output is reporting an error… Starting OSTree pull on the device… Password: error: While fetching http://localhost:34501/objects/b1/f302c75879b156d68fdb4fd538cc95e80884bb011c4…

Problem configuring a Static Network Configuration

Hi everyone, I’m experiencing issues configuring the DNS using nmcli within the container. The problem arises when attempting to modify the ipv4.DNS parameter. I can successfully change the ipv4.addresses, gateway, and method settings without any problems. However, the error I encounter is as follows: root@IB-1:~# nmcli con mod network0 ipv4.dns 8.8.8.8 Error: Failed to modify connection 'network0': ipv4.dns-data: unknown property As I mentioned, this issue only occurs when running inside the…

DNS Server IP.

[daniel_m.tx]

Hello @Isaga !

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?

Best regards,
Daniel Morais

[Isaga]

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.

[daniel_m.tx]

Hi @Isaga ,

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.

Best regards,