SERVFAIL looking up A for build.ascend4.org

[jdpipe]

Hi there

I seem to have a DNS issue which is preventing me from getting a certificate.

The issues seems to be that although I have an “A” record, I do not have a “DS” record, and that seems to be leading to a conclusion that my domain is “insecure”, eg as listed here http://dnsviz.net/d/ascend4.org/dnssec/ and here http://dnssec-debugger.verisignlabs.com/ascend4.org/.

Can anyone please give me some clues about what I would need to do to get a DS record? It doesn’t seem to be something that my DNS provider offers.

Cheers
JP

[mnordhoff]

The DS record and “insecure” stuff isn’t important. It just means the domain isn’t using DNSSEC. Enabling DNSSEC is good (according to some) but it’s not, like, necessary.

This is strange. I don’t see anything wrong with the DNS setup, but it’s just not working for Let’s Encrypt. Maybe there’s a regional Internet issue between Let’s Encrypt and the DNS provider. Maybe it’s something obvious i’ve missed!

Note:

I tried to issue staging certificates for build.ascend4.org, ns1.easyclouddns.net (one of its nameservers), and ns1.netregistry.net (one of easyclouddns.net's nameservers). They all failed with DNS timed out or SERVFAIL.

(If that’s against the subscriber agreement… you didn’t read this post.)

Either something’s up with the DNS provider, or something’s up with the resolvers. It’s not specific to ascend4.org.

Edit: And from my position on the Internet, all the nameservers are located in Fremont, California. (They probably use anycast.) Not especially redundant, but not northern China either.

[jdpipe]

Thanks for the forensics…

This domain is (currently) colocated with http://dnssec-debugger.verisignlabs.com/stg-06.anu.edu.au. Could that somehow cause the problem? The two domains are using different DNS servers, even though the IP address is the same. Could that be the problem?

[mnordhoff]

Nah, that shouldn't be a problem.

Wait a minute... There was a thread about Netregistry issues a while ago:

DNS resolver issues?

I…

@jsha Do you remember what became of that? Netregistry DNS issues a year ago?

[jsha]

A note, since it’s not explicitly stated earlier in the thread: The nameservers for ascend4.org are ns[123].easyclouddns.net. To find out the IP address for one of those nameservers, it’s necessary to contact the easyclouddns’ nameservers. All my queries for dig ns easyclouddns.net timeout, so it’s not possible to directly find out the names of easyclouddns’ nameservers. However, whois reveals that easyclouddns is registered with NetRegistry, so I’m assuming their nameservers are ns[123].netregistry.net.

It does look like NetRegistry is having a rather bad outage at the moment: https://twitter.com/netregistry/status/852317642903834625. That’s probably the cause of all these timeouts. I’m afraid the best advice I can offer you at the moment is to change your nameservers away from easyclouddns.net, at least for now.

[mnordhoff]

That’s the case now but i could “dig ns easyclouddns.net” yesterday.

Actually, i can right now too. Maybe it’s recovering since you posted.

Edit: And yes, you’re right.

easyclouddns.net.       3525    IN      NS      ns1.netregistry.net.
easyclouddns.net.       3525    IN      NS      ns2.netregistry.net.
easyclouddns.net.       3525    IN      NS      ns3.netregistry.net.

[jsha]

Hm, that scuttles that theory. And I can indeed successfully look up the domain using an unbound instance configured like prod. It’s possible there were intermittent issues leading up to the total outage?

@jdpipe, how many times did the problem occur previously? Does it still occur now? Against both prod and staging?

[jdpipe]

Hi @jsha, I have only tried with ‘certbot-auto’, following the (previous) instructions for Ubuntu 14.04.5. I have seen that this script updates itself automatically. ‘certbot-auto --version’ reports ‘certbot 0.13.0’. I have no problems running this script with other domains, but it has consistently failed either with ‘SERVFAIL’ as occurred briefly recently during a DNS server outage, or with ‘DNS problem: query timed out looking up A for ascend4.org’ as currently, and all other times.

I’m not aware of how to run the ‘staging’ version of certbot, if you could point me at some instructions, that would be great.

[mnordhoff]

@jdpipe

I'm not aware of how to run the 'staging' version of certbot, if you could point me at some instructions, that would be great.

You use the same software; it connects to a different API server, which issues certificates from a fake CA that isn't trusted by browsers.

Use the same Certbot command as normal, but add "--staging" or "--test-cert". (Both options are equivalent.)

[jdpipe]

OK, so I tried

~john/certbot-auto --dry-run certonly --test-cert

and the result was the same, DNS problem: query timed out looking up A for ascend4.org.

Any further suggestions?

BTW I had another look at the DNSSEC analyser link above. I received “NSEC3 proving non-existence of ascend4.org/DS”, which I don’t remember seeing before. Is there any chance that that could be affecting what certbot-auto reports?

[sahsanu]

Hi @jdpipe,

I don’t know the reason you are getting the query timed out looking up A for ascend4.org, I can resolve your A record without issues from different countries, what is strange is that every DNS record that your DNS servers don’t recognize, they don’t answer anything, the query just time out.

For example:

1.- Quering records not recognized by your DNS servers.

Quering CAA (TYPE257) record:

$ dig @ns1.easyclouddns.net ascENd4.org +norecurse +dnssec -t TYPE257 +short

; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> @ns1.easyclouddns.net ascENd4.org +norecurse +dnssec -t TYPE257 +short
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Quering TLSA (TYPE52) record:

$ dig @ns1.easyclouddns.net ascENd4.org +norecurse +dnssec -t TYPE52 +short

; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> @ns1.easyclouddns.net ascENd4.org +norecurse +dnssec -t TYPE52 +short
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

2.- Now quering some record not defined for your domain but recognized by your DNS Servers:

Quering NAPTR (TYPE35) record:

$ dig @ns1.easyclouddns.net ascENd4.org +norecurse +dnssec -t TYPE35

; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> @ns1.easyclouddns.net ascENd4.org +norecurse +dnssec -t TYPE35
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14624
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 2800
;; QUESTION SECTION:
;ascENd4.org.                   IN      NAPTR

;; AUTHORITY SECTION:
ascENd4.org.            7200    IN      SOA     ns1.easyclouddns.net. root.ns1.easyclouddns.net. 2015021700 86000 7200 12096000 600

;; Query time: 305 msec
;; SERVER: 203.55.142.21#53(203.55.142.21)
;; WHEN: Sat Apr 22 12:39:02 CEST 2017
;; MSG SIZE  rcvd: 101

3.- Now quering a record defined and recognized:

Quering A (TYPE1) record:

$ dig @ns1.easyclouddns.net ascENd4.org +norecurse +dnssec -t TYPE1 +short
150.203.42.16

For me, easyclouddns.net DNS servers are broken, they should answer every question but in this case, the important record is CAA (TYPE257), Let’s Encrypt needs an answer… the answer could be the content of CAA record or nothing because it is not defined but needs an answer, not a DNS server time out .

I don’t know how easy could be to you but there are other free DNS servers out there that you could use.

Good luck,
sahsanu

[jdpipe]

Hi @sahsanu,

Thanks very much for your sleuthing. So I understand from what you say that my DNS provider is timing out when a CAA record is requested, but instead it should be reporting that there is no CAA record for my domain (and hence that it is allowed for letsencrypt to issue a certificate for this domain). Is that right?

This DNS service is provided by my domain registry, MelbourneIT. That is the reason I am using it. I’ll see what help they can provide about this issue.

Cheers
JP

[mnordhoff]

@jdpipe

So I understand from what you say that my DNS provider is timing out when a CAA record is requested, but instead it should be reporting that there is no CAA record for my domain (and hence that it is allowed for letsencrypt to issue a certificate for this domain). Is that right?

Just about. In another thread, @LeonA recently found that it sort of works (over TCP, which ordinary resolvers won't use without reason, so it doesn't help), there are more details from Let's Encrypt, and it seems to be actually working right... sometimes.

DNS problem: query timed out looking up CAA (using Netregistry)

W…

[jdpipe]

But I take it there’s not version of certbot-auto yet that implements this CAA check over TCP as a fallback/secondary check? It sounds like Netregistry should fix their DNS server, but that there is an available workaround if TCP is permitted in the case where the standard approach times out?

[ahaw021]

this is to do with Boulder not certbot

Boulder is the software that LetsEncrypt uses to run checks etc

Andrei

[jdpipe]

Somebody changed the title of this thread, and now the error message is no longer visible. For reference, the error message received from certbot was

Failed authorization procedure. ascend4.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: query timed out looking up A for ascend4.org

[jdpipe]

Hi Andrei
Given the error messages reported from certbot, and given your comment about Boulder, is it possible that Boulder should be reporting the problem with a timeout on the CAA record, rather than reporting failure to look up an A record?
Cheers
JP