mirror of
https://github.com/AdguardTeam/AdGuardHome.git
synced 2026-03-04 00:01:12 -05:00
DNS rewrites BROKEN since months #3617
Labels
No labels
P1: Critical
P2: High
P3: Medium
P4: Low
UI
bug
cannot reproduce
compatibility
dependencies
docker
documentation
duplicate
enhancement
enhancement
external libs
feature request
good first issue
help wanted
infrastructure
invalid
localization
needs investigation
performance
potential-duplicate
question
recurrent
research
snap
waiting for data
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/AdGuardHome#3617
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Lovely-Maisonette on GitHub (Apr 12, 2022).
Rewrites are ignored and queries are sent upstream instead:
DNS Query (CLI) [FAILS]
DNS rewrite config and version (docker) [OK]
Adguard log entry [Answer from upstream!!!)]
Testing from within the GUI [OK!!!]
Something in the logic got broken around v107
@fernvenue commented on GitHub (Apr 12, 2022):
Maybe you can turn on verbose log and try delete this rewrite then add it again to see what's happen.
@agneevX commented on GitHub (Apr 13, 2022):
Cannot reproduce this on v0.107.5.
@Lovely-Maisonette commented on GitHub (Apr 13, 2022):
stopped, deleted all rewrites, set verbose, restarted, added just one rewrite
my.test 1.2.3.4
This is the nslookup from client 192.168.1.191 (added the DOT to prevent expansion of localdomain)
This is the verbose log
And this from the GUI
And this from the GUI filter test, which works as expected
There must be something taking precedence before the filter is applied, when the queries come from port 53
I remember something "rewrite" code being introduced around v106->v107, and then rolled back due to problems, and that rollback never fixed my issues.
I never changed my installation, only pulling regularly the latest version from < v106 times from
https://hub.docker.com/r/adguard/adguardhome
@fernvenue commented on GitHub (Apr 13, 2022):
@Lovely-Maisonette Does this client use the global settings and upstream?
@Lovely-Maisonette commented on GitHub (Apr 13, 2022):
I use my router as upstream for internal name resolution (is not enough, an therefore I need the rewrite to add CNAMES.
What is not internal should go outside. This is relevant config:
But the rewrite should bypass any upstreams.
I am not sure what you mean by "global settings"
You think there is a missconfiguration?
The rewrites stopped working after an update around one year ago I would say, and without changing the configuration.
@fernvenue commented on GitHub (Apr 13, 2022):
Of course :)
Settings - Client settings
@Lovely-Maisonette commented on GitHub (Apr 13, 2022):
yes, global settings. I have not defined any specific client settings for this or any other ip.
I moved to adguard/adguardhome:edge long ago, in the hope a fix would roll in.
@ainar-g commented on GitHub (Apr 13, 2022):
@Lovely-Maisonette, we cannot reproduce that, but we've had several similar issues. A few questions that would help us diagnose the issue:
nslookupbut with a dot at the end of the hostname? E.g.nslookup my.test..local_domain_nameparameter?Thanks.
@Lovely-Maisonette commented on GitHub (Apr 13, 2022):
Hi @ainar-g,
I will speak in the past, because I changed some things drastically in the last couple of hours.
My router is my DHCP server and main name resolution for local hosts.
The DHCP server tells the clients to use the domain casa (it is now a TLD, but it was not when I started using it. I use it for my 192.168. and 10. networks.
Adguard is my main DNS server (router the secondary/fallback)
Adguard retrievs external names from outside servers, and internal names from the DNS/DHCP router.
I have internal services that should be isolated from each other, those get their own networks and the router does not know about them. Some of them are reachable through a reverse proxy (frontend endpoints only). The reverse proxy needs to be reached by it's own name and a multitude of CNAMES, to route requests to those internal services. I used the rewrites to provide those aliases. I do not know if there is a way to automate that the same way I did with the other servers on 192.168.
but did not care, they are in the dozens, so I could maintain them by hand in the rewrite page (that page is missing some EDIT button).
Today I could not wait any longer and started looking for a fix or an alternative. At the end I deleted everything and started over. In parallel I learned from something you wrote elsewhere about dnsrewrite and made it work using the "Custom filtering rules" (that name fooled me, never looked in there before) instead of the "rewrites" (intuitively, the right place to look for creating CNAMES).
Now I have:
elastic.casa^$dnsrewrite=NOERROR;CNAME;web.casa
portainer.casa^$dnsrewrite=NOERROR;CNAME;web.casa
foo.casa^$dnsrewrite=NOERROR;CNAME;web.casa
bar.casa^$dnsrewrite=NOERROR;CNAME;web.casa
...
This works and is good enough for my needs. Unfortunately, trying to make it work, I did not think about keeping the old instance and config to help you debug this further, sorry for my shortsightedness.
I was not able to remove the .casa from there (changing the domain on the router will break it up) but as long as |I do not need to scale into the hundreds of server, I do not mind, though all I need is a simple
elastic, portainer, foo, bar -> web
The rewrite bug is still there, but maybe we need to close this ticket as "cannot reproduce" until further notice.
@ainar-g commented on GitHub (Apr 13, 2022):
I see, thanks for the feedback. We are actually planning to eventually remove the legacy DNS rewrites completely, and we've been recommending users to switch to
dnsrewriterules for a while now. Perhaps we should add a UI tip about that.@ElStupid commented on GitHub (Apr 19, 2022):
How to do dnsrewrite rules?
I'm experiencing the same kind of problems as mentioned here, although it did work for short time. I only have 1 DNS server defined, which is AdGuard Home. Now when I query for a DNS rewrite address (which is something like sub.domain.local) the logging show it's upstreamed and NXDOMAIN. Even when caching is switched off by setting it to 0 size.
I'm running v0.107.5 on my NAS in a Docker container btw.
If exchanging the legacy DNS rewrite for dnsrewrite rules makes life easier then please do so. But the interface is quite intuitive and I would be sad to see it go...
@Lovely-Maisonette commented on GitHub (Apr 19, 2022):
I am not part of the team but,
What was not working (being set upstream, instead of resolving like in the internal "check filter") for me was the
Filters/DNS Rewrites.
If I understand correctly, that is what @ainar-g calls "legacy" and to be removed sooner or later (hopefully not the other way around, not clear to me. @ainar-g?)
I discovered a second way to make rewrites a few days ago (after years of using Adward, not intuitive). in the
Filters/Custom Filtering Rules
(With than name sounds like the exception, not the rule)
I would say, it needs better documentation. I stopped when this worked for me:
portainer.casa^$dnsrewrite=NOERROR;CNAME;web.casa
Do not ask me to document it, or to know what happens if I remove CNAME, NOERROR, or ^$ which looks like an empty regular expression. IT worked for me and I moved on. Hopefully someone can expand on this:
https://github.com/AdguardTeam/AdGuardHome/wiki/Hosts-Blocklists
Still not clear why it is documented in the Blocklist. Probably GUI and Docs need revamping there.
@ElStupid commented on GitHub (Apr 19, 2022):
Exactly. I guess your finding in the custom filtering rules is the "dnswrite" @ainar-g is talking about.
With some very good documentation that would be doable also (I don't make lots of them and they don't change often).
But it would be great to do it more intuitive through the current interface.
Thanks for pointing it out, I will give it a try.
@RossComputerGuy commented on GitHub (Nov 28, 2022):
I think I'm having the same issue when doing DNS rewrites with Adguard. I get responses when I query a rewritten URL but when I use Tailscale, I get
NXDOMAIN. Is this a known issue and is it related to this? I'm running Adguard Home off TrueNAS.@dnnspaul commented on GitHub (Nov 30, 2022):
It worked for several weeks after installation, but it "suddendly" stopped working for now multiple months. I read this whole thread and enabling the option for filtering the domains with filters and hosts-file made it working again:
(sorry, but I'm using the german version. It's the first setting at "Settings -> General".) I'm using the linuxserver adguard docker image.
@RossComputerGuy commented on GitHub (Nov 30, 2022):
@dnnspaul I had the same problem where it just suddenly stopped working even without using Tailscale but your solution fixed it.
@zfedoran commented on GitHub (Dec 7, 2022):
Same issue here, worked for a while, then stopped working for one rewrite after another. At this point half work and half do not. All work when tested through the adguard web GUI test but not when testing from the terminal or other device on the same network. These used to work but have stopped working.
@dnnspaul fix didn't work as I already had this setting enabled. Flipping it on and off doesn't do anything either.
@kvervo commented on GitHub (Jan 30, 2023):
I was about to write a comment for this issue with details and steps to reproduce it :)
And then I found that in my network I had the AdBlock feature from the router vendor enabled on the router. This caused the issue and although all clients reported that DNS server was configured properly from DHCP, still the router somehow override that and forced it's own instance of DNS to take over for all client requests.
Once the feature was disable everything got back to normal.
@zfedoran commented on GitHub (Jan 30, 2023):
@kvervo which type of router are you using? I think it would be helpful to share in case anyone else has that issue
@dominikhoebert commented on GitHub (Feb 18, 2023):
Same for me, it worked fine until a few days ago and now most of them don't work anymore. All of them work through the AG web gui test. Did somebody find a solution in the meantime?
@wehrstedt commented on GitHub (Mar 16, 2023):
Got the same problem today. Im running adguard in a docker container. Today, dns rewrite stopped working and a lot of my local domains could not be resolved. I did not changed anything.
I opened the adguard dashboard to debug this issue. First thing i noticed was that the query log were disabled. 2 days ago the query log were enabled. I did not disabled it by myself. After enabling the query log i could see my local dns queries were forwarded to my upstream dns servers even dns rewrites were active and well configured.
After a while i diceded to launch a new, fresh docker container. DNS rewrite was working again. I relaunched my old container and noticed that dns blocking also does not work. I than rechecked the configuration and noticed that the option "Block domains using filters and host files" were disabled. After reactivating this option everything worked again.
I dont know what happened to the configuration. I did not changed anything at all.
@wehrstedt commented on GitHub (Mar 16, 2023):
In the adguard logs:
Maybe there is a memory leak which causes this issue?
@Cybolic commented on GitHub (Sep 20, 2023):
I was having the same problem: DNS rewrites worked fine on the local network (i.e.
nslookup myhost.local.net 192.168.x.xworked), but failed whenever I used Tailscale (i.e.nslookup myhost.local.net 100.x.x.x=>NXDOMAIN).What finally made it work was adding Tailscale's network to the
dns.private_networksconfig setting:For reference, I saw no difference between using DNS rewrites vs custom filtering rules and the "Block domains using filters and hosts files" setting didn't have any effect either.
@Wetzel402 commented on GitHub (Feb 22, 2024):
This was my problem! Thanks!