DNS problem: NXDOMAIN looking up A

Help
1

I cannot renew my Domain anymore due to some DNS error. I suspect it has got something to do with the Unicode-Character but I cannot say exactly. I registered the certificate with the exact same command below and I don’t know what changed. Maybe I upgraded certbot or some DNS-library in the meantime, but I’m not sure. Any hints on what I could do?

Many thanks in advance

Johannes

My domain is:

staging.prüfungs.tv

I ran this command:

certbot certonly --webroot --webroot-path /home/joe/web/staging-pruefungstv/public --renew-by-default --agree-tos -d staging.xn--prfungs-o2a.tv

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for staging.prüfungs.tv
Using the webroot path /home/joe/web/staging-pruefungstv/public for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. staging.prüfungs.tv (http-01): urn:ietf:params:acme:error:dns :: Fetching https://staging.pr\xfcfungs.tv/.well-known/acme-challenge/oH4V71dK0fgMm4n7T5EYw2WkrD0t_BGONc7t7xfADw8: DNS problem: NXDOMAIN looking up A for staging.pr\xfcfungs.tv - check that a DNS record exists for this domain

IMPORTANT NOTES:

My web server is (include version):

Apache 2.4.38-3+deb10u3

The operating system my web server runs on is (include version):

Debian Buster 10.4

My hosting provider, if applicable, is:

Hosteurope

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):

No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

certbot 0.31.0

2

There is a non-standard character in that name:
ü
And the – in the long name may be confusing cerbot.
Try it with single quotes around the long name:

certbot certonly --webroot --webroot-path /home/joe/web/staging-pruefungstv/public --renew-by-default --agree-tos -d 'staging.xn--prfungs-o2a.tv'
3

That’s not it. As you can see from the output, certbot correctly identifies the long name then even correctly translates it to the unicode version and tries to download the challenge. It is then when some DNS request fails. And as I said, the certificate was correctly issued before with the exact same command.

4

No I don't see that:

5

I believe your web server is directly returning the UTF-8 version.

E.g. a request for http://staging.xn--prfungs-o2a.tv/ returns this Location header:

Location: https://staging.prüfungs.tv/

I believe that’s invalid; it should probably use the punycode version. Maybe % encoded UTF-8 would work; I’d have to read RFC 3986 again.

1 Like
6

And was it issued using that exact same version of certbot?:

I would TRY it with the single quotes and may be even use a \ in from of each -

certbot certonly --webroot --webroot-path /home/joe/web/staging-pruefungstv/public --renew-by-default --agree-tos -d 'staging.xn\-\-prfungs-o2a.tv'

Just to be 100% certain that is NOT part of the problem.

FYI certbot doesn't treat the double dash as a human would.

7

I used the punycode version with success. Thanks a lot!

8

As I said, maybe there was an update in between.

Yes it does. It just especially recognizes command line options where a double dash is at the beginning of an argument.

You can see from your quote that certbot correctly translates xn--prfungs-o2a to prüfungs (\xfc in Unicode is ü: Unicode Hex Character Code ü)

9

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