Unknown FQDNs resolved to public IP?


I have Asus RT-AX53U with OpenWrt 22.03.5 r20134-5f15225c1e / LuCI openwrt-22.03 branch git-23.093.57104-ce20b4a.

Whenever I try to resolve some FQDN that does not exist it is resolved to the router's public IP.

Previously I had TP-Link with an older OpenWRT and this was not happening.

Which setting causes that?

could you post an example ?
mask your public IP.

$ ping agstezr.iturhft.kutiz
PING <<my domain>> (<<my public ip>>) 56(84) bytes of data.
64 bytes from <<my-public-ip.my provider.domain>> (<<my public ip>>): icmp_seq=1 ttl=44 time=34.2 ms
64 bytes from <<my-public-ip.my provider.domain>> (<<my public ip>>): icmp_seq=2 ttl=44 time=36.0 ms
64 bytes from <<my-public-ip.my provider.domain>> (<<my public ip>>): icmp_seq=3 ttl=44 time=35.7 ms
64 bytes from <<my public-ip.my provider.domain>> (<<my public ip>>): icmp_seq=4 ttl=44 time=35.3 ms

What does nslookup of that name result in? Which dns service are you running on the router (dnsmasq, unbound, odhcpd)?

Also, I would expect the ping ttl to be 64 instead of 44, at least by default.

1 Like

Not only that, the reply is ~35 ms. Usually one's own router will respond in less than 1 ms. I'm thinking this is some CG-NAT and the ISP does DNS poisoning for NXDOMAIN.

$ nslookup agstezr.iturhft.kutiz

** server can't find agstezr.iturhft.kutiz: NXDOMAIN

What that would be good for? I don't want to add all possible nonexistent domains to some list...

Regarding service(s):

I am using defaults, I didn't mess with such low level config. In the process list I see two of them from your list:


Can you run it from the router?

At the router:

# ping agstezr.iturhft.kutiz
ping: bad address 'agstezr.iturhft.kutiz'
# nslookup agstezr.iturhft.kutiz

** server can't find agstezr.iturhft.kutiz: NXDOMAIN

** server can't find agstezr.iturhft.kutiz: NXDOMAIN

Is it a macOS system you're running this command on?

MacOS has its own, internal mechanism of how to resolve domains, and nslookup on macOS doesn't use it. Instead, nslookup on macOS simply asks the default DNS server. So there might be settings in place (at your computer) that make macOS ask other DNS servers than the default one, which makes nslookup and ping yielding different results.

Try scutil --dns and check the result. This gives you all the DNS servers configured on your computer, along with the domains they are used for.

The call nslookup agstezr.iturhft.kutiz a.b.c.d for every DNS servers IP address the scutil --dns gave you.

If you don't run macOS ... forget what I just said :slight_smile:

OK, I got rid of that.

I my config I had these settings:

Local server: /lan/ (the default)
Local domain: int.<<my domain>>

When I changed Local server to /int.<<my domain>>/ the behavior above stopped.


So I installed tcpdump package and tried it again with Local server: /lan/. The router at first asks for IP address of agstezr.iturhft.kutiz, gets No such name response and then it tries agstezr.iturhft.kutiz.int.<<my domain>>. At my provider I have DNS record for *.<<my domain>> pointing to my public IP, so it gets my public IP as the answer.

The help for Expand hosts setting in Advanced Settings tab of DHCP and DNS says:
Add local domain suffix to names served from hosts files.

I definitely do not have agstezr.iturhft.kutiz in my hosts file, so again: DAFUQ?

Ugh, my bad. The suffix int.<<my domain>> is added by my computer after the first resolve failure as I have search int.<<my domain>> in my /etc/resolv.conf.


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.