OpenWRT + AdGuard Home - OpenWRT itself cannot resolve DNS, clients can

Installing and Using OpenWrt
1

Hi,

I have a problem where OpenWRT itself loses DNS so that it cannot resolve addresses, but the clients can.

I'm running x86 OpenWRT 22.03.5 as a router.
I have installed AdGuard Home on it.

OpenWRT -> Network -> Diagnostics:

nslookup: write to '127.0.0.1': Connection refused
nslookup: write to '::1': Connection refused
ping: bad address 'openwrt.org'

Pinging an IP works fine, so it points to a DNS issue.

AdGuard handles DNS at port 53, and I've changed dnsmasq to port 5330.

(I'm not well-versed in this network and dnsmasq jungle so I don't necessarily understand the connections between eveything or use the correct terms.)

(Edit: scratch below noresolv 0 or 1 discovery, seems like noresolv wasn't the setting anymore, OpenWRT itself is still unable to resolve DNS even after changing noresolv back to 1 now and I'm not sure how to get it back to working)

Whenver I set dnsmasq's noresolv to 0 (Ignore resolv file), as the AdGuard Home guide below guides to do, that's when OpenWRT router stops resolving DNS for itself.

If I set noresolv back to 1, OpenWRT can resolve again. But that causes issues with AdGuard Home.

What I'm trying to achieve is to set OpenWRT to answer to private .lan and .arpa addresses. That doesn't work as long as noresolv is 1, which seems to cause some kind of DNS loop and tons of entries to the logs, and timeout error messages in OpenWRT's system logs.

I have followed the AdGuard Home guide from here using opkg:

And I have also tried installing it using the curl script directly from AdGuard's github.

I've tried with custom DNS on wan interface, and I've tried with DNS servers advertised by peer, but that makes no difference. Something prevents the router accessing those wan DNS servers all the same, and I don't understand why.

I can't find a setting from LuCI that would prevent or let the router use those wan DNS servers. It's probably something simple, but the reasons escape me. It's like the last piece of the puzzle is missing.

Anyone wiser mind telling me where I'm going wrong or how to make both the router and AdGuard happy?

Possibly relevant configs below:

/etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option localservice '1'
        option ednspacket_max '1232'
        list server '192.168.2.1'
        option rebind_protection '0'
        option port '5330'

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'
        list dhcp_option '6,192.168.2.1'
        list dhcp_option '3,192.168.2.1'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

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

config host
        option name 'x'
        option dns '1'
        option ip '192.168.2.22'

/etc/config/network

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

config globals 'globals'
        option ula_prefix 'removed'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.2.1'

config interface 'wan'
        option device 'eth0'
        option proto 'dhcp'
        option peerdns '0'
        list dns '9.9.9.9'
        list dns '1.1.1.1'

config interface 'wan6'
        option device 'eth0'
        option proto 'dhcpv6'

config interface 'guestwifi'
        option proto 'static'
        option ipaddr '192.168.100.1'
        option netmask '255.255.255.0'
        list dns '9.9.9.9'

Maybe the issue is in /etc/resolv.conf that it's missing the WAN IPs? If so, I don't properly understand why it would miss them and what's the way to add them:

search lan
nameserver 127.0.0.1
nameserver ::1

Just in case the settings from AdGuard Home:
Upstream DNS servers:

