TXT record is not found

Did you check on both authoritative DNS servers?

From the "outside in"; As would anyone else on the Internet.


We check it in SoftLayer UI or with command dig
(for our domains, we can't check the customer's domains)

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31275
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Using dig is good.
You would have to follow the authoritative path from "."


Or, use https://unboundtest.com


The more I look at that code, the more it seems flawed [to me].
Potentially capable of returning false positives.
It relies on two hard-coded public DNS servers [and whatever server(s) are in /etc/resove.conf - which are likely also unrelated public server(s)]
To validate the presence of a TXT record in the public space - NOT in existence in ALL authoritative DNS servers for your zone.

But that isn't the entire code, so I might have missed something(s).
That's just how I see it [given that small view]


But you may need to take a class on how to read that unbound output - LOL


Can you please explain?

this code is here lego/nameserver.go at master · go-acme/lego · GitHub

If I want to add my code checking that the TXT record is propagated and visible from the web, which go lib would you recommend using for this purpose?

Say we want the authoritative DNS replies for: ...

Start with the DNS root:
nslookup -q=ns "."
[shows a list of authoritative DNS servers for the "." (root) domain]

Take any server from that reply and ask it for "com."
nslookup -q=ns com. IP.IP.IP.IP
[IP.IP.IP.IP (or name) from reply above]

Take any server from that reply and ask it for "example.com."
nslookup -q=ns example.com. IP.IP.IP.IP
[IP.IP.IP.IP (or name) from reply above]

Take ALL server from that reply and ask each for "xyz.example.com."
nslookup xyz.example.com. IP.IP.IP.IP1
nslookup xyz.example.com. IP.IP.IP.IP2
[IP.IP.IP.IP1 & IP2 (or name) from reply above]

Those responses are the true authoritative responses for xyz.exmple.com.

nslookup xyz.example.com. google-public-dns-a.google.com
is NOT an authoritative response.


Yes! But, the top part is just like dig and readily shows existence or errors for domain and record type. And, chases the tree.


Can I use this example code to check that TXT record was propagated and we can call LE to validate a challenge?

Only if you make those requests against both of your authoritative DNS servers.
To that end, you could just alter the lego code to use your authoritative DNS servers instead of the two public DNS servers.

//[not needed] const defaultResolvConf = "/etc/resolv.conf"
// altered to use the authoritative name servers
var defaultNameservers = []string{
// recursiveNameservers are used to pre-check DNS propagation.
var recursiveNameservers = getNameservers(defaultNameservers)

Thank you for your help
This code is of Lego, we can't change it and we don't want to change it because we have a lot of customers with different DNS providers and domains and all orders use the same code

1 Like

I understand.
But it would be helpful to know if that does make any difference [if it does fix this problem OR not].


If I use dig command, does it check the both nameservers?
If I use go net.LookupTXT("mydomainl.com") where it takes txt records?

No, dig doesn't; You do.
And it's not possible with any single request.
You can manually point dig at each authoritative nameserver.
[but you first need to find out which are the authoritative nameservers]


I see.
Thank you.

1 Like

I debugged Lego code
They indeed always get authoritative nameservers and queries each of them for the expected TXT record.
and still after this check LE fails to find TXT record
what can be a reason?

1 Like

Have you tried just increasing the interval even longer for this customer? We see some DNS providers that use Anycast take as long as 1-2H. That's not true for all Anycast I am just describing one of the worst.