Validating via Microsoft DNS API local

Question
#1

Hello, my name is Frank
I have a problem with the automatic Certificate Update.
We use the
Challenge Typ: dns-01, DNS Update Method: Microsoft DNS API
Server Name is the local MS DNS Server FQDN and his IP-Address
Remote Managment Prot is DCOM and Authentication is Default.
The process begins with create the txt Records successful.
The delay time ist 30 seconds.
After the delay runs the process in an error.
it is possible a DNS txt read error.
Where ist the protocol to find the error message?

best regards
Frank

#2

Hi Frank, can you share a log file for the certificate request? You can get this from the status page your managed certificate > Open Log File

Let’s Encrypt DNS validation works but checking any of your primary or secondary nameservers (sometimes more than one) for the TXT record so you need to leave enough propagation time for the TXT record change to copy to all of your nameservers before the validation can proceed. You could try increasing your propagation delay to 120 seconds.

#3

Hi.
the delay time is now 300 seconds
the txt record is created, but the request is wrong.
Where i can the log file upload?

#4

Step One:

2021-04-05 21:16:12.117 +02:00 [INF] Attempting Domain Validation: mail.apparet-it.net
2021-04-05 21:16:12.117 +02:00 [INF] Registering and Validating mail.apparet-it.net
2021-04-05 21:16:12.117 +02:00 [INF] Performing automated challenge responses (mail.apparet-it.net)
2021-04-05 21:16:12.120 +02:00 [INF] DNS: Creating TXT Record ‘_acme-challenge.mail.apparet-it.net’ with value ‘VBDo12yh0CV3PfCgxJjT7pw97CUVa7XnAk30u_umWUc’, in Zone Id ‘’ using API provider ‘Microsoft DNS API’
2021-04-05 21:16:12.346 +02:00 [INF] DNS: Microsoft DNS API :: DNS record updated
2021-04-05 21:16:12.348 +02:00 [INF] Requesting Validation: mail.apparet-it.net

Delay for 300 Seconds

#5

The DNS TXT Record was created for mail.apparet-it.net
My control has successfully determined this.

After Delay, Step Two:
2021-04-05 21:21:13.553 +02:00 [INF] Attempting Challenge Response Validation for Domain: mail.apparet-it.net
2021-04-05 21:21:13.553 +02:00 [INF] Registering and Validating mail.apparet-it.net
2021-04-05 21:21:13.553 +02:00 [INF] Checking automated challenge response for Domain: mail.apparet-it.net
2021-04-05 21:21:14.710 +02:00 [WRN] Challenge response validation still pending. Re-checking [10]…
2021-04-05 21:21:16.635 +02:00 [INF] DNS problem: NXDOMAIN looking up TXT for _acme-challenge.mail.apparet-it.net - check that a DNS record exists for this domain
2021-04-05 21:21:18.099 +02:00 [INF] DNS: Deleting TXT Record ‘_acme-challenge.mail.apparet-it.net’, in Zone Id ‘’ using API provider ‘Microsoft DNS API’
2021-04-05 21:21:18.932 +02:00 [INF] Validation of the required challenges did not complete successfully. DNS problem: NXDOMAIN looking up TXT for _acme-challenge.mail.apparet-it.net - check that a DNS record exists for this domain
2021-04-05 21:21:18.932 +02:00 [INF] Validation of the required challenges did not complete successfully. DNS problem: NXDOMAIN looking up TXT for _acme-challenge.mail.apparet-it.net - check that a DNS record exists for this domain

The delete process for the DNS TXT Record was succesful.

#6

Hi Frank, the app thinks it has updated your DNS server OK. It appears as if the DNS server Certify is updating is not your public DNS server that Let’s Encrypt will see.

Can you confirm that the authoritative DNS nameserver you expect to update are ns1.domainknecht.de and ns2.domainknecht.de.

You can check these during the request to see if the TXT record is present using dig -t TXT _acme-challenge.mail.apparet-it.net from a linux (or WSL) terminal or from a windows command prompt nslookup -type=txt _acme-challenge.mail.apparet-it.net

#7

