lego waiting for DNS propagation when TXT record is set

[mrmelon54]

lego is constantly waiting for dns propagation probably due to DNS issues.
This is in a test environment with PEBBLE_VA_ALWAYS_VALID due to me testing that my program uses lego correctly as a library.
The DNS server is custom built just to respond to the TXT requests to prevent external conditions messing with the tests.
I have checked with dig that the TXT record is set correctly.
Is it possible to make lego skip the DNS propagation?
Or is there specific DNS record setup I need to make lego resolve correctly?

[ldez]

hello,

The DNS propagation check is unrelated to your ACME server: this check is done by lego by calling the DNS servers.

You have to set Nameservers/resolvers,
The default is to use the system resolvers, or Google's DNS resolvers if the system's cannot be determined.

You can:

• update your system resolvers /etc/resolv.conf
• add custom DNS resolvers:

  err = client.Challenge.SetDNS01Provider(provider, dns01.AddRecursiveNameservers(dns01.ParseNameservers([]string{"1.1.1.1"})))

• disable the propagation check (I don't recommend that):

  err = client.Challenge.SetDNS01Provider(provider, dns01.DisableCompletePropagationRequirement())

SetDNS01Provider
AddRecursiveNameservers
ParseNameservers
DisableCompletePropagationRequirement

FYI, lego not LEGO 😉

[mrmelon54]

Defining a nameserver with a port doesn't work as lego tries to do SOA records and attempts to connect to the nameserver listed there. Which I am unable to provider as I can't listen on port 53 without root.

[ldez]

lego tries to call your DNS to get SOA records to determine the "zone", it's not related to the propagation check.

There is no DNS server ("listen") inside lego, lego just calls the DNS through port 53 (if there are entries with port 53), it's a client call, so it's not related to root rights.

I think your problem is related to a firewall configuration or a misconfigured local DNS server.

[mrmelon54]

I am trying to configure my a custom DNS server specific for testing if my wrapper around the lego certificate renewal works correctly. Unfortunately something somewhere seems to pickup a different dns server to connect to even though I added the RecursiveNameservers option.

[hello.example.test] acme: error: 400 :: urn:ietf:params:acme:error:connection :: Get "http://hello.example.test:5002/.well-known/acme-challenge/ui72Dhtk9M00kqQBAsPbWVEWRloR-6SWnYrDZBSOXmo": dial tcp: lookup hello.example.test on 192.168.1.1:53: lame referral

[ldez]

If a DNS query is answered in a way that indicates that the responder is not authoritative for the expected zone, the result is called lame.
So it's related to your DNS configuration, you should be authoritative.
I will not be able to help you with the configuration of your DNS server.

[mrmelon54]

Yep I understand that, my issue is its trying to use "192.168.1.1:53" when I set it to use "127.0.0.1:5053"
That's why the DNS configuration is wrong because it's not asking the correct nameserver
I decided in the end to just disable the propagation as I'm using my own dns server it doesn't need to propagate and it seems to work now. Along with the PEBBLE_VA_ALWAYS_VALID=1 environment variable to force pebble to allow my random test fqdn.