Don't try to handle health-check messages in fallback chain

[KevinCathcart]

This is intended to handle the worst part of #90 (continuously sending requests to cloudflare DNS when blocked) by making the DNS spam no longer be continuous, and only happen in shorter bursts when the local servers return NXDomain. See the commit message text below (after the horizontal rule).

I'm not actually sure what the best way to test this change out locally is. There seems to be an absence of documentation around testing changes to supervisor plugins.

---

If the fallback chain takes more than 2 seconds to resolve a query the fallback plugin's internal forward plugin will think it has failed and begin sending health checks every 0.5 seconds.

By immediately returning any reply for the health-check message (even an error), it will be deemed a healthy upstream server, and health-checks will stop.

If Cloudflare is inaccessible then it is very easy for it to take more than 2 seconds to process a request, and piling on a bunch of health-check messages makes things much much worse.

Refusing this specific request should have no ill effect, as there is not normally any need to make an IN NS . request, especially of an stub or recursive resolver, and in any event, normally the main chain would handle this.

[pvizeli]

if you block it, just disable it then...

[KevinCathcart]

I strongly disagree that advising users to manually turn off the fallback if they are blocking known external DNS resolvers is an appropriate fix, at least not if fallback is enabled by default, and when blocked results in flooding the network with packets as quickly as possible, which is exactly what happens right now.

Honestly, I feel that any failure mode that acts like denial of service attempt on the local network is not really acceptable under any circumstances, but it is especially bad behavior for a default configuration. And it is not exactly like blocking external dns resolvers is an especially exotic scenario to be running in. There exist routers that offer it as a checkbox feature (at least for port 53, but I’d be unsurprised if some have not added well known DoH resolvers to that checkbox too).

It would be one thing if the fallback were opt-in, or if it were only enabled if, on first boot, supervisor detected that the dhcp offered resolver does not handle AAAA records correctly.