Let's encrypt and Azure Private DNS zones

Help
1

from this post i have understood that let's encrypt does not generate certs for private domains directly,
but also found a comment which gives me work around, where i can use the public DNS for your certificate validation proof through TXT records

so in my public hosted zones,how do i configure these DNS with TXT records
so can i have the records in public dns temporary? if yes then during renewal do i need to add it again?

2

The Domain Name needs to be DNS public,
however other than the DNS records the server itself does not need to be publicly accessible.
You will need to use the DNS-01 Challenge to accomplish that.

The information on the Challenges can be found

4 Likes
3

Also it will most likely impact which ACME Client Implementations - Let's Encrypt ACME v2 Client you want to choose. :smile:

4 Likes
4

Yes and yes. Check the ACME v2 Clients to see which can help you automate the renewal task.

You might even desire changing DNS hosting Server if the one you presently are using does not easily support the DNS-01 Challenge.

4 Likes
5

this works for the first time ,once i get the certificate , then i can create the private dns zone with the same domain ,but during renewal won't this be an issue,the url will get resolved to private dns zone instead of the public dns zone and it would start failing?

6

Yes, renewal would once again use the public DNS, so if it's private at that time, it would fail.

Could you please explain your situation a little bit more? Maybe some other smart something might work (e.g. split horizon stuff), but at the moment we have no clue, so can't help you directly, only reactive by answering your questions.

3 Likes
7

In cases like yours, it is most common to have both a private and a public DNS zone. The private one is where your records point to your actual devices' private IP addresses. The public one would contain only public IPs (if they exist) and your TXT records associated with the ACME DNS challenges.

4 Likes
8

Scenario: i have a k8s cluster [private] in a vnet and this vnet has private dns zone
using an internal load balancer and nginx-ingress, doing host based routing , so none of my applications endpoints are exposed outside the vnet , now i would want to make my applications endpoints secure[https], how i can do this?

this is my exact scenario

9

i would have to keep my public and private dns same right?
so at the time of renewal instead getting resolved for public dns entry ,it would get resolved for the private dns entry since application is in a vnet and this would cause an issue right?

10

No, the public and private DNS zones are completely separate. In your case, the private zone stays as-is and untouched. The public zone only exists to satisfy the DNS challenges for the ACME protocol. None of your k8s stuff needs to exist in the public DNS zone. And only TXT records related to ACME will live in the public zone (and get updated each renewal ideally by your ACME client).

I should add that this also only works if the domain name associated with the private zone is a publicly registered domain you actually own/control. You can't request public certificates for internal-only names like corp.local.

5 Likes
11

so you are telling there won't be conflict [during updating txt records by ACME client], even i have the same dns entry in both public and private dns zones

12

Yes. It's a very common configuration sometimes known as "split brain" or "split horizon" DNS. Internal clients are configured to use internal DNS resolution which only resolves records from the private zone. External clients use standard public recursive resolvers to only resolve records from the public zone.

5 Likes
13

So since let's encrypt during first time/renewal process it would always be external client it would 100% use the public dns zone and the conflict would never arise am i right?

14

Yes. Maybe it helps to know you use an ACME Client to request a cert but the Let's Encrypt ACME Servers do the authentication (and cert issuance). These LE Servers operate in the public internet and have no way to see private systems.

4 Likes
15

Are those clients able to validate globally signed certs?

Yes; And as an extreme example:
I could also create a duplicate zone (of your real domain) in my home DNS.
No one on the Internet will ever know about it - they can't.

4 Likes
16

_acme-challenge. TXT record was automatically added in public dns zone but after that facing this issue

cert-manager/challenges "msg"="propagation check failed" "error"="DNS record for "xxx-xxx.abc.xyz" not yet propagated" "dnsName"="xxx-xxx.abc.xyz" "resource_kind"="Challenge" "resource_name"="test" "resource_namespace"="default" "resource_version"="v1" "type"="DNS-01"

i am using an internal load balancer

what exactly the issue is here?

17

For DNS?

It seems like you may need to wait a bit longer for the authoritative DNS servers to sync:

OR
Your cert-manager system isn't using the same internal DNS system for verification...???

3 Likes
18

my application is behind ingress-nginx using internal load balancer
I am using both internal and external dns zone [split horizon" DNS]
but for dns solver check i am using the external/public dns zone in aws route 53

19

Not DNS related.

Are you 100% certain?

3 Likes
20 
    solvers:
    - selector:
        dnsZones:
          - "abc.xyz"
      dns01:
        route53:
          region: xxxxxxxxxxxx
          hostedZoneID: xxxxxxxxxxxx
          accessKeyID: xxxxxxxxxxxx
          secretAccessKeySecretRef:
            name: route53-secret
            key: secret-access-key

  1. but one thing is i am not using actual domain using sub domain? would that be an issue [i don't think so]?

  2. and it works perfectly fine when i am using http01 solver and application is behind an external load balancer