Letsencrypt uses very old dns data

[swigger]

here is the log

IMPORTANT NOTES:

• The following errors were reported by the server:

Domain: www.swigger.net
Type: connection
Detail: Failed to connect to 104.217.129.58:443 for TLS-SNI-01
challenge

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.

and this shows the correct ip address

$ nslookup www.swigger.net 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
www.swigger.net canonical name = swigger.net.
Name: swigger.net
Address: 160.16.67.159

le uses a very old ip address 104.217.129.58 which I changed at lease one month ago.

Please help to correct that.

[Osiris]

That’s odd… Because the DNS client of Boulder doesn’t cache results, nor does it query DNS servers which do. It follows the whole path from root down…

I’m getting the same IP from certbot indeed, although my error doesn’t relay the IP address (I’m getting it from the verbose log), which is a non-related bug I think

[swigger]

where is the root problem and what should I do?

[Osiris]

Beats me, I think it’s quite strange. Perhaps a developer from Let’s Encrypt/Boulder can comment? @cpu perhaps?

[pfg]

Let’s Encrypt’s DNS server uses dns-0x20 to add entropy to DNS queries (making it harder to spoof responses). Practically speaking, that means a DNS server uses randomized casing for queries - www.swigger.net might become WwW.SwIgGeR.NeT. Using this casing when querying your name servers, I do indeed get 104.217.129.58 as a response:

dig @apple.ns1.anquanbao.com WwW.SwIgGeR.NeT A

; <<>> DiG 9.8.3-P1 <<>> @apple.ns1.anquanbao.com WwW.SwIgGeR.NeT A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4761
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;WwW.SwIgGeR.NeT.		IN	A

;; ANSWER SECTION:
www.swigger.net.	3600	IN	CNAME	swigger.net.
swigger.net.		3600	IN	A	104.217.129.58

;; Query time: 352 msec
;; SERVER: 121.14.157.13#53(121.14.157.13)
;; WHEN: Sat Dec 17 11:00:47 2016
;; MSG SIZE  rcvd: 111

Not entirely sure what sort of weirdness would cause it to serve a different IP based on this (rather than an empty response) - maybe some cache that hasn’t been purged in months? - but that seems to be it.

[TCM]

Yeah, as soon as you capitalize a single letter in the FQDN, it answers with 104.217.129.58.

Go complain to whoever provides that DNS and tell them to fix their horribly broken service.

[swigger]

thank you all. I’ll ask my dns provider to solve this issue.

[cpu]

Thanks for diagnosing this one @pfg - you rock!