Problem with Round Robin DNS


#1

Hi Everyone,

I got problem with domain which use Round Robin DNS, it’s just can generate at ones time, but can not generate again. I got random error, here is :

[first error]
Failed authorization procedure. ha.sample-domain.org (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found ‘ssl1.sample.org, ssl2.sample.org

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: ha.sample-domain.org
    Type: unauthorized
    Detail: Correct zName not found for TLS SNI challenge. Found
    ssl1.sample.org, ssl2.sample.org

    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.

[second error]
Failed authorization procedure. ha.sample-domain.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: ha.sample-domain.org
    Type: connection
    Detail: Failed to connect to host for DVSNI 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.

I generate cert with the same command, using this :
/usr/local/letsencrypt/letsencrypt-auto --agree-tos --agree-dev-preview auth --standalone --csr /test/5/ha.csr --cert-path /test/5/ha.crt --fullchain-path /test/5/ha.full.pem --chain-path /test/5/ha.pem --email mymail@gmail.com

What must I do?

If I use dig for get A record, here is the result :
me@device:~$ dig A ha.sample-domain.org

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> A ha.sample-domain.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16160
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ha.sample-domain.org. IN A

;; ANSWER SECTION:
ha.sample-domain.org. 30 IN A X.X.X.X
ha.sample-domain.org. 30 IN A Y.Y.Y.Y
ha.sample-domain.org. 30 IN A Z.Z.Z.Z

;; Query time: 439 msec
;; SERVER: 192.168.0.254#53(192.168.0.254)
;; WHEN: Sun Apr 10 23:00:42 WIB 2016
;; MSG SIZE rcvd: 86

='FYI, 2 days ago I try generate cert and got 2-3 times error, but I can generate until 5 cert.

** sample-domain.org is not real, I just change for sample.
Thank you so much.


#2

In order to verify ownership of your domain, Let’s Encrypt’s CA server will attempt to connect to your domain and request a specific resource that you need to serve in order to demonstrate that you have full control over the domain.

If you’re using round-robin DNS , you don’t know which of your IPs the CA server will connect to ahead of time, so you’ll have to ensure all IPs will be able to respond to the challenge.

There are a number of approaches you could try:

  • If you have some kind of shared storage between your nodes, I would recommend using the webroot plugin. Pass the path to your shared storage as the -w argument and make sure all nodes serve the files in that directory when a request is sent to http://example.com/.well-known/acme-challenge/{random}.
  • You could also designate one of your nodes as the “verification” node (or even a separate node, for that matter) and configure all your other nodes to redirect requests to that node. Let’s say you have a.example.com, b.example.com and c.example.com. All three are configured to redirect requests for /.well-known/acme-challenge/* to http://a.example.com/.well-known/acme-challenge/*, where a.example.com is your verification node - the one where you run the client using the webroot plugin.
  • Finally, you could use the dns-01 challenge which works by creating a TXT record on your DNS server to verify ownership. This is probably only an option if you have an automated way to modify your DNS, as you’ll have to repeat this every three months. The official client currently doesn’t support dns-01 yet, but the three bash clients do.

Note that with all three options, it’s up to you to distribute the keys to all nodes securely.


#3

Hi,

Thank you for your explain, so the essence is all node is must be same if we want to use round-robin DNS.

:slight_smile:


#4

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