Pages Let's Encrypt cert failing - perhaps due to IDN domain name?

TL;DR; I suspect a custom IDN domain might be at fault - сяурт.com. Are IDN domain supported?


can you share the DNS settings in a screenshot? (redact the verification challenge value)

When I try querying the domain, I get a SERVFAIL error which could mean that the DNS entries are wrong, or the zone is not served correctly by the nameservers.

$ dig ns	10800	IN	NS	10800	IN	NS	10800	IN	NS

returns the nameservers but querying for an A record fails.


Hi Michael,

Aha, my dig is quite different:

$ dig

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61923
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

; EDNS: version: 0, flags:; udp: 4096
;сяурт.com.                     IN      A

сяурт.com.              300     IN      A

сяурт.com.              172800  IN      NS
сяурт.com.              172800  IN      NS
сяурт.com.              172800  IN      NS

;; ADDITIONAL SECTION:      600     IN      A      600     IN      AAAA    2604:3400:aaac::5c     80748   IN      A     16949   IN      AAAA    2001:4b98:aaab::ef     42846   IN      A     42846   IN      AAAA    2001:4b98:aaaa::fd

;; Query time: 119 msec
;; WHEN: Sat Oct 09 08:39:11 CEST 2021
;; MSG SIZE  rcvd: 270

My DNS zone:

@ 86400 IN SOA 1633633740 10800 3600 604800 10800
@ 10800 IN ALIAS
@ 10800 IN MX 10
@ 10800 IN MX 50
@ 10800 IN TXT "v=spf1 a mx -all"
_2eef56abcc223ea4199c7e195e0ca70a 10800 IN CNAME
_gitlab-pages-verification-code 10800 IN TXT "gitlab-pages-verification-code=6b7c0c7eadbc6d2776a974e9d7b665d5"
_imap._tcp 10800 IN SRV 0 0 0   .
_imaps._tcp 10800 IN SRV 0 1 993
_pop3._tcp 10800 IN SRV 0 0 0   .
_pop3s._tcp 10800 IN SRV 10 1 995
_submission._tcp 10800 IN SRV 0 1 465
gm1._domainkey 10800 IN CNAME
gm2._domainkey 10800 IN CNAME
gm3._domainkey 10800 IN CNAME
webmail 10800 IN CNAME

The ALIAS is handled by the name servers to produce an A record tracking the GitLab pages IP.

Not sure why is my detailed answer still on hold… @dnsmichi the DNS details are held as SPAM.

I’ve noticed while in a train that their name servers did not serve the records there. Could it be that your NS does not support IDN?

dig @ doesn’t show. My home router doesn’t show either.

My office NS does show the detail and so does Network Tools: DNS,IP,Email so it could be incompatibility or I’m getting suspicious of some form of blacklisting/censoring. It is weird.


Discourse uses Akismet to determine potential spam. Maybe your source IP address is known for abusive behaviour (tor or VPN exit nodes, public facing servers, etc.). That’s something which gets into the moderation queue, which I have now approved for this post.

I’m not sure about the implementation state of IDN. For German umlauts, I remember this being added to .at domains in 2011 though being a challenge. Yet it seems that each ccTLD and gTLD implements that differently, and recursive resolvers do weird things as well.

I don’t know which resolver is used on SaaS and Pages, as I am not on the infrastructure team. Since it runs in Google Cloud, something similar to the Google public resolver I guess.

It might be worthwhile to ask Gandi support if they know about IDN problems with public resolvers. Or, how to troubleshoot them.