"The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A"

# certbot certonly -d delphi-real-estate.com,www.delphi-real-estate.com,mail.delphi-real-estate.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Error while running apachectl configtest.

AH00526: Syntax error on line 64 of /etc/httpd/conf.d/carls-vhosts.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/delphi-real-estate.com/cert.pem' does not exist or is empty


How would you like to authenticate with the ACME CA?
-------------------------------------------------------------------------------
1: Apache Web Server plugin - Beta (apache) [Misconfigured]
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
-------------------------------------------------------------------------------
Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 2
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for delphi-real-estate.com
tls-sni-01 challenge for www.delphi-real-estate.com
tls-sni-01 challenge for mail.delphi-real-estate.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. mail.delphi-real-estate.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for mail.delphi-real-estate.com, www.delphi-real-estate.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for www.delphi-real-estate.com, delphi-real-estate.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for delphi-real-estate.com

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: mail.delphi-real-estate.com
   Type:   connection
   Detail: DNS problem: SERVFAIL looking up A for
   mail.delphi-real-estate.com

   Domain: www.delphi-real-estate.com
   Type:   connection
   Detail: DNS problem: SERVFAIL looking up A for
   www.delphi-real-estate.com

   Domain: delphi-real-estate.com
   Type:   connection
   Detail: DNS problem: SERVFAIL looking up A for
   delphi-real-estate.com

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA 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.

************************************************************************

Well it comes up fine when pinging, on all three names.

DNSStuff finds everything is fine (except it can’t connect to port 25 which is understandable).

I don’t understand what is wrong here.

Your domain has some problems with DNSSEC: http://dnsviz.net/d/delphi-real-estate.com/dnssec/

If you try to query it using DNSSEC-validating resolver (such as Google Public DNS), you'll get SERVFAIL errors. You can also use https://unboundtest.com/, which is configured to mimic Let's Encrypt validation servers.

2 Likes

I’d demonstrated that DNSSEC cannot be the problem, in my last post over here:

Google Public DNS is resolving servfails as well:

# dig @8.8.8.8 delphi-real-estate.com A

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.4 <<>> @8.8.8.8 delphi-real-estate.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7376
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;delphi-real-estate.com.                IN      A

;; Query time: 61 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Nov 21 15:09:38 2017
;; MSG SIZE  rcvd: 40

# dig @8.8.8.8 delphi-real-estate.com NS

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.4 <<>> @8.8.8.8 delphi-real-estate.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2147
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;delphi-real-estate.com.                IN      NS

;; Query time: 83 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Nov 21 15:10:29 2017
;; MSG SIZE  rcvd: 40

I’m no DNSSEC expert, but this is going to cause issues with issuance regardless of cause. Let’s Encrypt handles DNS lookups slightly differently, but in general, if it fails on Google’s DNS, it’s probably going to have issues with Let’s Encrypt. (Note that the inverse is not necessarily true.)

I don’t understand what G**gle nor LetsEncrypt wants. I don’t know what more to do than to set it up correctly at a major DNS registrar, and exactly like I set up the other domains which got LE certs.

It is simply not a DNSSEC problem, unless it’s that G**gle and LetsEncrypt -require- DNSSEC.
And then it’s an impossible catch 22.

@Quantum, but there IS a problem with DNSSEC at your domain. Nameservers for .com domain claim that your domain has DS record set:

[mkwm]:~$ dig DS delphi-real-estate.com @a.gtld-servers.net

; <<>> DiG 9.9.10-P2 <<>> DS delphi-real-estate.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33355
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;delphi-real-estate.com.		IN	DS

;; ANSWER SECTION:
delphi-real-estate.com.	86400	IN	DS	1 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32 F24E8FB5

;; AUTHORITY SECTION:
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.

If you have disabled DNSSEC at your registrar, this record should disappear... But it is still present, not sure why... Maybe it's a bug at the registrar side?

3 Likes

Hmm, my registrar sees it just fine using G**gle, but we can not. He’s looking into that.

I’m in Seattle and you seem to be in Mountain View. Registrar is in Bryan, Texas, though my DNS has been up for several days.

Sure enough, Mountain View is one of the last to know:
https://www.whatsmydns.net/#A/www.delphi-real-estate.com
… although Dallas is out in the cold too.

Hell if I were in Russia or Pakistan I could get my certs now…

As of a minute ago, the .com DNS and whois servers both believe the DS record exists, from my perspective.

whatsmydns.net is just confirming which of its resolvers don't validate DNSSEC:

