Hello, The single domain and wildcard is working fine, but i have add www and toplevel both, It’s got NXDOMAIN！NXDOMAIN！NXDOMAIN！
but my domain DNS is fine, dig have correct record both www and toplevel
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:utb.host
It produced this output:Let’s Encrypt Verify error! DNS problem: NXDOMAIN looking up A for utb.host
My web server is (include version):openresty/1.13.6.1
The operating system my web server runs on is (include version):CentOS 7.4
My hosting provider, if applicable, is:RAKSmart
I can login to a root shell on my machine (yes or no, or I don’t know):yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):Oneinstack beta
That error message seems to come from OneinStack itself, though it’s almost the same as a real Let’s Encrypt error message.
It’s doing some sort of self-test, which is failing for some reason, which may or may not actually be an NXDOMAIN.
It’s hard to say why OneinStack is failing to download a file from your server, or whether Let’s Encrypt would be able to validate the name, if the client were to ask it to.
Self-testing isn’t really necessary anyway, and it’s possible for it to fail when a validation request from Let’s Encrypt would succeed. (Sometimes servers can have trouble accessing themselves when outside clients are experiencing no trouble at all.)
Can you modify OneinStack to log the error from curl, or rip out the self-test entirely? Or check the web server’s error logs and configuration to see what might have happened?
Edit: The DNSKEY thing is a bug with the domain’s DNS servers, but it won’t cause resolution to fail. The domain doesn’t use DNSSEC, so clients won’t ask for the DNSKEY records, so the invalid (non-) response won’t stop them.
