Nslookup, DNS, loopback and resolv.conf troubles

I have a Dynalink DL-WRX36 on OpenWrt 23.05.0-rc3 as a main router. I've set up adguardhome on port 53, reconfigured dnsmasq to 5353 and it all seems to work fine, except that I can't get the router itself to resolve anything, like when doing opkg update or anything in Network/Diagnostics. Nslookup would return:

;; connection timed out; no servers could be reached

nslookup: write to '127.0.0.1': Connection refused
nslookup: write to '::1': Connection refused

I've tried various things from this forum and otherwise and so far I've only figured that if I change /etc/resolv.conf :

search lan
nameserver 127.0.0.1
nameserver ::1

...to nameserver 192.168.66.1 (ip of the said router, running adguardhome), things start working again, but as soon as I Save and Apply anything, the file gets reverted to 127...

I've set the correct IP in DNS Forwardings under DHCP and DNS settings, as well as in lan interface "Use custom DNS servers" setting.

I just tried adding the IP to /etc/config/network loopback interface from this:

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

...to this:

config interface 'loopback'
	option device 'lo'
	option proto 'static'
    list ipaddr '127.0.0.1'
    list ipaddr '192.168.66.1'
	option netmask '255.0.0.0'

...but that totally shut me down and I had to go to failsafe mode and mounting JFFS2 to undo the thing.

Can anyone provide some guidance to fix the nslookup and other stuff from the router itself. As mentioned, everyting else seems to be working ok.

Make AGH listen to all interfaces, not only the LAN IP.

1 Like

Thanks, but how does that help the router itself? Or rather, what interface would help the issue? I tried doing it on wan interface too, but no effect.

if AGH listens to localhost too (or just try 0.0.0.0), the router will be able to resolve using it, but setting the router up to use 8.8.8.8, or some other public DNS, isn't usually a big deal.

This should not be in the loopback section... at least not in the same one as 127.0.0.1/8.

Tell me about it. I actually found it here, but it sure didn't work out for me.

Please tell me more, using 8.8.8.8 or similar would work for me. Where should I do that?

There is a major difference there -- the subnet is defined using CIDR notation per address which prevents the entire 192.0.0.0/8 subnet from getting clobbered (keeping in mind that the RFC range is 192.168.0.0/16, so it's messing up far more than just your lan).

this should actually work out of the box, unless you checked the ignore upstream DNS option (or whatever it's called, don't have a device with a WAN port nearby)

Are you saying that if I had used CIDR notation in my original attempt, like so

config interface 'loopback'
	option device 'lo'
	option proto 'static'
    list ipaddr '127.0.0.1/8'
    list ipaddr '192.168.66.1/32'
	option netmask '255.0.0.0'

...that it would have worked better?

Possibly. But you need to remote the netmask line.

And usually you don’t need to add rfc1918 addresses to the loop back stanza.

I certainly didn't check to ignore upstream DNS, that's precisely what I want.

Up until today, I was blissfully unaware of the loopback interface, but the darn router just won't resolve and keeps resetting the resolv.conf file and I just want it to stop.

If you only want to get it to work, add
echo "nameserver 8.8.8.8" > /etc/resolv.conf to your local startup script.

I'm afraid it's not that simple. This gets reset every time I Save & Apply anything, not just at boot.

Anyway, this didn't help. In fairness, it didn't shut me out either, like my original attempt, but as it doesn't make a difference, I might as well revert it.

You can configure it statically like this:

Thanks for this, however I already have all of this in place:

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.66.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	list dns '192.168.66.1' #upstream_dns

config interface 'wan'
	option device 'wan'
	option proto 'dhcp'
	option peerdns '0'
	list dns '192.168.66.1' #upstream_dns

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option peerdns '0'
	list dns '192.168.66.1' #upstream_dns

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option cachesize '1000'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option localservice '1'
	option ednspacket_max '1232'
	option port '5353'
	list server '192.168.55.1'
	option rebind_localhost '1'
	option logqueries '1'
	option noresolv '1' #split_dns

EDIT: however, I find it odd that even with the option noresolv '1', I can still edit /etc/resolv.conf, put in the DNS IP instead of 127... and nslookup will start working. That doesn't look like ignoring the file.

EDIT 2: or perhaps "ignore" was meant as in "don't update the file", as it now looks like. After noresolv option was turned on and resolv.conf updated, it hasn't been reverted back. Fingers crossed!

Thanks everyone!

If you want to set multiple addresses on an interfaces, do not write the address and a subnet-mask, but with a proper CIDR notation. (Really, there should in general never the need to write IP+subnet besides some shitty implementation. CIDR was introduced in 1993! And writing CIDR is easier al the time then fiddling with subnetmasks, Why it is still the default notation on a fresh OpenWRT is beyond my understanding but back to topic: Multiple addresses on an interfaces have to be written with CIDR, and this also works fine since ages.)

config interface 'loopback'
    option device 'lo'
    option proto 'static'
    list ipaddr '127.0.0.1/8'
    list ipaddr '192.168.66.1/24'

And again, you can assign plenty of addresses to loopback just fine.

Edit: History lesson: RFC 1519: Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy

Thanks for your input. This was only one of several attempts to solve what I needed solved (see above), but as it didn't, I didn't really know what good it would do me to have multiple addresses on the loopback, so I reverted back to original.