The provider hands zone and Record.Name to the API verbatim. For an IDN zone that means Unicode is sent where the API, DNS itself and Let's Encrypt all want A-labels, and the failure that follows is hard to trace back to its cause.
Low priority for the Caddy path: CertMagic derives the zone from a DNS query (FindZoneByFQDN), so by the time AppendRecords is called it is already an A-label. It is direct libdns users who would hit this — someone who passes 你好.example.com. straight in.
Two ways out, and I do not have a strong opinion yet:
- Normalise at the boundary with
golang.org/x/net/idna. This is what the sibling JavaScript implementation of the same API does (url.domainToASCII on both host and zone, once, before anything else). It costs a second dependency in a package that currently has exactly one.
- Reject non-ASCII input with a message naming the punycode form. No new dependency, and the caller learns what to do, but it is a refusal where the other implementation quietly copes.
Noting it now so it is not rediscovered later.
The provider hands
zoneandRecord.Nameto the API verbatim. For an IDN zone that means Unicode is sent where the API, DNS itself and Let's Encrypt all want A-labels, and the failure that follows is hard to trace back to its cause.Low priority for the Caddy path: CertMagic derives the zone from a DNS query (
FindZoneByFQDN), so by the timeAppendRecordsis called it is already an A-label. It is direct libdns users who would hit this — someone who passes你好.example.com.straight in.Two ways out, and I do not have a strong opinion yet:
golang.org/x/net/idna. This is what the sibling JavaScript implementation of the same API does (url.domainToASCIIon both host and zone, once, before anything else). It costs a second dependency in a package that currently has exactly one.Noting it now so it is not rediscovered later.