Louen
(Louen)
February 1, 2025, 10:55am
1
I was commenting here:
opened 12:57PM - 13 Dec 24 UTC
@dennismuench
Coming from here:
https://github.com/caddy-dns/bunny/issues/2…
[I've sorted the empty DNS zone](https://github.com/SirLouen/libdns-bunny/commit/4d2a2447442d46a15d1b57155b2e4b011d28889c) and now I can better see where the issue is coming
```json
{
"level":"error",
"ts":1734093679.7992978,
"logger":"tls.obtain",
"msg":"could not get certificate from issuer",
"identifier":"*.mysite.com",
"issuer":"acme-v02.api.letsencrypt.org-directory",
"error":"[*.mysite.com] solving challenges: presenting for challenge: adding temporary record for zone \"_acme-challenge.mysite.com.\": zone not found: _acme-challenge.mysite.com (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/158696983/21239318474) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"
}
{
"level":"error",
"ts":1734093679.7995076,
"logger":"tls.obtain",
"msg":"will retry",
"error":"[*.mysite.com] Obtain: [*.mysite.com] solving challenges: presenting for challenge: adding temporary record for zone \"_acme-challenge.mysite.com.\": zone not found: _acme-challenge.mysite.com (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/158696983/21239318474) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)",
"attempt":2,
"retrying_in":120,
"elapsed":62.522038877,
"max_duration":2592000
}
{
"level":"info",
"ts":1734093681.371488,
"logger":"tls.obtain",
"msg":"obtaining certificate",
"identifier":"mysite.com"
}
{
"level":"info",
"ts":1734093681.3735995,
"logger":"tls",
"msg":"using ACME account",
"account_id":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/158696983",
"account_contact":[
]
}
{
"level":"info",
"ts":1734093682.2132306,
"logger":"tls.acme_client",
"msg":"trying to solve challenge",
"identifier":"mysite.com",
"challenge_type":"http-01",
"ca":"https://acme-staging-v02.api.letsencrypt.org/directory"
}
```
It appears that it cannot create the `_acme-challenge`. I wonder if something has changed in the Bunny DNS API. I think that this belongs to libdns-bunny.
Regarding this issue:
looking up authoritative nameservers: could not determine authoritative nameservers
And @matt sent me here:
for _, rr := range r.Answer {
if ns, ok := rr.(*dns.NS); ok {
authoritativeNss = append(authoritativeNss, strings.ToLower(ns.Ns))
}
}
if len(authoritativeNss) > 0 {
return authoritativeNss, nil
}
return nil, errors.New("could not determine authoritative nameservers")
}
// Update FQDN with CNAME if any
func updateDomainWithCName(r *dns.Msg, fqdn string) string {
for _, rr := range r.Answer {
if cn, ok := rr.(*dns.CNAME); ok {
if cn.Hdr.Name == fqdn {
return cn.Target
}
}
I’ve been reviewing the code
Even if the zone is found, the code requires at least one valid NS record in the DNS response (len(authoritativeNss) > 0
).
> host -t SOA wabisabi.com.es
wabisabi.com.es has SOA record kiki.bunny.net. hostmaster.bunny.net. 2020032201 7200 900 1209600 86400
> dig NS wabisabi.com.es @8.8.8.8 +trace
wabisabi.com.es. 86400 IN NS kiki.bunny.net.
wabisabi.com.es. 86400 IN NS coco.bunny.net.
I can’t really understand what “could not determine authoritative nameservers” means and I’m trying to get a grasp from it. I sorted it by using the resolvers
directive, but what disturbs me, is that, in this given configuration, I was using SWAG (Nginx) in the same machine (a different docker container) and it was not returning the equivalent error message.
Wondering why there are no NS in the answer. Does anyone know how can I dig further into this scenario?
PS: If anyone wants to know the exact setup here is the step-by-step guide on how I did configure my caddy server
opened 12:57PM - 13 Dec 24 UTC
@dennismuench
Coming from here:
https://github.com/caddy-dns/bunny/issues/2…
[I've sorted the empty DNS zone](https://github.com/SirLouen/libdns-bunny/commit/4d2a2447442d46a15d1b57155b2e4b011d28889c) and now I can better see where the issue is coming
```json
{
"level":"error",
"ts":1734093679.7992978,
"logger":"tls.obtain",
"msg":"could not get certificate from issuer",
"identifier":"*.mysite.com",
"issuer":"acme-v02.api.letsencrypt.org-directory",
"error":"[*.mysite.com] solving challenges: presenting for challenge: adding temporary record for zone \"_acme-challenge.mysite.com.\": zone not found: _acme-challenge.mysite.com (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/158696983/21239318474) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)"
}
{
"level":"error",
"ts":1734093679.7995076,
"logger":"tls.obtain",
"msg":"will retry",
"error":"[*.mysite.com] Obtain: [*.mysite.com] solving challenges: presenting for challenge: adding temporary record for zone \"_acme-challenge.mysite.com.\": zone not found: _acme-challenge.mysite.com (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/158696983/21239318474) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)",
"attempt":2,
"retrying_in":120,
"elapsed":62.522038877,
"max_duration":2592000
}
{
"level":"info",
"ts":1734093681.371488,
"logger":"tls.obtain",
"msg":"obtaining certificate",
"identifier":"mysite.com"
}
{
"level":"info",
"ts":1734093681.3735995,
"logger":"tls",
"msg":"using ACME account",
"account_id":"https://acme-staging-v02.api.letsencrypt.org/acme/acct/158696983",
"account_contact":[
]
}
{
"level":"info",
"ts":1734093682.2132306,
"logger":"tls.acme_client",
"msg":"trying to solve challenge",
"identifier":"mysite.com",
"challenge_type":"http-01",
"ca":"https://acme-staging-v02.api.letsencrypt.org/directory"
}
```
It appears that it cannot create the `_acme-challenge`. I wonder if something has changed in the Bunny DNS API. I think that this belongs to libdns-bunny.
TheRettom
(Riley M)
February 4, 2025, 9:48pm
2
I’m not an expert here, but because nobody responded, I want to try to help.
I dealt with a similar problem with nameserver resolution when I started my domain. I believe the problem was, with your current configuration, LetsEncrypt is trying to generate a certificate for the wildcard domain, but it needs to first ensure you own the base domain. I believe this is because your TLS field is formatted incorrectly. I’d change your Caddyfile to reflect the following:
{
debug
}
*.wabisabi.com.es {
root * /srv/site
encode gzip zstd
file_server
php_fastcgi unix//run/php/php-fpm-site.sock {
root /var/www/html
}
respond /health-check 200 {
body "Lets go"
}
tls {
issuer acme {
dns bunny READACTED_API_KEY
dir https://acme-staging-v02.api.letsencrypt.org/directory
}
}
}
And honestly, I don’t think you need some of those directives for tls. I believe you could get away with:
tls {
dns bunny READACTED_API_KEY
}
Louen
(Louen)
February 4, 2025, 10:03pm
3
Sorry but I can’t see the difference between your proposed caddyfile and mine
TheRettom
(Riley M)
February 4, 2025, 11:57pm
4
The difference is you have TLS outside the site block, when it should be inside the site block. By your post 5 days ago, this is your Caddyfile:
{
debug
}
(tls) {
tls {
issuer acme {
dns bunny READACTED_API_KEY
dir https://acme-staging-v02.api.letsencrypt.org/directory
}
}
}
*.wabisabi.com.es {
root * /srv/site
encode gzip zstd
file_server
php_fastcgi unix//run/php/php-fpm-site.sock {
root /var/www/html
}
respond /health-check 200 {
body "Lets go"
}
import tls
}
I’m saying to move the TLS directive to the inside of the site block:
{
debug
}
*.wabisabi.com.es {
tls {
issuer acme {
dns bunny READACTED_API_KEY
dir https://acme-staging-v02.api.letsencrypt.org/directory
}
}
root * /srv/site
encode gzip zstd
file_server
php_fastcgi unix//run/php/php-fpm-site.sock {
root /var/www/html
}
respond /health-check 200 {
body "Lets go"
}
}
Louen
(Louen)
February 5, 2025, 12:24am
5
That cannot be. What I had was simply an import pattern.
And my TLS directive was built like that theorically to use the staging server instead of the regular one (because I was doing a lot of tests and exhausting the LE quota)
So technically any of these mods should not be the cause of the nameserver thing.