Windows server DNS


#1

Please fill out the fields below so we can help you better.

My domain is:owncloud.cnc.bc.ca

I ran this command:letsencypt --apache -d owncloud.cnc.bc.ca

It produced this output:Failed authorization procedure. owncloud.cnc.bc.ca (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 CAA for owncloud.cnc.bc.ca

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: owncloud.cnc.bc.ca
    Type: connection
    Detail: DNS problem: query timed out looking up CAA for
    owncloud.cnc.bc.ca

    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.

My operating system is (include version):Ubuntu 16.04

My web server is (include version):Apache 2.4

My hosting provider, if applicable, is:On premise

I can login to a root shell on my machine (yes or no, or I don’t know):Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):No

I can access the webpage locally and externally, I can also run dig sucessfully externally.
However when I run #dig -t TYPE257 owncloud.cnc.bc.ca I get a timeout
I know that Windows Server DNS does not support CAA, but I don’t get a timeout when I run dig locally.


#2

I think you’ve identified the exact problem here, and I’ve confirmed it for myself, but it’s not something Let’s Encrypt can control or affect. So you’ll have to talk to whoever is responsible for that DNS infrastructure to figure out why that timeout happens. (If it’s you, maybe you can find a forum related to the DNS software or hosting that you use for that site?)


#3

Thanks, I also checked with our firewall admin who says the PaloAlto is not capable of blocking resource record lookups.
Think I will look at the Windows firewall next.


#4

The Windows firewall is set to accept all DNS connections, is there a command flag in letsencrypt to bypass the CAA lookup?


#5

CAA is a mechanism that allows domain owners to (roughly speaking) declare which CAs are permitted to issue certificates for their domain. This mechanism would not be effective if you could simply instruct Let’s Encrypt to skip the check.

Unfortunately, fixing your DNS to serve an empty response or a CAA record would be the only option here.


#6

The CAA lookup happens on the CA (server) side and is mandatory as a matter of CA policy. It’s not being done by your client, it’s being done by the CA as part of the decision of whether to give you a cert.


#7

Okay, thanks for clearing that up for me. I will keep trying to track down where the failure is.


#8

So I have found the problem, don’t know if it will help anyone else but here it is. In my province of British Columbia, Canada the government runs a program called SPANBC that is used to connect all government agencies and public sector schools.
Using a reverse DNS trace (dig -x 142.27.70.239 +trace) I found that their DNS servers were the ones responsible for the CAA timeouts. I have now put it a help request to get that fixed.


#9

Not sure if this is off topic, and I will create a new one if necessary, but what would a proper response and an empty response to dig -t TYPE257 look like?


#10

Basically: RCODE=0 (“NOERROR”), ANCOUNT=0 (no answer)

This is what it would look like in dig:

; <<>> DiG 9.8.3-P1 <<>> -t TYPE257 letsencrypt.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8306
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;letsencrypt.org.		IN	TYPE257

;; AUTHORITY SECTION:
letsencrypt.org.	3600	IN	SOA	a20-66.akam.net. hostmaster.akamai.com. 1475184296 43200 7200 604800 7200

;; Query time: 67 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 30 00:20:30 2016
;; MSG SIZE  rcvd: 105

#11

Note that the same nameservers also block DANE TLSA lookups and likely queries for other valid RRtypes:

@ns1.cnc.bc.ca.[142.27.70.174]
; <<>> DiG 9.10.4-P2 <<>> +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t tlsa _25._tcp.owncloud.cnc.bc.ca @142.27.70.174
;; connection timed out; no servers could be reached

@ns2.cnc.bc.ca.[142.27.70.173]
; <<>> DiG 9.10.4-P2 <<>> +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t tlsa _25._tcp.owncloud.cnc.bc.ca @142.27.70.173
;; connection timed out; no servers could be reached

If the domain ever enables DNSSEC, it would be unable to receive email from DANE-enabled MTAs [ https://tools.ietf.org/html/rfc7672 ]. Not an issue at present, because DNSSEC is not yet deployed.

See https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-05 for why such blocking is wrong, and needs to be fixed.


#12

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