(That's an intentionally invalid domain.)

Edit: For that matter, the registrar's whois agrees.

1 Like

Maybe I’ll have it sooner or later. Dallas sees it now. Hey, Brazil just got the word. Mountain View is still in the dark, lol. The last one…

I don’t think whatsmydns is asking for DNSSEC - it’s asking for the A.

dig @8.8.8.8 delphi-real-estate.com A

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @8.8.8.8 delphi-real-estate.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17141
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;delphi-real-estate.com. IN A

;; Query time: 52 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Nov 21 14:42:37 PST 2017
;; MSG SIZE rcvd: 51

To clear up any confusion - DS record is a bit different from the others, as it is placed inside parent zone (com in your case), instead of directly inside your zone (delphi-real-estate.com). This means it requires special handling by your domain registrar (just like with changing NS records).

If you check your domain using Verisign Whois Search (Verisign is responsible for maintaing com DNS zone) at https://www.verisign.com/en_US/domain-names/whois/index.xhtml, you’ll get the following results:

Your search for delphi-real-estate.com returns the below results:

Domain Name: DELPHI-REAL-ESTATE.COM
Registry Domain ID: 1736975196_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.gkg.net
Registrar URL: http://www.gkg.net
Updated Date: 2017-11-18T18:56:44Z
Creation Date: 2012-08-02T18:24:33Z
Registry Expiry Date: 2019-08-02T18:24:33Z
Registrar: GKG.Net, Inc.
Registrar IANA ID: 93
Registrar Abuse Contact Email: abuse@gkg.net
Registrar Abuse Contact Phone: +1.8776951790
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited 
Name Server: NS3.GKG.NET
Name Server: NS4.GKG.NET
DNSSEC: signedDelegation
DNSSEC DS Data: 1 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
        
>>> Last update of whois database: 2017-11-21T22:55:22Z <<<

So, something clearly went wrong with disabling DNSSEC (DNSSEC: signedDelegation shouldn’t be there). I guess waiting would not help (as this is not a problem with DNS propagation) :frowning:

3 Likes

I see.

I’ve heard back from my registrar, and I don’t understand why delphi-real-estate.com was represented as DNSSEC (as opposed to the others), but to solve it he just turned DNSSEC on. His explanation isn’t clear, but I now have my delphi cert and all domains are now cranking.

“_After reviewing your domain configurations, The domain was not signed with DNSSEC, even though you had your Delegation Signer Records. By turning on DNSSEC is the DNS Configuration panel, it added the DNSKEY and RRSIGs to the domain. And synchronized properly. I was able to verify that DNSSEC is working through verisignlab’s DNSSEC debugger, you can also check with the link below. _
http://dnssec-debugger.verisignlabs.com/delphi-real-estate.com

Somehow he’s enabled DNSSEC – I’d thought that DNSSEC required the domain’s cert, but I haven’t gotten to that part yet so maybe I’m wrong.

1 Like

Nope, DNSSEC is a parallel system of validating domain name ownership. You are probably thinking of DANE, which is an additional system on top of DNSSEC that can express requirements about the domain's certificate. DANE is not implemented by browsers, so if your goal is securing a web site, it's probably not of interest to you.

Ah yes, DANE for email. Fortunately my registrar has a tab for TLSA. I’ll get to that at some point.

There’s a DANE plugin for Firefox, but I’m a bit wary of plugins. I’ll probably try out Bloodhound at some point. Hopefully Tor Broweser and Firefox will integrate the DANE patches soon.

Ok I have DANE set up now for quantum-sci.com on port 443, and mail.quantum-sci.com on ports 993 and 587.

What’s the use of DANE? DNSSEC makes sure that you get the correct IP address when you want to connect, while a DANE TLSA record (signed by DNSSEC) will give information about the SSL/TLS certificate you can expect at the specific service you are connecting to. This way you don’t have the (usual) plaintext exchange for initial authentication.

And needless to say, in using a trusted root CA like LE, your SMTPs server is much less likely to be thought carrying spam. And this will at least encrypt on the uplink and downlink with perfect forward secrecy, and depending on intermediate servers may remain encrypted through each transit hop.

It’s easy when your registrar supports it. I have a TLSA tab in Modify domains. Add a record and set
Port 443
Protocol tcp
Host @
Cert Usage 3.DANE-EE
Selector 1.SPKI
Match 2.SHA2-512
TTL 1 day

Then you need a SHA512 hash of the public cert: This site makes it easy: https://www.huque.com/bin/gen_tlsa
Or, you could use the sha512sum command, but you’d need to remove all the {CR}s from the cert first.

This sets your TLSA record for the website. You can also add TLSA records for email by doing all the same, but for ports 587 and 993. Be sure to set the domain here for mail.{mydomain}.com if that’s what you use.

Check your DANE functionality at https://www.huque.com/bin/danecheck
(It’ll take a bit to propagate)

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