[SOLVED] How to get OpenWrt to forward domainless name requests?

I have my main router set up with all my local LAN IPs and names in its dnsmasq. From any computer on the network, I can ping guardian, or ping roswell and that succeeds. But I can't do that from my OpenWrt devices set up as client bridges. It works fine from computers connected TO the bridges, since they are just getting their DHCP passed through to the main router. It just doesn't work when I am logged into the client bridges themselves.

OpenWrt sets its resolv.conf to point to 127.0.0.1, so I am trying to configure the client bridges dnsmasq to pass on domainless DNS requests to the main server. I turned off "Domain Required" on the setup page, which boils down to removing "domain-needed" from the dnsmasq config. What else is needed to get this to work?

I suppose I could just manually point resolf.conf to the main router, but I'd rather figure out how to get dnsmasq configured properly. Any ideas?

/etc/config/dhcp is below:

config dnsmasq
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option expandhosts '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option ednspacket_max '1232'
	list server '192.168.2.1'
	option localservice '0'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

To configure the DNS server on the devices.

You have removed the domain lines:

uci set dhcp.@dnsmasq[0].local='/lan/'
uci set dhcp.@dnsmasq[0].domain='lan'
uci commit dhcp
service dnsmasq restart

I did that as part of the troubleshooting, wondering if dnsmasq was automatically adding .lan to the domain before sending it. I've added those config lines back in and no effect. Here is what happens:

root@horizon:~# ping guardian
ping: bad address 'guardian'
root@horizon:~# echo "nameserver 192.168.2.1" > /etc/resolv.conf
root@horizon:~# ping guardian
PING guardian (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: seq=0 ttl=64 time=1.214 ms
64 bytes from 192.168.2.1: seq=1 ttl=64 time=4.181 ms
64 bytes from 192.168.2.1: seq=2 ttl=64 time=1.079 ms
64 bytes from 192.168.2.1: seq=3 ttl=64 time=1.934 ms
^C
--- guardian ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.079/2.102/4.181 ms
root@horizon:~# echo "nameserver 127.0.0.1" > /etc/resolv.conf 
root@horizon:~# ping guardian
ping: bad address 'guardian'

So the upstream nameserver works fine. Just the local dnsmasq isn't passing the requests.

With the following config:

option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option localservice '1'
option ednspacket_max '1232'

I can see that the packet with the query for the ping:

root@whale:[~]#ping asdf
ping: bad address 'asdf'

goes upstream:

19:24:36.150210 IP (tos 0x0, ttl 64, id 28366, offset 0, flags [DF], proto UDP (17), length 50)
    192.168.10.47.59914 > 1.1.1.1.53: 19103+ A? asdf. (22)
19:24:36.151025 IP (tos 0x0, ttl 64, id 28367, offset 0, flags [DF], proto UDP (17), length 50)
    192.168.10.47.36885 > 1.1.1.1.53: 58049+ AAAA? asdf. (22)
19:24:36.173950 IP (tos 0x0, ttl 55, id 10462, offset 0, flags [none], proto UDP (17), length 125)
    1.1.1.1.53 > 192.168.10.47.59914: 19103 NXDomain 0/1/0 (97)
19:24:36.174179 IP (tos 0x0, ttl 55, id 10461, offset 0, flags [none], proto UDP (17), length 125)
    1.1.1.1.53 > 192.168.10.47.36885: 58049 NXDomain 0/1/0 (97)

the response of course is expected.

1 Like

put a dot after it. now retry.

That's really useful, thank-you. I should have done this myself, but figured I'd just misconfigured something dumb.

... time passes ...

Ok, so I have more information and I'm actually more confused. From tcpdump on lo and wlan0

root@horizon:~# ping hermes [note: hermes=192.168.2.5]
15:46:03.114272 IP 127.0.0.1.40294 > 127.0.0.1.53: 41741+ A? hermes. (24)
15:46:03.114367 IP 127.0.0.1.40294 > 127.0.0.1.53: 44049+ AAAA? hermes. (24)
15:46:03.114618 IP 192.168.2.6.32941 > 192.168.2.1.53: 7747+ A? hermes. (24)
15:46:03.114720 IP 192.168.2.6.32941 > 192.168.2.1.53: 7747+ A? hermes. (24)
15:46:03.114870 IP 192.168.2.6.32941 > 192.168.2.1.53: 7747+ A? hermes. (24)
15:46:03.115291 IP 192.168.2.6.41233 > 192.168.2.1.53: 13247+ AAAA? hermes. (24)
15:46:03.251294 IP 192.168.2.1.53 > 192.168.2.6.32941: 7747* 1/0/0 A 192.168.2.5 (40)
15:46:03.251436 IP 192.168.2.1.53 > 192.168.2.6.32941: 7747* 1/0/0 A 192.168.2.5 (40)
15:46:03.251468 IP 192.168.2.1.53 > 192.168.2.6.32941: 7747* 1/0/0 A 192.168.2.5 (40)
15:46:03.251795 IP 127.0.0.1.53 > 127.0.0.1.40294: 41741* 0/0/0 (24)
15:46:03.305077 IP 192.168.2.1.53 > 192.168.2.6.41233: 13247 0/0/0 (24)
15:46:03.305332 IP 127.0.0.1.53 > 127.0.0.1.40294: 44049 0/0/0 (24)
ping: bad address 'hermes'
  1. The machine in question (horizon @ 192.168.2.6) is trying to ping hermes (192.168.2.5)
  2. The resolver tries to resolve "hermes."
  3. The resolver first asks the local dnsmasq at 127.0.0.1 for an A and AAAA record.
  4. dnsmasq forwards it on upstream
  5. upstream responds to the A inquiry with the correct IP
  6. upstream has no IPv6, so correctly responds with "No error, answer 0" on the AAAA record
  7. dnsmasq ignores the correct A responses it received and responds back with answer 0 on BOTH the A and the AAAA requests

So the local dnsmasq is forking up somewhere. I just don't know if this is a configuration issue, or a dnsmasq issue.

Rebind protection will prevent dnsmasq from passing along a local IP returned from upstream. Disable rebind protection and try again.

4 Likes

Perfect, thank-you.

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