Weird side effect of lacking IPv4 route

I am experiencing a weird issue with DNS resolution. When I resolve a name like google.com nslookup returns both IPv4 and IPv6 answers, but if I attempt to use that (say ping google.com) the OS picks the IPv6 address

After more than hour scouring this forum and trying to disable IPv6 I finally realized I was missing a route to the Internet via the GW. Once I added this it started using the IPv4 address from the DNS response.

I guess my point is that it is misleading. Make sure you are able to route by IP address alone before you get into DNS resolution issues!!!

My setup:

I am using a Cudy WR3000 v1 running latest OpenWRT as an Access Point. It has a static IP at 192.168.11.2/24. One of the LAN ports is connected with a cable to another OpenWRT device (at 192.168.11.1/24)

I stopped/disabled dnsmasq and odhcpd

BTW: I tried to disable IPv6, but I still seem to have an IPv6 address auto assigned on the eth0 and br-lan

Commands:

Without a proper route

root@Cudy2:~# ping google.com -c 2
PING google.com (2607:f8b0:4009:802::200e): 56 data bytes
ping: sendto: Network unreachable

root@Cudy2:~# nslookup google.com
Server:         192.168.11.1
Address:        192.168.11.1:53

Non-authoritative answer:
Name:   google.com
Address: 142.250.177.78

Non-authoritative answer:
Name:   google.com
Address: 2607:f8b0:4009:802::200e

root@Cudy2:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 br-lan

After adding a proper route, now it works

root@Cudy2:~# ip route add 0.0.0.0/0 via 192.168.11.1

root@Cudy2:~# ping google.com -c 2
PING google.com (142.250.177.78): 56 data bytes
64 bytes from 142.250.177.78: seq=0 ttl=116 time=22.641 ms
64 bytes from 142.250.177.78: seq=1 ttl=116 time=132.670 ms

--- google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 22.641/77.655/132.670 ms

root@Cudy2:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.11.1    0.0.0.0         UG    0      0        0 br-lan
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 br-lan

And why did your router lack an IPv4 route?

This still seems odd.

This table is still missing information (e.g., your WAN network). Try ip -4 route

Can you show your network configuration?

I surmise you failed to configure a gateway on the LAN interface when setting up your device as an AP.

Btw if a system is dual stack, then IPv6 is preferred over ipv4 by any modern OS out there since 2 decades now.

Edit ps. Please , use ip r short for ip route show. To get IPv6 routes use ip -6 r.

Ifconfig, route, and friends are depricated since at least 2012!

1 Like
root@Cudy2:~# ip route show
default via 192.168.11.1 dev br-lan 
192.168.11.0/24 dev br-lan scope link  src 192.168.11.2 

You are correct. I did not have the default gateway setup.

The point of this post was to let folks know of this 'odd' IMO side effect

It seems the logic in the resolver library is that since I lack a IPv4 route, I should prefer the IPv6 address

Or let folks know how to setup correctly e.g. with: https://openwrt.org/docs/guide-user/network/wifi/wifiextenders/bridgedap ?

2 Likes

no the logic is since you have an ipv6 global routable address you should prefer that. this preference has been that way for 20+ years. The goal is for people to begin using ipv6 as soon as its available.

in a saner world ISPs would all have NAT64 machines and stop handing out v4 addresses entirely. Thats how TMobile networks work for example.

2 Likes

There is no IPv6 router on my network (that I know of). Output from ip route show (above) does now show an IPv6 route, correct?

Correct. Per design it does not show IPv6 routes.

1 Like

try ip -6 route show

1 Like