Client not resolving domain with local IP

Installing and Using OpenWrt
1

Hi,

With OpenWRT 23.05.5 and 24.10.1, when I try to ping host their name instead off their IP:

# ping host1.house.lan
ping: bad address 'host1.house.lan'

However :

# nslookup host1.house.lan 192.168.1.1
Server:         192.168.1.1
Address:        192.168.1.1:53

Name:   host.house.lan
Address: 192.168.1.83

In "DHCP and DNS" > "Filter", I've tried to :

  • add "host1.house.lan" or "*.house.lan" or "house.lan"
  • finally deactivate "Rebind protection" without success, both time.

If I add manually "nameserver 192.168.1.1" in /tmp/resolv.conf (or in /etc/resolv.conf) it's working some time (1-2 minutes), after the line is removed automatically.

OpenWRT is reseted, only the LAN interface is set with DHCP. It's a simple AP (TP-Link TL-WA801ND v5) one ethernet, one wifi interface.

On my computer, on the same network :

# ping host1.house.lan
PING host1.house.lan (192.168.1.83) 56(84) bytes of data.
64 bytes from host1.house.lan (192.168.1.83): icmp_seq=1 ttl=64 time=1.54 ms
64 bytes from host1.house.lan (192.168.1.83): icmp_seq=2 ttl=64 time=1.47 ms
^C
--- host1.house.lan ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.469/1.505/1.541/0.036 ms

What am I missing ?

2

And if you rerun it skipping the IP of the router?

3

Yes, local resolver :

# nslookup host1.house.lan
Server:         127.0.0.1
Address:        127.0.0.1:53

** server can't find netmana.house.lan: NXDOMAIN

** server can't find netmana.house.lan: NXDOMAIN

But :

# nslookup google.com
Server:         127.0.0.1
Address:        127.0.0.1:53

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

Non-authoritative answer:
Name:   google.com
Address: 2800:3f0:4005:40f::200e
4

Your client is bypassing the router's DNS, this a client issue, not Openwrt.

5

Sorry, Idon't understand. To be more explicit :

root@OpenWrt:~# nslookup host1.house.lan
Server:         127.0.0.1
Address:        127.0.0.1:53

** server can't find host1.house.lan: NXDOMAIN

** server can't find host1.house.lan: NXDOMAIN

root@OpenWrt:~# nslookup google.com
Server:         127.0.0.1
Address:        127.0.0.1:53

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

Non-authoritative answer:
Name:   google.com
Address: 2800:3f0:4005:40f::200e

root@OpenWrt:~#
6

The local resolver (dnsmasq) of OpenWRT is bypassing the DNS server on my network (192.168.1.1) ?

7

No, your client is running it's own resolver, bypassing the one on the router, hence the 127.0.0.1.

8

I don't understand the "your client". I'm doing the nslookup on the AP, it's the client.

When you are saying "your client", I understand my computer...

9

And we would know this how ?

echo "nameserver 192.168.1.1" >> /etc/resolv.conf should temp fix the issue for you.

Indeed, why would an AP need to be able to do this ?

10

Yes, I've tried it. But only for 1-2 minutes it's working.

11

Yes, my first post isn't explicit.

I explicit it in the 4th aswer...

12

Because it's getting a DNS server through DHCP, and the option "Use DNS servers advertised by peer" is activated for the LAN interface.

13

Not sure you want this, br-lan being a DHCP client should be good enough.

And if you get IPs from DHCP, where does 127.0.0.1 come from ?

14

Hello @Megagolgoth similar issue here, started yesterday.
I was working around a setup with kerberos and samba, which implies adding some records.

To be clear, my setup is unbound for overall resolution and dnsmasq for dhcp and local domain resolution.
As per my setup, under the unbound setup, on the dhcp section, I have configured the dnsmasq and the local domain. No changes here from long time ago.
This was working fine for a while.

If I restart unbound, the resolution for the local domain is working fine for few minutes and then it stops.

Query to unbound

root@OpenWrt:/etc/krb5kdc# dig pichisrv1-dev.pichilandia.lan @127.0.0.1 -p53

; <<>> DiG 9.18.24 <<>> pichisrv1-dev.pichilandia.lan @127.0.0.1 -p53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9791
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pichisrv1-dev.pichilandia.lan. IN      A

;; AUTHORITY SECTION:
.                       83992   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2025041801 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Apr 18 22:44:17 IST 2025
;; MSG SIZE  rcvd: 133

Query to the dnsmasq

root@OpenWrt:/etc/krb5kdc# dig pichisrv1-dev.pichilandia.lan @127.0.0.1 -p5353

; <<>> DiG 9.18.24 <<>> pichisrv1-dev.pichilandia.lan @127.0.0.1 -p5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18032
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pichisrv1-dev.pichilandia.lan. IN      A

;; ANSWER SECTION:
pichisrv1-dev.pichilandia.lan. 0 IN     A       192.168.14.231

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1) (UDP)
;; WHEN: Fri Apr 18 22:44:20 IST 2025
;; MSG SIZE  rcvd: 74

