DNS Validation - Fallback to configured/system DNS servers when authoritative name servers for a domain cannot be contacted

[JT-Moore]

In situations where a firewall prevents the client from sending DNS queries directly to any of the authoritative servers for a domain,
LookupClientProvider.GetNameServers() should fallback to using the configured or system DNS servers.

This can be easily implemented by changing the following line in LookupClientProvider.GetNameServers() from:

 verified = backup?.ToList() ?? new List<IPAddress>();

to:

 verified = backup?.ToList() ?? ParseDefaultClients();

Doing that would allow DNS validation plugins to work in environments where clients are required to only use specific recursive DNS servers.

[WouterTinus]

At first glance I'd say your change doesn't actually change anything. When GetNameServers returns an empty list, CreateLookupResult falls back to the _systemclient, which uses those same defaultclients.

[JT-Moore]

That's probably right. I think the issue I was having was ultimately due letsencrypt returning cached results from a previous http-01 validation resulting in an dns-01 unavailable error when I tried to switch validation methods. I guess there is unfortunately no way to make them ignore their cached validation on their  side too (other than switching hostnames for testing or waiting for the previously cached validation to expire) which makes it unnecessarily hard to confirm that everything is working correctly when switching from one validation method to another.Thanks anywayJT MooreOn May 18, 2024, at 1:12 AM, Wouter Tinus ***@***.***> wrote: At first glance I'd say your change doesn't actually change anything. When GetNameServers returns an empty list, CreateLookupResult falls back to the _systemclient, which uses those same defaultclients. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[WouterTinus]

I guess there is unfortunately no way to make them ignore their cached validation on their side

You could create a new account for that purpose.

[JT-Moore]

It looks like there may be a way to delete a cached authorization on the server side: https://datatracker.ietf.org/doc/html/rfc8555#section-7.5.2 I expect most people want that to happen too when using –nocache. Would it be possible to add support for that to win-acme? From: Wouter Tinus ***@***.***> Sent: Saturday, May 18, 2024 7:22 AM To: win-acme/win-acme ***@***.***> Cc: JT Moore ***@***.***>; Author ***@***.***> Subject: Re: [win-acme/win-acme] DNS Validation - Fallback to configured/system DNS servers when authoritative name servers for a domain cannot be contacted (Issue #2583) I guess there is unfortunately no way to make them ignore their cached validation on their side You could create a new account for that purpose. — Reply to this email directly, view it on GitHub <#2583 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOKX5EH22G5RZ24CEJTFQDTZC42T5AVCNFSM6AAAAABH5DZXLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJYG44DIOJQHA> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AOKX5EBCAH45XDFGYELAPPDZC42T5A5CNFSM6AAAAABH5DZXLSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT6JILYY.gif> Message ID: ***@***.*** ***@***.***> >

[WouterTinus]

Would it be possible to add support for that to win-acme?

That's been included in version 2.2.9.1

[JT-Moore]

Fantastic! Thank you From: Wouter Tinus ***@***.***> Sent: Saturday, May 25, 2024 3:12 PM To: win-acme/win-acme ***@***.***> Cc: JT Moore ***@***.***>; Author ***@***.***> Subject: Re: [win-acme/win-acme] DNS Validation - Fallback to configured/system DNS servers when authoritative name servers for a domain cannot be contacted (Issue #2583) Would it be possible to add support for that to win-acme? That's been included in version 2.2.9.1 — Reply to this email directly, view it on GitHub <#2583 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOKX5EF26BKFAMQ4I7C6YXLZEDPBTAVCNFSM6AAAAABH5DZXLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZRGQYDKMRVHE> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AOKX5EDWUSJTXFCDT3B7MMLZEDPBTA5CNFSM6AAAAABH5DZXLSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT7BKU4W.gif> Message ID: ***@***.*** ***@***.***> >