Hi,
ns1.domainknecht.de and ns2.domainknecht.de is not my local DNS Server
my local DNS Server are DCx12.apparet-it.qm as primary and DCx12.apparet-it.qm as secundary has also a zone apparet-it.net
the certificate process is starting of the Exchange Server machine (mailx1.apparet-it.qm)
the txt records was created in the local MS DNS Server.
between the delay of 300 seconds
test the dns services wtih nslookup of all machines
[MAILx1.apparet-it.qm] PS U:> nslookup
Standardserver: DCx12.apparet-it.qm
Address: 192.168.200.222

set qt=txt
_acme-challenge.mail.apparet-it.net
Server: DCx12.apparet-it.qm
Address: 192.168.200.222
_acme-challenge.mail.apparet-it.net text = “UOQ8x6tzlIRa6nOliEQ0zjQ6yNLQyTFcKiSkNUmZ0DM”

[DCx1.apparet-it.qm] PS U:> nslookup
Standardserver: DCx12.apparet-it.qm
Address: 192.168.200.222

set qt=txt
_acme-challenge.mail.apparet-it.net
Server: DCx12.apparet-it.qm
Address: 192.168.200.222
_acme-challenge.mail.apparet-it.net text =
“UOQ8x6tzlIRa6nOliEQ0zjQ6yNLQyTFcKiSkNUmZ0DM”
server DCx11.apparet-it.qm
Standardserver: DCx11.apparet-it.qm
Address: 192.168.200.212
_acme-challenge.mail.apparet-it.net
Server: DCx11.apparet-it.qm
Address: 192.168.200.212
_acme-challenge.mail.apparet-it.net text =
“UOQ8x6tzlIRa6nOliEQ0zjQ6yNLQyTFcKiSkNUmZ0DM”

after the delay form 300 seconds
DNS problem: NXDOMAIN looking up TXT for _acme-challenge.mail.apparet-it.net - check that a DNS record exists for this domain
DNS: Deleting TXT Record ‘_acme-challenge.mail.apparet-it.net’, in Zone Id ‘’ using API provider ‘Microsoft DNS API’

#8

You must update the nameservers listed in your domain’s WHOIS records. These are the servers that Let’s Encrypt will be talking to. Let’s Encrypt secures publicly available servers and uses public records in order to do so. It doesn’t seem like your local DNS server affects public data.

Try adding 8.8.8.8 to the end of your nslookup command to bypass your local DNS server to see what your public records(according to Google) state for the TXT record. Asking DCx12.apparet-it.qm with nslookup will give you false positives.

#9

Yes, if you need to use DNS validation to prove your domain control then Let’s Encrypt (the Certificate Authority) will check your public DNS, not your local DNS (they can only see the public DNS).

If your mail server has port 80 open (it doesn’t need to have IIS) you could try using http validation instead of dns validation. Certify will spin up a temporary http server on port 80 during validation (if nothing else is using port 80 or if only IIS is).

Another option is acme-dns or scripting your own DNS updates against your public DNS provider.

#10

Hi, Very thanks for your answers
I can not understand this
Create and Delete of TXT Records in local DNS Server is succesful
However, the checking is carried out in the public DNS server
Why is it not checked locally as well?

#11

Certify The Web is an app to make automatic certificate renewals easier, but it it not the Certificate Authority - it does not issue the certificates, it orders them from Let’s Encrypt and attempts to perform all the steps required to help validate your domain.

The Certificate Authority is Let’s Encrypt (by default) and they can only check your domain using public information they can verify such as your public DNS records or information that your server can provide over http.

So although you are managing to update your local DNS, you are not updating your public DNS (the part that Let’s Encrypt can see).

I would recommend you either try http validation instead or try acme-dns (see https://docs.certifytheweb.com/docs/dns/providers/acme-dns) which is a system where you create a CNAME once then future validation attempts update the acme-dns server instead of your real DNS server.

#12

One thing to understand is that the DNS/HTTP validation is a challenge rather than configuration. Let’s Encrypt is challenging you to prove that you own the domain you’re trying to get a certificate for. When you’re updating your local DNS, you’re failing to answer the challenge because Let’s Encrypt cannot see your local(private) answer.

1 Like
#13

Hi, Ok Thank you for your answers
i understand this now
the Certificate Authority can only validate in the public DNS Records, which does find in the whois records

1 Like