Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom filter in hosts format should only respond to A type queries #3789

Closed
timkgh opened this issue Oct 31, 2021 · 10 comments
Closed

Custom filter in hosts format should only respond to A type queries #3789

timkgh opened this issue Oct 31, 2021 · 10 comments
Labels

Comments

@timkgh
Copy link

timkgh commented Oct 31, 2021

v0.107.0-b.13

I have a custom filter in the hosts file format of the form:
192.168.1.2 my.example.com

It works fine if I query for A record.

But AGH responds to other record types (e.g. TXT, CAA) with a SOA fake-for-negative-caching.adguard.com.
This does not seem right. Why is it responding to other record types? This is a (public) subdomain that I want the A record to be a private LAN IP (returned only by AGH) while the other record types can come via the upstream/domain DNS servers.

@timkgh
Copy link
Author

timkgh commented Oct 31, 2021

If I put it in "DNS rewrites" instead of "Custom filter" it works as expected. It would be nice to just keep all the rules in 1 place, in custom filter.

@ainar-g
Copy link
Contributor

ainar-g commented Nov 1, 2021

Have you tried using the dnsrewrite rules instead? That is, something like:

|my.example.com^$dnsrewrite=NOERROR;A;192.168.1.2,dnstype=A

This should rewrite only A queries, but let every other type be resolved by an upstream.

@ainar-g ainar-g added the waiting for data Waiting for users to provide more data. label Nov 1, 2021
@timkgh
Copy link
Author

timkgh commented Nov 2, 2021

Ah I didn't know about $dnsrewrite -- it makes sense. Thank you.

@ainar-g
Copy link
Contributor

ainar-g commented Nov 2, 2021

@timkgh, is your issue resolved then?

@timkgh
Copy link
Author

timkgh commented Nov 2, 2021

Yes, it is resolved. But should it still be considered a bug if you use the hosts file format? To me hosts format implies A or AAAA so I don't think AGH should respond to other types of queries for those rules, it should be the equivalent of the $dnsrewrite suggested above. Others may run into this problem too and be surprised by its behavior.

@ameshkov wdyt?

@ameshkov
Copy link
Member

ameshkov commented Nov 7, 2021

Actually, AGH works exactly as the hosts files are supposed to work.

If you have a line with an IPv6 address, but no lines with an IPv4 address, you'll end up with an empty NOERROR response to A.

@timkgh
Copy link
Author

timkgh commented Nov 7, 2021

@ameshkov It may work for A and AAAA queries, but it is still responding to TXT and CAA queries, I'd expect these to be forwarded upstream.

@ameshkov
Copy link
Member

ameshkov commented Nov 7, 2021

Tbh, I don't think blocklist maintainers expect us to forward TXT queries to the domains they list as blocked.

@timkgh
Copy link
Author

timkgh commented Nov 7, 2021

But this is not really blocking, it's more like a rewrite of an A record:
192.168.1.2 my.example.com
To me hosts file syntax means A or AAAA queries, but I also understand the point about blocking.
Maybe this is fine and the correct way to do it is by using $dnsrewrite

@ainar-g
Copy link
Contributor

ainar-g commented Nov 8, 2021

Yes, the usage of /etc/hosts-like syntax for DNS rewrites is more of a hack than a solution. $dnsrewrite is much more complete and flexible.

I'm going to close this issue for now, since the solution is to not use the hosts format for DNS rewrites. Please feel free to open discussions for help with the $dnsrewrite modifier syntax or issues if you find any bugs with it. Thanks.

@ainar-g ainar-g closed this as completed Nov 8, 2021
@ainar-g ainar-g added question and removed waiting for data Waiting for users to provide more data. labels Nov 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants