Huaweicloud DNS subdomain

We try certbot, certmanager y finaly
getssl ver. 2.27

always same issue, no resolution from let’s encrypt server, this is for political reasons ?
from internet, same machines, etc works great, but i can’t get let’s encrypt certificates …

sleep 5 secs before testing verify again
checking if challenge is complete

url https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/57601405/Y5MSRQ

using KID=https://acme-staging-v02.api.letsencrypt.org/acme/acct/13693202

payload =

responseHeaders HTTP/1.1 100 Continue

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 18 May 2020 18:48:52 GMT
Content-Type: application/json
Content-Length: 398
Connection: keep-alive
Boulder-Requester: 13693202
Cache-Control: public, max-age=0, no-cache
Link: https://acme-staging-v02.api.letsencrypt.org/directory;rel=“index”
Link: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/57601405;rel=“up”
Location: https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/57601405/Y5MSRQ
Replay-Nonce: 0001QMNsDrBQcVDswwMOlUWRScPD0AEgO5BPrcn6g3s1Cig
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

response {
“type”: “http-01”,
“status”: “invalid”,
“error”: {
“type”: “urn:ietf:params:acme:error:dns”,
“detail”: “DNS problem: SERVFAIL looking up A for pvtdev.sed.srcei.cl - the domain’s nameservers may be malfunctioning”,
“status”: 400
},
“url”: “https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/57601405/Y5MSRQ”,
“token”: “FNzsT2do6_iSws1xjfv8wYqBaRfbLZl10e6bsdaxpII”
}

code 200

response status = invalid
getssl: pvtdev.sed.srcei.cl:Verify error: “detail”: “DNS problem: SERVFAIL looking up A for pvtdev.sed.srcei.cl - the domain’s nameservers may be malfunctioning”,

1 Like
1 Like

Hi @siccl

your name servers are buggy - critical buggy - https://check-your-website.server-daten.de/?q=pvtdev.sed.srcei.cl

X Fatal error: Nameserver doesn't support TCP connection: secundario.nic.cl / 200.7.5.7: Refused
X Fatal error: Nameserver doesn't support TCP connection: secundario.nic.cl / 2001:1398:276:0:200:7:5:7: Refused
X Fatal error: Nameserver doesn't support echo capitalization: ns1.huaweicloud-dns.cn / 122.112.208.53
X Fatal error: Nameserver doesn't support echo capitalization: ns1.huaweicloud-dns.cn / 139.159.208.46
X Fatal error: Nameserver doesn't support echo capitalization: ns1.huaweicloud-dns.cn / 49.4.112.16
X Fatal error: Nameserver doesn't support echo capitalization: ns1.huaweicloud-dns.cn / 2407:c080:0:ffff:ffff:fffe:0:1
X Fatal error: Nameserver doesn't support echo capitalization: ns1.huaweicloud-dns.com / 139.159.208.43
X Fatal error: Nameserver doesn't support echo capitalization: ns1.huaweicloud-dns.com / 139.9.224.17
X Fatal error: Nameserver doesn't support echo capitalization: ns1.huaweicloud-dns.net / 159.138.112.21
X Fatal error: Nameserver doesn't support echo capitalization: ns1.huaweicloud-dns.net / 159.138.76.159
X Fatal error: Nameserver doesn't support echo capitalization: ns1.huaweicloud-dns.org / 159.138.17.59
X Fatal error: Nameserver doesn't support echo capitalization: ns1.huaweicloud-dns.org / 159.138.77.159

Authoritative name servers must support TCP connections. Letsencrypt checks, if a query AbC.com has an answer with AbC.com (good) or abc.com (wrong).

If that doesn't work, it's a Servfail.

Rechecked with Unboundtest, the same - https://unboundtest.com/m/A/pvtdev.sed.srcei.cl/PDFSVCVY

May 18 18:58:04 unbound[21072:0] info: wrong 0x20-ID in reply qname
May 18 18:58:04 unbound[21072:0] info: from server 139.9.224.17 port 53

Result:

pvtdev.sed.srcei.cl. A IN SERVFAIL

Letsencrypt uses an Unbound instance with the same configuration as unboundtest.

2 Likes

Hi @JuergenAuer

I have found this topic very interesting, however if possible I would like to know which RFCs talk about the need to support Echo Capitalized, if I’m not mistaken the RFC 4343 mentions that it is case insensitive. Nevertheless I think that name servers should support this, however we know that two domains with the same name cannot exist be it with uppercase or lowercase differences so what would be the security advantange to support Echo Capitalized? For domain resolution there seems to be no problem at all.

As I said, I would like to know more and if you have any documentation or the time (and patience) to elaborate further that would be awesome.

Thank you!

EDIT: In the siccl’s case, the error:

Domain: pvtdev.sed.srcei.cl Type: dns Detail: DNS problem: SERVFAIL looking up CAA for pvtdev.sed.srcei.cl - the domain’s nameservers may be malfunctioning**

Is about Echo Capitalized alone?

1 Like

There is a draft, created 2008:

5.2. It is strongly urged that the DNS specification be amended to require that the question section from the request MUST be copied, exactly, bit for bit, into the question section of the response. The DNS specification is silent on the matter of altering 0x20 bits in the question name when copying it from the request to the response, so, this change is "within the spirit."

So Name Servers should do that. Resolvers can use it to check, if the answer isn't changed.

It's an additional step to check, if the answer is correct / not spoofed etc.

Letsencrypt uses an Unbound instance with the same config like unboundtest. So if unboundtest fails because of the echo capitalization, Letsencrypt will fail too.

2 Likes

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