Looking up authoritative nameservers: could not determine authoritative nameservers

I was commenting here:

Regarding this issue:

looking up authoritative nameservers: could not determine authoritative nameservers

And @matt sent me here:

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

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
        }

Sorry but I can’t see the difference between your proposed caddyfile and mine

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"
        }
}

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.