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

Avoid repeated Cloudflare resolve attempts when DNS over TLS is blocked #134

Merged
merged 1 commit into from
Apr 4, 2024

Conversation

agners
Copy link
Member

@agners agners commented Apr 4, 2024

When a first resolve attempt on the fallback chain (:5553) fails, the fallback plug-in of the main chain will trigger health check. By default health checks sends a request every 0.5s as long as upstream reports unhealthy (default value). Unfortuntely the fallback plug-in's health check can't be confiugred currently.

Each of these health checks will trigger a 5s resolve attempt by the fallback chains forward plug-in. And since we get a health check every 0.5s, and health checks on the fallback chain are disabled, this leads to non-stop resolve attempts, forever.

On-top of that, even when the primary/DHCP provided DNS server is working, the loop plug-in will trigger a first resolve attempt on the fallback chain still! This means, even with a working primary DNS sever, the fallback chain will enter a runaway loop still!

This change does several things:

  • Handle the loop check using a template plug-in. This avoids a loop test requests to Cloudflare. With that, and a working primary DNS server, no DNS requests will get sent to Cloudflare by default.
  • Handle the health check of the fallback plug-in using a template plug-in. This essentially "disables" health check on the primary chains fallback plug-in (which would be the better approach, if that were possible).
  • Reenable health checks in the fallback chain, to avoid repeated attempts to Cloudflare when it's not available.

Fixes #90

When a first resolve attempt on the fallback chain (:5553) fails, the
fallback plug-in of the main chain will trigger health check. By default
health checks sends a request every 0.5s as long as upstream reports
unhealthy (default value). Unfortuntely the fallback plug-in's health
check can't be confiugred currently.

Each of these health checks will trigger a 5s resolve attempt by the
fallback chains forward plug-in. And since we get a health check every
0.5s, and health checks on the fallback chain are disabled, this leads
to non-stop resolve attempts, forever.

On-top of that, even when the primary/DHCP provided DNS server is
working, the loop plug-in will trigger a first resolve attempt on the
fallback chain still! This means, even with a working primary DNS sever,
the fallback chain will enter a runaway loop still!

This change does several things:
- Handle the loop check using a template plug-in. This avoids a loop
  test requests to Cloudflare. With that, and a working primary DNS
  server, no DNS requests will get sent to Cloudflare by default.
- Handle the health check of the fallback plug-in using a template
  plug-in. This essentially "disables" health check on the primary
  chains fallback plug-in (which would be the better approach, if that
  were possible).
- Reenable health checks in the fallback chain, to avoid repeated
  attempts to Cloudflare when it's not available.
@agners agners changed the title Avoid repeated Cloudlflare attempts when DNS over TLS is blocked Avoid repeated Cloudlflare resolve attempts when DNS over TLS is blocked Apr 4, 2024
@agners agners merged commit d66e8f2 into master Apr 4, 2024
10 checks passed
@agners agners deleted the fix-cloudflare-fallback-resolve-storm branch April 4, 2024 14:49
@agners agners changed the title Avoid repeated Cloudlflare resolve attempts when DNS over TLS is blocked Avoid repeated Cloudflare resolve attempts when DNS over TLS is blocked Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CoreDNS is burning CPU and spamming my network with DNS requests to 1.1.1.1
2 participants