Do not use 0.0.0.0 as response for adblocked domains

[ameshkov]

@iskradelta commented on Thu Oct 17 2019

Let this be a configuration option, which "ip" to return for adblocked domains, or NXERROR.

Example: node_modules/.bin/dnstls @176.103.130.130 +tls-host=dns.adguard.com googleads.g.doubleclick.net
"answers": [
{
"name": "googleads.g.doubleclick.net",
"type": "A",
"ttl": 3274,
"class": "IN",
"flush": false,
"data": "0.0.0.0"
}

This is a problem, since a client using AdGuard DNS servers above, or Firefox browser on laptop, if vising any shitty webpage or using any shitty application! They could try to connect to services running on Android phone or laptop, just because they have http://googleads.g.doucleblick.net:anyport and basically perform any kind of queries to, supposedly "local" services. This is worse since many developers think running stuff on localhost, or bound to any of their "internal" interfaces is not exposed to the internet.

When using AdGuard DNS, by default, its possible for any program to access services on localhost.

Specifying an address such as 127.6.6.6 as response, or NXERROR would fix the problem.

[ameshkov]

NXDOMAIN is problematic, Apple devices may fall back to a different DNS when they receive it.
Smth like 127.X.X.X is an option indeed, we should try it.

[iskradelta]

I know, hence it would be good to have an option in dnsproxy - when upstream (using adguard dns as upstream but have my own slef-hosted version) says nxdomain error, Id like reply with my own choice of 127.5.6.7 or similar - where I know none of my local services are running on any of my devices.

Or, alternative solution, to rewrite any 0.0.0.0 responses from any upstreams, to one of my choice. But 0.0.0.0 by default is really bad, it should be 127.0.0.1 to lower chances of ads "accidently" making connections and spreading malware on any interfaces.

[ameshkov]

Ah, I got it now.

Well, dnsproxy is supposed to simply proxy DNS queries/responses, not modify it.

We could add a setting for that to AG Home so that you could define what exactly is returned when a request is blocked.

[iskradelta]

Thats OK, I can run my own AG Home. Do you have pointers where in the code the change should be done?

[ameshkov]

Well, now that we have AdGuard DNS with the option of having a personal server, this task should be revived.

Planned for a future update, thanks for the reminder.

[Apocalypsing]

Specifying an address such as 127.6.6.6 as response, or NXERROR would fix the problem.

Responding back with loopback addresses also isn't ideal.

Basically, the issue comes down to indefinite spam of endless connection attempts by clients. If a client is receiving a loopback address after doing a DNS query for a specific domain, most if not all clients will go through with a connection attempt, believing it is a valid IP address. But since most people aren't hosting a web server on their devices - especially on the loopback interface - the client will fail and retry to reconnect, indefinitely.

I think a better method would be to respond back to the client with some kind of error, instead. In the past I have used Unbound as a DNS resolver, and it was set up with a DNS blocklist and to respond to blocklisted queries with the DNS query typed REFUSED, and that setup worked very well for me in the time I used it.

So maybe the REFUSED response code could work? While I do think that null-routed addresses like 0.0.0.0 or 0::0 are good defaults, I do agree that having the option to change how blocked responses are handled would be great to have.

Also, I am aware this issue is quite old. But I saw that it was still open, and that nobody else had mentioned the issues that can come up with loopback addresses in DNS query results, so I thought I'd jump in clarify.