Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using of IDN (punycode) Domains #37

Open
aschulz01 opened this issue Nov 21, 2024 · 6 comments
Open

using of IDN (punycode) Domains #37

aschulz01 opened this issue Nov 21, 2024 · 6 comments

Comments

@aschulz01
Copy link
Contributor

aschulz01 commented Nov 21, 2024

Hello, currently I try to create an certificate for multiple domains
sample: certbot certonly -v -a dns-inwx -d ".xn--bung-zra.de" -d "xn--bung-zra.de" -d ".uebung.de" -d "uebung.de" --agree-tos

(to cover the german umlaut-domains *.übung.de, übung.de, *.uebung.de, uebung.de)
the domainname in this issue is changed, the real domainname exists at inwx.de and the idn notation matches the field
"Domain ACE" inside the content of https://www.inwx.de/de/domain/info/"übung.de"

unfortunately this error occurred:
Starting new HTTPS connection (1): api.domrobot.com:443
https://api.domrobot.com:443 "POST /xmlrpc/ HTTP/1.1" 200 None
Testing xn--bung-zra.de for domain _acme-challenge.xn--bung-zra.de...
Resetting dropped connection: api.domrobot.com
https://api.domrobot.com:443 "POST /xmlrpc/ HTTP/1.1" 200 None
Testing _acme-challenge.xn--bung-zra.de for domain _acme-challenge.xn--bung-zra.de...
Resetting dropped connection: api.domrobot.com
https://api.domrobot.com:443 "POST /xmlrpc/ HTTP/1.1" 200 None
Encountered exception:

Traceback (most recent call last):
File "/snap/certbot-dns-inwx/current/lib/python3.12/site-packages/certbot_dns_inwx/_internal/dns_inwx.py", line 157, in add_txt_record
domain = self._find_domain(record_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/snap/certbot-dns-inwx/current/lib/python3.12/site-packages/certbot_dns_inwx/_internal/dns_inwx.py", line 234, in _find_domain
raise errors.PluginError(
certbot.errors.PluginError: Unable to determine base domain for _acme-challenge.xn--bung-zra.de using names: ['_acme-challenge.xn--bung-zra.de', 'xn--bung-zra.de']

If I try call certbot with the unicode domainnames (übung.de, ...) then certbot advised me to use the ace domain format (idn /punycode)

@aschulz01
Copy link
Contributor Author

aschulz01 commented Nov 21, 2024

I found, that the DomRobot API "nameserver.list" should allow a punicode input. "nameserver.createRecord" and "nameserver.info" already allow this. The result from nameserver list must also punicode if the input was punicode. Then the authentication against certbot should work and the DomRobot Api should keep stable.

@aschulz01
Copy link
Contributor Author

I asked the inwx support to fix the domrobot API function "nameserver.list".

@aschulz01
Copy link
Contributor Author

answer from inwx:

vielen Dank für den Hinweis. Die Problematik ist bereits bei meinen Kollegen bekannt und wird vermutlich im Sprint des kommenden Jahres mit umgesetzt werden.
Bis dahin müssen Sie sich leider noch etwas gedulden.

@oGGy990
Copy link
Owner

oGGy990 commented Nov 26, 2024

Hi @aschulz01 ,

so, does the API function provide the domains using the unicode representation? If so, we could implement a workaround to convert the domain names for the respective interfaces.

I do not have access to an IDN and I am uncertain whether I could fake one on INWX' OTE test system, unfortunately.

@aschulz01
Copy link
Contributor Author

aschulz01 commented Nov 26, 2024

Hi oGGy990,

the answer from inwx is not specific.
This is the google translate output while translating the answer above:
"Thank you very much for the tip. The problem is already known to my colleagues and will probably be implemented in the sprint next year. Unfortunately, you'll have to be patient until then."

And these are the results of my investigation:
The current API calls "nameserver.createRecord" and "nameserver.info" does provide the idn syntax. I have tested this.
The current call "nameserver list" does not provide the idn syntax. the return list is empty if a idn string is passed. If the search pattern is unicode, then the matching domain list is returned. I have tested this as well.

In order to implement a workaround, the search input domain pattern of "nameserver list" would have to be transformed from idn to unicode and the domain name in the output list of the call would have to be transformed from unicode to idn.
input pattern: ("xn--bung-zra.de" -> "übung.de")
output list: ("übung.de" -> "xn--bung-zra.de")

best regards
Andreas

@oGGy990
Copy link
Owner

oGGy990 commented Nov 26, 2024

Thanks for the translation, Andreas. But I'm german as well, so there's no need for it. ;-)

I've implemented a simple workaround on the branch feature/idna-workaround. Is it possible for you to give this one a try? It requires the idna package to be optionally installed in order to do the de-/encoding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

2 participants