Redirecting blocked hosts to localhost by returning 0.0.0.0 instead of NXDOMAIN is not ideal

Hi. Since this doesn't seem to be a security issue*, even though both Firefox [1] and Chrome/Chromium [2] allow this to happen currently, with both NextDNS and Cloudflare's 1.1.1.3 DNS server, I guess it's okay to post it here, publicly.

This affects only macOS(untested) and Linux, but not Windows(untested).

NextDNS returns 0.0.0.0 for blocked hostnames, instead of NXDOMAIN, just like Cloudflare's 1.1.1.3 server. This is the same as returning 127.0.0.1, thus DNS Rebinding attacks on localhost are possible.

You can try running netcat listening on port 443 as root to see both Firefox and Chrome/Chromium connecting to it:

# nc -l -p 443 -s 127.0.0.01

then make sure the hostnames incoming.telemetry.mozilla.org and accounts.google.com and www.google.com are blocked in your NextDNS (or see below for another way to do it), and open Firefox or Chromium, and you'll see some garbage text on the terminal where netcat's running including the hostname that was tried.

You can emulate NextDNS returning 0.0.0.0 instead of NXDOMAIN by using the following lines in /etc/hosts:

0.0.0.0 incoming.telemetry.mozilla.org

0.0.0.0 www.google.com

0.0.0.0 accounts.google.com

or you can even, for tests, replace 0.0.0.0 with 127.0.0.1 since this is what happens anyway. Yes, this means that if you have lines with 0.0.0.0 in /etc/hosts from long ago, they're pointing to localhost, instead of pointing to nothing despite what https://en.wikipedia.org/wiki/0.0.0.0 says

This works whether you have NextDNS set in /etc/resolv.conf (and you used Link-IP to update the linked IP), or you're using systemd-resolved or you're using dnsmasq. (I've also tested 1.1.1.3 of cloudflare as DoH and in /etc/resolv.conf)

However for the latter (dnsmasq), I have two workarounds. You can either starts dnsmasq with --stop-dns-rebind argument, or(/and) you can add this line to /etc/dnsmasq.conf:

bogus-nxdomain=0.0.0.0

both prevent DNS Rebinding attacks on localhost from being enabled by the use of NextDNS (or by the use cloudflare's 1.1.1.3 dns server), thus the latter makes dnsmasq return NXDOMAIN for any domain that resolves to 0.0.0.0

Both of those I want(ed) to suggest to be added on the Setup page for dnsmasq, with regards to NextDNS.

You can also try to ping ablockedhosthere or ping 0.0.0.0 to see it pings your localhost, although ping is a bit of a special case because it returns the source IP as the replier, even though internally it can ping 0.0.0.0 if you remove two lines and recompile it:

Index: /var/tmp/portage/net-misc/iputils-20211215/work/iputils-20211215/ping/ping.c
===================================================================
--- .orig/var/tmp/portage/net-misc/iputils-20211215/work/iputils-20211215/ping/ping.c
+++ iputils-20211215/ping/ping.c
@@ -775,8 +775,14 @@ int ping4_run(struct ping_rts *rts, int
 bind_to_device(rts, sock->fd, rts->whereto.sin_addr.s_addr);
 }

-if (rts->whereto.sin_addr.s_addr == 0)
-rts->whereto.sin_addr.s_addr = rts->source.sin_addr.s_addr;
+        //ping -c 1 -B -I 127.0.0.22 bruh  (where "0.0.0.0 bruh" is in /etc/hosts)
+        //PING bruh (0.0.0.0) from 127.0.0.22 : 56(84) bytes of data.
+        //64 bytes from 127.0.0.22 (127.0.0.22): icmp_seq=1 ttl=65 time=0.013 ms (DIFFERENT ADDRESS!)
+        //originally:
+        //PING bruh (127.0.0.22) from 127.0.0.22 : 56(84) bytes of data.
+        //64 bytes from 127.0.0.22 (127.0.0.22): icmp_seq=1 ttl=65 time=0.046 ms
+//if (rts->whereto.sin_addr.s_addr == 0)
+//rts->whereto.sin_addr.s_addr = rts->source.sin_addr.s_addr;

 if (rts->broadcast_pings || IN_MULTICAST(ntohl(rts->whereto.sin_addr.s_addr))) {
 rts->multicast = 1;

therefore even ping can access 0.0.0.0 as 127.0.0.1, however the  source of the reply is reported(visually) wrongly.

Bottom line is, returning NXDOMAIN for blocked hosts, if you want to avoid DNS Rebinding attacks on your localhost, is pretty much required. (maybe use the above dnsmasq workarounds for now?) Quad9 already does this, smart of them!

* doesn't appear to be a security issue because both Chromium and Firefox are talking about it openly in public bugs, and NextDNS and Cloudflare appear to be using 0.0.0.0 instead of NXDOMAIN and they wouldn't really do this unless they knew that returning 0.0.0.0 is the same as returning 127.0.0.1 ... or am i wrong?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1672528#c17

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=1300021