But, if I restart unbound... it works for a while.

root@OpenWrt:/etc/krb5kdc# /etc/init.d/unbound restart
9136
root@OpenWrt:/etc/krb5kdc# dig pichisrv1-dev.pichilandia.lan @127.0.0.1 -p53

; <<>> DiG 9.18.24 <<>> pichisrv1-dev.pichilandia.lan @127.0.0.1 -p53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12049
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pichisrv1-dev.pichilandia.lan. IN      A

;; ANSWER SECTION:
pichisrv1-dev.pichilandia.lan. 300 IN   A       192.168.14.231

;; Query time: 4300 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Apr 18 22:48:28 IST 2025
;; MSG SIZE  rcvd: 74
15

dnsmasq could do the work of unbound (resolver).

In "DHCP and DNS" > "Filter", I've tried to :

  • add "host1.house.lan" or "*.house.lan" or "house.lan" on "Domain whitelist"
  • finally deactivate "Rebind protection" without success, both time.

These options doesn't seems to be effective. Why ?

16

You both are using sub domains instead of a TLD.

Does this work when your OpenWrt idevices configured normally (and default software)?

17

I think in my case the rebind protection is not working as expected somehow.
Clearly the problem is located on the unbound side.
So, from there and following the config....

The rebind protection sets these lines into the unbound config:

  private-address: 10.0.0.0/8
  private-address: 100.64.0.0/10
  private-address: 169.254.0.0/16
  private-address: 172.16.0.0/12
  private-address: 192.168.0.0/16
  private-address: fc00::/7
  private-address: fe80::/10
  private-address: 127.0.0.0/8
  private-address: ::1/128

My local subnets are a match within them, however....
I also have this:


  do-not-query-localhost: no

  domain-insecure: pichilandia.lan
  private-domain: pichilandia.lan
  local-zone: pichilandia.lan transparent

And this...

forward-zone:

  name: pichilandia.lan
  forward-first: no
  forward-addr: 127.0.0.1@5353

it seems, as per my understanding of the configuration, that my local domain should bypass the private-address rules but I need to do further research, therefore it should work.
So far, it seems the rebind protection is an issue on my side. I might need to end up disabling it, and adjust the private-address rules by hand.

@lleachii the fact that is not a TLD, I dont think it is relevant at all, it is a local zone in any case.

@Megagolgoth unbound provides further functionalities and performance on my setup, so I decided to used it time ago. The fact that you see in the nslookup output "netmana.maison.lan: NXDOMAIN" is interesting. Did you try to use dig with trace? if not "nslookup -debug host1.house.lan" and/or "dig +trace host1.house.lan". DnsMasq is pretty simple setup, it shouldn't give issues.

18

It seems something is not fully ok with the background scripts.
On some unbound restarts I see

[...]
Sat Apr 19 01:49:01 2025 daemon.info unbound: [32589:0] info:    8.000000   16.000000 8
Sat Apr 19 01:49:13 2025 daemon.warn unbound: [737:0] warning: duplicate local-zone 14.168.192.in-addr.arpa.
Sat Apr 19 01:49:14 2025 daemon.notice unbound: [737:0] notice: init module 0: validator
Sat Apr 19 01:49:14 2025 daemon.notice unbound: [737:0] notice: init module 1: iterator
Sat Apr 19 01:49:15 2025 daemon.err unbound: [737:0] error: duplicate forward zone 14.168.192.in-addr.arpa. ignored.
Sat Apr 19 01:49:15 2025 daemon.err unbound: [737:1] error: duplicate forward zone 14.168.192.in-addr.arpa. ignored.
Sat Apr 19 01:49:15 2025 daemon.info unbound: [737:0] info: start of service (unbound 1.19.3).

But without any change, I restarted it again and..


[...]
Sat Apr 19 01:44:13 2025 daemon.info unbound: [27212:0] info:    1.000000    2.000000 2
Sat Apr 19 01:44:13 2025 daemon.info unbound: [27212:0] info:    2.000000    4.000000 3
Sat Apr 19 01:44:26 2025 daemon.notice unbound: [28795:0] notice: init module 0: validator
Sat Apr 19 01:44:26 2025 daemon.notice unbound: [28795:0] notice: init module 1: iterator
Sat Apr 19 01:44:27 2025 daemon.info unbound: [28795:0] info: start of service (unbound 1.19.3).

Now it is displaying the warning and errors again, not sure how this would impact yet.

19

There is also the problem of the NXDOMAIN . The TDL "lan" is not available on Internet.

20

I found that the mdns was flooding the dns server, unbound at the start and then the dnsmasq.
dnsmasq entered on a status where the traffic over the loopback was refused (tcpdump helped to figure it out), therefore not resolving those queries coming from the unbound. Post that, the unbound was redirecting the queries to the root servers and obviously, it was failing too.

Resolved by enabling "Filter SRV/SOA service discovery" under dnsmasq which enables the uci option:

# uci show dhcp  | grep win2
dhcp.@dnsmasq[0].filterwin2k='1'

Still under validation, but it looks good here.