caddyserver / certmagic

Automatic HTTPS for any Go program: fully-managed TLS certificate issuance and renewal
https://pkg.go.dev/github.com/caddyserver/certmagic?tab=doc
Apache License 2.0
4.99k stars 286 forks source link

could not find the start of authority #161

Closed hongyi-zhao closed 2 years ago

hongyi-zhao commented 2 years ago

I use certmagic via a thin wrapper but failed as follows:

$ login_token="ID,Token"
$ certgrabber -domain bp.hyddns.xyz -provider dnspod -token $login_token -challenge-type dns-01
Getting cert for domain: bp.hyddns.xyz
bp.hyddns.xyz: obtaining certificate: [bp.hyddns.xyz] Obtain: [bp.hyddns.xyz] solving challenges: presenting for challenge: could not determine zone for domain "_acme-challenge.bp.hyddns.xyz": could not find the start of authority for _acme-challenge.bp.hyddns.xyz.: NOERROR (order=https://acme-v02.api.letsencrypt.org/acme/order/324767840/48975851400) (ca=https://acme-v02.api.letsencrypt.org/directory)

See here for related discussion. Any hints for fixing this problem?

Regards, HZ

francislavoie commented 2 years ago

Certmagic makes DNS queries to find an SOA record so that we know what the "base domain" is, so it can tell the DNS plugin the base domain/zone.

Real quick, I tried looking for an SOA for your domain, and it looks fine: https://mxtoolbox.com/SuperTool.aspx?action=soa%3ahyddns.xyz&run=toolpage

So I figure whatever DNS server your system is configured to use isn't resolving it 🤷‍♂️

hongyi-zhao commented 2 years ago

I tried with Google DNS as follows:

$ dig +short SOA bp.hyddns.xyz @8.8.8.8
www.hyddns.xyz.
$ dig +short SOA hyddns.xyz @8.8.8.8
donald.dnspod.net. freednsadmin.dnspod.com. 1640510300 3600 180 1209600 180

On my machine, a local DNS resolver powered by dnsmasq and dnsproxy is configured as follows:

$ pgrep -af dnsmasq 
621309 /usr/sbin/dnsmasq --port=53 -c10240 --localise-queries --server=127.0.0.1#6053 --conf-dir=/home/werner/Public/anti-gfw/dns/dnsmasq/conf/conf-dir,*.conf -C /home/werner/Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf

$ pgrep -af dnsproxy 
620941 /home/werner/Public/anti-gfw/dns/dnsproxy/dnsproxy.git/dnsproxy --ipv6-disabled --all-servers -u https://dns.adguard.com/dns-query -u tls://8.8.4.4 -u tls://8.8.8.8 -u tls://1.0.0.1 -u tls://1.1.1.1 -u tls://9.9.9.9 -u tls://9.9.9.10 -u tls://149.112.112.10 -l 127.0.0.1 -p 6053
620942 /home/werner/Public/anti-gfw/dns/dnsproxy/dnsproxy.git/dnsproxy --ipv6-disabled --all-servers -u 114.114.114.114:53 -u 114.114.115.115 -u 114.114.114.119 -u 114.114.115.119 -u 114.114.114.110 -u 114.114.115.110 -u 223.5.5.5 -u 223.6.6.6 -u 180.76.76.76 -u 112.124.47.27 -u 114.215.126.16 -l 127.0.0.1 -p 6054

If I run the dig command using the local DNS on port 53, nothing is returned:

$ dig +short SOA bp.hyddns.xyz 
$ dig +short SOA hyddns.xyz 
$

But the querying using non-53 ports do not have the above problem:

$ dig +short SOA hyddns.xyz @127.0.0.1 -p6053
donald.dnspod.net. freednsadmin.dnspod.com. 1640510300 3600 180 1209600 180
$ dig +short SOA hyddns.xyz @127.0.0.1 -p6054
donald.dnspod.net. freednsadmin.dnspod.com. 1640510300 3600 180 1209600 180

Finally, I figured out that the culprit is the following option in my dnsmasq configuration file (Public/anti-gfw/dns/dnsmasq/conf/dnsmasq.conf):

# Uncomment this to filter useless windows-originated DNS requests
# which can trigger dial-on-demand links needlessly.
# Note that (amongst other things) this blocks all SRV requests,
# so don't use it if you use eg Kerberos, SIP, XMMP or Google-talk.
# This option only affects forwarding, SRV records originating for
# dnsmasq (via srv-host= lines) are not suppressed by it.
filterwin2k

Commenting out the above option solved the problem:

$ dig +short SOA bp.hyddns.xyz 
www.hyddns.xyz.
$ dig +short SOA hyddns.xyz 
donald.dnspod.net. freednsadmin.dnspod.com. 1640510300 3600 180 1209600 180

See here for the relevant explanation of this behavior:

This is working as designed. From the manpage [1]:

-f, --filterwin2k
    Later versions of windows make periodic DNS requests which don't get
sensible answers from the public DNS and can cause problems by
triggering dial-on-demand links. This flag turns on an option to filter
such requests. The requests blocked are for records of types SOA and
SRV, and type ANY where the requested name has underscores, to catch
LDAP requests.

If you have an always-online dial-up connection, or any other type of
Internet connection that isn't dial-up, then you don't need to enable
the filterwin2k option.

[1] https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

Regards, HZ

francislavoie commented 2 years ago

Thanks for that detailed explanation! Fascinating. Glad you figured it out!