https://dns.quad9.net/dns-query
[/lan/]127.0.0.1:5330
[//]127.0.0.1:5330
[/in-addr.arpa/]127.0.0.1:5330
[/ip6.arpa/]127.0.0.1:5330

(I've tried to play between 192.168.2.1:5330 and 127.0.0.1:5330, but it doesn't seem to make a difference either)

Private reverse DNS servers
192.168.2.1:5330
Use private reverse DNS resolvers: ticked
Enable reverse resolving of clients' IP addresses: ticked

1 Like
2

Swap those two, if you also want local lookups to work.
Have AGH as upstream DNS resolver to dnsmasq.

1 Like
3

I have a similar setup with AGH at port 53 and dnsmasq moved to 54. Working OK for me.
May I suggest checking the bind_hosts entry in your AGH yaml file, it should have all interfaces listed (including 127.0.0.1). Something like this:

  bind_hosts:
    - 127.0.0.1
    - 192.168.2.1
    - 192.168.100.1

I prefer AGH at 53 since this allows seeing the IPs of clients in the AGH logs.

PS Unfortunately, the AGH guide only mentions that some settings should be changed in yaml file, but does not say which exactly. The good thing is that the author (@mercygroundabyss) has explained these changes in AGH related threads on the forum.

4

But it'll kill local/private DNS/ARP lookups.

5

I see OP pointed AGH for private reverse DNS to dnsmasq:

and also pointed AGH to dnsmasq for LAN domains:

not entirely sure why the last two lines are needed, though.

6

Oh man. I would've hoped there'd be a way around that, not just one or the other. Would've expected this con to come up on some tutorials if that really is the case.

The reasoning from the guide for AGH port 53 sounded good:
"The rationale for this is due to resolvers like dnsmasq forking each DNS request when AGH is set as an upstream, this will have an impact on DNS latency which is can be viewed in the AGH dashboard. You will also not benefit from being able to see the DNS requests made by each client if AGH is not your primary DNS resolver as all traffic will appear from your router."

I found this from the AdGuardHome.yaml:

  bind_hosts:
    - 192.168.20.1
  port: 53

What does it do to add more interaces there? Would adding 127.0.0.1 allow the router help resolving DNS? Like can the router/dnsmasq not bypass AGH in any way and always has to go through it?

Didn't see the AGH guide pointing that anything would need to be messed about with the .yaml file for the basic setup, unless maybe doing something with Nging reverse proxy or TLS.

7

I've tried to understand the noresolv setting and how it relates to what I'm experiencing...

noresolv 1 = OpenWRT uses its own DNS settings (is it using DNS servers set in wan interface?), and doesn't use AGH for itself.

noresolv 0 = OpenWRT uses AGH for DNS for itself that is provided by DHCP (is it using the server found from interface - lan - dhcp server - dhcp-options?).
Except OpenWRT loses its own DNS ability, so this doesn't seem to work exactly like that.

Am I understanding this somewhat correctly?

That said, does it really matter if I use one or the other? I'd prefer that the router's DNS capabilities aren't tied to AGH, therefore I'd choose noresolv 1, despite wiki's guide advising to put this to 0.

If I enable to use "Private reverse DNS servers" in AGH, I start getting these kinds of error messages in OpenWRT's System Log:

daemon.err AdGuardHome[7861]: [error] upstream 127.0.0.1:5330 failed to exchange ;lb._dns-sd._udp.0.2.168.192.in-addr.arpa. IN PTR in 2.001718925s. Cause: exchanging with 127.0.0.1:5330 over udp: read udp 127.0.0.1:55068->127.0.0.1:5330: i/o timeout

If I disable "private reverse DNS resolvers" and just choose to live without private DNS lookups, seems everything else is working fine. Using [/lan/]127.0.0.1:5335 in AGH Upstream DNS servers shows in AGH query log that 127.0.0.1 responds to .lan requests with NXDOMAIN, so that seems to work.

8

Yes, precisely. There is also a companion AGH setup post, where yaml file is described.

I tested the setup on my router with AGH stopped, there is indeed no fallback for the router to the router's WAN DNS providers. I keep noresolv option 0. Probably to have the fallback, one needs to manually add another forwarding to dnsmasq. Haven't checked.

Overall, why do you want router to go to WAN DNS, not AGH?

Curious, why do you set up this in AGH upstream DNS servers:

Also, the AGH guide suggests to add non-encrypted DNS resolvers (Cloudflare below, or any of your choice) for NTP to AGH upstream DNS servers:

[/pool.ntp.org/]1.1.1.1
[/pool.ntp.org/]1.0.0.1
[/pool.ntp.org/]2606:4700:4700::1111
[/pool.ntp.org/]2606:4700:4700::1001
9

I tried adding 127.0.0.1 to the .yaml file, but no change to the behaviour. But in hindsight, I might have had some other settings wonky already by then that the edit seemingly made no change.

Somehow I ended up breaking my OpenWRT installation enough that I chose to just wipe the slate clean. After reinstalling OpenWRT, I tried once again methodically following the wiki + the relevant forum post simultaneously (not using the provided scripts, doing by hand). Curiously the forum post mentions about adding the extra interfaces to the .yaml file, the wiki does not.

And so far AGH seems to be working (all DNS now going to AGH, noresolv=0). At least while my OpenWRT is connected to another router that I'm using in the meanwhile. But this requires some more testing still.

If this whole thing was because of not manually adding 127.0.0.1 to the AdGuardHome.yaml file, I might have saved tens of hours of frustration and troubleshooting :smiley: And more, I unsuccessfully tried this setup a year ago, but came defeated from that fight and gave up on OpenWRT.

My reasoning was merely based on my thoughts that why would the router's own connections need to be routed/filtered through AGH? I don't need to filter router's queries nor run them over DoH/DoT, I'm fine the router using my ISP's DNS directly. And thinking isn't it better that OpenWRT "natively" handles its own DNS? Or in case AGH breaks for some reason, I'd like the router still have a working DNS.

I'm coming from an Asus-Merlin router, where the router kept its own DNS (my ISP's) but the clients went through AGH that was running on another device. I felt that was easier to troubleshoot and "simpler". But maybe it doesn't really matter here.

I've removed them now, but this was mainly testing while I tried to read up on chatty Apple devices. Why send .arpa address requests upstream to an external DNS? And why do they pop up so often in my network? I thought maybe Apple's devices are so chatty with their requests because they can't get a proper response, and maybe letting them handled locally would help like other local addresses.

