DNS/Filter Rewrite Behavior Change

[DrDoug88]

Prerequisites

• I have checked the Wiki and Discussions and found no answer

• I have searched other issues and found no duplicates

• I want to report a bug and not ask a question or ask for help

• I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, AMD64 (aka x86_64)

Installation

Docker

Setup

On one machine

AdGuard Home version

v0.107.36

Action

A DNS lookup

Expected result

It should resolve to the selected IP in the DNS rewrites table.

Actual result

It resolved to a different IP.

Additional information and/or screenshots

I have been using AdGuardHome for the past year, and upgraded through various versions along the way. However, this most recent upgrade from v0.107.36 to v0.107.38 seems to have caused some issues. (Looking at the AGH releases, it was likely v0.107.37 where the logic changed). Anyhow, I am using a split-horizon DNS setup, stretching out a single base domain name with multiple destinations. Here is the specific issue:

DNS Rewrites Table:

example.com			1.2.3.4
*.example.com			1.2.3.4
*.external.example.com		A
*.internal.example.com		5.6.7.8

With v0.107.36 and prior, this logic worked fine. Even with the wildcard, if resolving abc.internal.example.com, it would return 5.6.7.8, while abc.example.com would resolve to 1.2.3.4.

However, with v0.107.38, abc.internal.example.com returns 1.2.3.4. It appears as if it is finding *.example.com first in the lookup process rather than *.internal.example.com.

Was this change intentional? If so, could there be an option to revert to the prior logic?

Thank you for all of your hard work.

[codyjd1]

I have the same issue.
For now i have done abc.example.com for all external (instead of wildcard), and *.internal.example.com for internal. But the rewrite table worked fine for me as well before V0.107.37 with the same wildcard setup as you @DrDoug88.

[DrDoug88]

Thank you for confirming @codyjd1.

It works fine this way in Dnsmasq, i.e.

address=/.example.com/1.2.3.4
address=/.internal.example.com/5.6.7.8
server=/.external.example.com/<IP of AdGuardHome>
server=<IP of AdGuardHome>

So in the worst case, I'll have to use Dnsmasq as primary DNS server for host to intercept those requests, and then pass everything else to upstream AdGuardHome. But I wish I didn't have to, since I have already designed functions that access AGH's API to add/remove rewrite entries...

[codyjd1]

Thank you @DrDoug88 for the example appreciate it! For now i will probably keep mine as is but hoping its fixed in the future back to how it was, as I had no issues prior to V0.107.37. I hope as well if we can get some clarification on what has changed or easier workaround.

[EugeneOne1]

@DrDoug88, hello and thanks for a thorough report and a test case. It's indeed a bug and we're going to release the fix in the edge channel later today.

[EugeneOne1]

@DrDoug88, hello again. We've pushed the newest edge build that should fix the legacy rewrites priority. Could you please check if it does?

[DrDoug88]

@EugeneOne1 Thank you for addressing this so quickly! Yes, I pulled the most recent edge build and it works as before. Closing.

[mxbchr]

I'm experiencing this issue since I've updated to V0.107.39. Release notes link this issue and say it has been addressed.

I have set a few DNS rewrites so that the selfhosted services can be accessed by there internal IP while I'm home. Most services are run through a reverse proxy at 10.0.2.8 with hostname *.example.org, only the vnp server is hosted on 10.0.2.1 with hostname vpn.example.org.
So I set the rules:

||example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.8
||vpn.example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.1

This worked perfectly fine until a few hours ago. anything.example.org returned 10.0.2.8, vpn.example.org returned 10.0.2.1.
Now the DNS query suddenly gives back two A records:

"Non-authoritative answer:
Name: vpn.example.org
Address: 10.0.2.1
Name: vpn.example.org
Address: 10.0.2.8"

Setting the rule to:
||vpn.example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.1,important
does not solve the issue.

Neither does:
@@||vpn.example.org^$dnsrewrite=10.0.2.8
||vpn.example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.1
both with and without important modifier.

Details from query log:
"Response details
Status: Rewritten
Elapsed: 0.15 ms
Response code: NOERROR
Rule(s):
||vpn.example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.1
||example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.8
Custom filtering rules

Response:
A: 10.0.2.1 (ttl=10)
A: 10.0.2.8 (ttl=10)"

I feel like this is related to this issue/the fix.
@EugeneOne1 Is someone gonna reopen it or should I open a separate Issue?

[ppfeufer]

Try:

||example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.8
|vpn.example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.1

[mxbchr]

Try:

||example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.8
|vpn.example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.1

Did so, thanks. But it doesn't change anything unfortunately.

Neither did either one of these:
@@||vpn.example.org^$dnsrewrite=NOERROR;A;10.0.2.8,important
@@||vpn.example.org^$dnsrewrite=10.0.2.8,important
@@||vpn.example.org^$client=10.0.2.0/24|192.168.3.0/24,dnsrewrite=NOERROR;A;10.0.2.1
@@||vpn.example.org^$dnsrewrite=10.0.2.8,client=10.0.2.0/24
plus
||vpn.example.org^$client=10.0.2.0/24,dnsrewrite=NOERROR;A;10.0.2.1