How does `tls resolvers` work exactly?

Hi there!

Assume caddy is running on a private network host that does not yet have any associated A or CNAME records and has its /etc/hosts as follows:

127.0.0.1       localhost
10.1.1.14       test.mydomain.com

Given the following example Caddyfile snippet:

test.mydomain.com {

    tls {
        dns cloudflare {env.CF_API_TOKEN}
        resolvers 1.1.1.1
    }

    # ... etc...
}

What does the resolvers 1.1.1.1 line do exactly?

Naturally I checked the documentation which says:

  • resolvers customizes the DNS resolvers used when performing the DNS challenge; these take precedence over system resolvers or any default ones. If set here, the resolvers will propagate to all configured certificate issuers.This is typically a list of IP addresses.

So it seems clear enough to me that this allows caddy and/or its cloudflare dns plugin to find Cloudflare’s API server so it can add the acme challenge TXT record to the mydomain.com domain.

But is 1.1.1.1 used for anything else?

Does caddy and/or its clouflare plugin use it to find the ip address for test.mydomain.com?

If so, that would be a problem because hostname-to-ip resolution is currently only represented in the caddy host’s /etc/hosts file and not yet in any dns server.

My understanding is that the acme exchange should still ‘just work’ and doesn’t need to know about the machine’s hostname or IP address. It is basically “I own mydomain.com, so I’ll add a TXT record to prove it, and after you verify that record, please issue me the cert.” No?

It overrides the system DNS configuration for TLS related operations. Sometimes the system resolver can be slow, split horizon, misconfigured, or return stale results.

Specifying a resolver lets Caddy bypass that and query something reliable, or query the authoritative DNS for the zone you want the certificate for directly. This does not affect how Caddy resolves other stuff, for example, upstream names.

Thanks for the reply!

That makes sense for outbound caddy-to-dnsprovider or caddy-to-letsencrypt requests during the DNS challenge.

But I’m also trying to learn:

Will there be a problem if caddy is an https reverse proxy for test.mydomain.com and that domain is not resolvable in any dns server and only via /etc/hosts?

You can use tls internal pretty much for any site name you like. If you want to do DNS-01 challenge, you don’t necessarily need an A record with IP address, but the zone (its authoritative DNS server) needs to be accessible by the issuer. Otherwise, I’m not sure how else the issuer would validate the challenge.

I’m not using tls internal - just the above test.mydomain.com example.

But if I understand you correctly, it sounds like the authoritative DNS (e.g. Cloudflare for mydomain.com) doesn’t need to have an A record at all for test.mydomain.com - it just needs to have the TXT record that the issuer will look for (e.g. _acme-challenge.test).

I just wanted to ensure that resolvers in the above example is only used to communicate with 1) the authoritative DNS server (e.g. Cloudflare) to create the TXT record and perhaps 2) the issuer (e.g. Let’s Encrypt), telling it to check for the TXT record.

This is important, for example, if the caddy host is in a network with a private (forwarding) DNS server without an A record for test.mydomain.com (or has an error/misconfiguration/etc), caddy’s DNS challenge flow should still work because of the explicit external resolvers.

Thanks for confirming!

Correct.

Only 1, it’s for Caddy’s use, it’s not communicated to the issuer. It’s for Caddy checking “I tried to write the TXT record, did it actually tho?” (aka the propagation check) because DNS plugins can misbehave or be slow to actually have the records appear in DNS after using whatever DNS provider’s API (Cloudflare is fast, so non-issue in that case). Once Caddy sees the TXT record, it can move on to tell the issuer “ok it should be there now, go look to confirm the challenge response!”

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.