I recently came up with a strange DNS issue which is confuses me a lot. Below is my setup scenario.
I have two wan interfaces which are obtaining IP settings with DHCP from each connected router. DNS server addresses are also included. since the /etc/resolve.conf is overwritten when an interface state changes I have configure the resolve file (local DNS file) to be "/etc/resolv.conf" in DHCP and DNS page. I didn't want to brake the symlink of that file. The reason of that action is because when I was trying to update, the command was failing due to missing DNS servers in that file. So in the file now are listed all DNS servers which are configured or obtained on every interface.
Now the issue.
- Both Wan 1 and Wan 2 are up and their obtained DNS servers are inside the the /etc/resolv.conf.
- Wan 1's DNS servers are not reachable.
- When trying to ping an FQDN with wan1's ip as a source the system is not resolving the FQDN. I get the error bad address. Same apply when I try to ping the FQDN with wan2's ip as a source. Instead when I use ip as destination the result is as expected. From wan 1 destination is unreachable from wan2 I have replies.
When I replicate the unreachable situation on wan 2 and do the pings with same parameters and FQDN both interfaces are resolving but only wan 1 gets replies. Result as expected.
I am very confused of how the system itself uses the DNS resolving or it might be something with routing. Is there a way to monitor the DNS servers and tell to the system which DNS to use at the time?
Any help will be highly appreciated.
Once included in "
/etc/resolv.conv", DNSs are not tied to any interface, and PING's source address is not used to determine the DNS to use: the PING command first resolves the FQDN (using whatever DNSs are configured at "
/etc/resolv.conf"), then sends the ICMP echo request (using the interface associated to the source IP address you specified).
In the default configuration:
/etc/resolv.conf is symlink to /tmp/resolv.conf
/tmp/resolv.conf will point to localhost <- this is dnsmasq
/tmp/resolv.conf.ifname will contain the nameservers learnt from the interface ifname
/tmp/resolv.conf.auto this is the file that dnsmasq uses to forward the queries.
This works pretty fine with multiple NS from multiple sources. So better stick to that.
The source address in the ping does not determine the egress interface, routes/metrics/rules do. If you want to force the ping out of an interface, use the
-I eth1 option for example.
Regarding your example, I can guess that the FQDNs you are trying to resolve and ping are provider specific.
But if you don't provide all the fact we cannot help.
Thank you for the complete point of the resolve files. In fact you are correct, After research and tests, I found that the egress port couldn't be defined by the IP of the interface.
The problem finally was not on the DNS resolution but on the touting itself. When I removed the route which corresponds to unreachable path the DNS works. However there are plenty of tools which you cannot play with egress port like openvpn and speedtest-cli. Openvpn is minor since you can bind the instance with an ip and then play with ip rules and tables to routing tables the connection from a specific interface and if you wan to force the instance down you can simply disable it.
But on speedtest-cli I cannot find such option to use egress port.
So at the moment I need to write a ping test script to check the connections and then apply some actions.
Can you point me to an example apart from pingcheck package?
You can manilulate the locally generated traffic with this:
ip rule add iif lo to default lookup XXX prio 16030