This testing didn't pan out yet since my OpenWRT/AGH setup wasn't working properly.

I saw the NTP addresses added in a guide. Didn't add them yet, haven't had issues with NTP that I'm aware of so passed on them for now because I couldn't see the benefit.

Buuut not so fast...

While typing this, AGH has lost the names of the devices in the query log that were just showing, now the few devices I have connected just show the IP address again.

It seemed to be related to this setting:
Network - DHCP and DNS - DNS forwardings: 192.168.2.1
or

config dnsmasq
	list server '192.168.2.1'

When I emoved that line and rebooted the router, the name resolving seemed to work again. But I couldn't get it to work consistently, after next reboot names were still only showing as IPs despite the list server line deleted. I can't get any consistency here.

Is having the router's DNS in list server in dnsmasq necessary in this setup? May I ask if you have it?

Also, in AGH's query log I'm now seeing multiple .arpa address entries from localhost at the same second highlighted in light blue where the response is "Rewritten". Then the same addresses are coming again from localhost. It seems it does it for all devices

Like this in blue in AGH:

1.2.168.192.in-addr.arpa    Rewritten   127.0.0.1
1.99.168.192.in-addr.arpa   Rewritten   127.0.0.1
6.2.168.192.in-addr.arpa    Rewritten   127.0.0.1

Then in white:

138.1.168.192.in-addr.arpa    Processed     127.0.0.1
1.1.168.192.in-addr.arpa      Processed     127.0.0.1
150.99.168.192.in-addr.arpa   Processed     127.0.0.1

Then after a few seconds again the same IPs in blue "Rewritten", and once more in white "Processed". Then no more.

My initial observation is that the above messages kept looping often when I had list server '192.168.2.1' in dnsmasq. Now I haven't had any of them for at least 15 minutes since those initial messages.

Not sure if this is how it's supposed to be, haven't seen these before.

Sorry for the amount of text, this has become more like my live venting diary as I go about with this.

10

I have it actually. Just for testing, I deleted it. It seems that nothing really changed. Router requests (127.0.0.1) still go through AGH. I personally prefer them going that way, just to be able to see all of them in AGH queries.

I also witnessed similar behaviour upon reboots, but ultimately AGH shows the device names, too. Don't really know why.

Actually, you gave examples with different addresses in your post.

It took me also a couple of attempts to get AGH running :slight_smile: I realized that setting something on OpenWrt is not a matter of one evening (my initial expectations), but rather a prolonged process. I also started documenting [with uci scripts] the settings changed to 1. understand when things go wrong and fix these easier; 2. to somewhat automate the setup to my preferred settings from the fresh install.

11

First post. New OpenWRT user who's very rusty with all things Linux. So take everything said below with a grain of salt.

I was having the same issue as OP after installing Adguard Home on OpenWRT 23.05. I couldn't ping anything, opkg was broken, etc. As suggested by @route66, I inserted 127.0.0.1 to the bind addresses within the AGH yaml file. Originally, the only bind address defined was the local IP of the router, 192.168.x.x.

I saved the file and restarted the AGH service. No joy. After rebooting the router, router based DNS resolutions work again!

Now I may proceed to download more packages (and hopefully not break things further).

-ej_breaks_the_lan

12

em uma instalação recente em meu novo setup encontrei o mesmo problema relatado. Consegui resolver o problema, identificando que as requisições estavam acusando "nslookup: write to '127.0.0.1': Connection refused"

Sendo assim, realizei a alteração da opção que fica em:

Network > DHCP and DNS > Devices & Ports > Exclude interfaces

Neste local a interface de 'loopback' estava adicionada, ela não pode estar na exclusão pois precisa atender as resoluções locais, ou então apenas o clients poderão resolver e não o openwrt

Lembre-se que a interface 'wan' deverá permanecer nesta lista de exclusão, impedindo assim que esta interface atue com resoluções DNS.

13

The preferred language in the OpenWrt forum is english.
When writing in your native language, please always provide an english translation.
This way other users all around the world can take part in the discussion and possibly benefit from the outcome, without having to use a translator.

Thanks! :slight_smile:

1 Like
14

Sorry for my mistake, I ended up answering in Portuguese. I'm answering again in English.

in a recent installation on my new setup I found the same problem reported. I managed to solve the problem, identifying that the requests were reporting "nslookup: write to '127.0.0.1': Connection refused"

Therefore, I changed the option to:

Network > DHCP and DNS > Devices & Ports > Exclude interfaces

In this place the 'loopback' interface was added, it cannot be excluded as it needs to meet local resolutions, or else only clients will be able to resolve it and not openwrt

Remember that the 'wan' interface must remain on this exclusion list, thus preventing this interface from acting with DNS resolutions.

1 Like