Welcome

• Yes, I've searched similar issues on GitHub and didn't find any.

How do you use lego?

Binary

Detailed Description

This is related to several issues. A sampling of them are:

• desec: hangs forever at waiting for DNS record propagation #1406
• Possible bad propagation check with dns-01 challenge #1777

What I believe is happening is that lego is attempting to verify the challenge record propagation and strongly preferring IPv6 if it is enabled on the host. If the remote authoritative nameserver is not responding to an IPv6 connection, lego simply loops until the challenge token expires and thus never completes issuing a certificate.

I arrived at this conclusion by starting a certificate issuance, watching the requests (tcpdump -i ${IFACE} udp port 53 | rg acme) to see that outgoing queries for the TXT record are happening to the auth server over IPv6. I then tried the same query myself on both IPv4 and IPv6:

❯ dig @ns-249-c.gandi.net _acme-challenge.example.com txt +yaml
-
  type: MESSAGE
  message:
    type: AUTH_RESPONSE
    query_time: !!timestamp 2023-01-06T14:16:03.573Z
    response_time: !!timestamp 2023-01-06T14:16:03.612Z
    message_size: 109b
    socket_family: INET
    socket_protocol: UDP
    response_address: 217.70.187.250
    response_port: 53
    query_address: 0.0.0.0
    query_port: 43704
    response_message_data:
      opcode: QUERY
      status: NOERROR
      id: 27604
      flags: qr aa rd
      QUESTION: 1
      ANSWER: 1
      AUTHORITY: 0
      ADDITIONAL: 1
      OPT_PSEUDOSECTION:
        EDNS:
          version: 0
          flags:
          udp: 1232
      QUESTION_SECTION:
        - _acme-challenge.example.com. IN TXT
      ANSWER_SECTION:
        - _acme-challenge.example.com. 300 IN TXT "gpHXXn-bXxreJ860cysiinMfymNPPwPnq2aA3rNfdhY"

❯ dig @ns-249-c.gandi.net _acme-challenge.example.com txt +yaml -6

; <<>> DiG 9.16.22 <<>> @ns-249-c.gandi.net _acme-challenge.smurf.pw txt +yaml -6
; (1 server found)
;; global options: +cmd
-
  type: DIG_ERROR
  message: |
    connection timed out; no servers could be reached

Typically, a tool such as this (as shown by the dig usage above) provides a mechanism to indicate the IP stack to use through the switches -4 and -6. If I understand https://pkg.go.dev/net#Dialer correctly, it looks like passing tcp or tcp6 to the network parameter of Dialer.Control is all that is needed in the underlying framework to make these flags possible.

Note, the Gandi nameservers do respond on port 53 over IPv6. My actual problem is something with AT&T's terrible network.