Authoritative DNS Server support not working

[ericcan]

I have been using the DNS challenge support for the acme-dns server and it has been working great. Today, I removed the default DNS server from my settings file, allowing the plug-in to use a randomly assigned DNS server along the lines of LetsEncrypt's method. According to the preliminary test, WACS reported that my TXT field was returning NULL rather than the assigned value (my CNAME record was set weeks ago, so it was not an issue of propagation). letsencrypt WAS able to find the TXT token just fine and the certificate was issued.

I manually looked up the record with the reported authoritative DNS server that WACS had chosen and it was able to find my CNAME record, but was not returning a TXT record.

I have a theory that perhaps authoritative DNS servers don't do a recursive search the way that middleman DNS servers do. Here is the result I got from NSLOOKUP using an the authoritative server:

_acme-challenge.mydomain.org canonical name = 499320ea-ea38-46bf-9724-c421e7581f3d.auth.mydomain.org
auth.mydomain.org nameserver = auth.mydomain.org
auth.mydomain.org internet address = 35.202.100.100

If I run the same query with Google's DNS, I do get a TXT record.

So, is it possible more steps are needed to recursively search for the TXT record in this new approach?

[ericcan]

I should also add that when I look at the logs of my acme-dns server, the DNS lookup by WACS shows no sign of querying my server (meaning that the lookup doesn't appear to have followed the CNAME alias). The lookup for letsencrypt shows in the logs just fine.

[WouterTinus]

@davidpeden3 do you have time to look into this?

[davidpeden3]

yep, i can look at it tomorrow. @ericcan is sort of correct about the recursion. @MichaCo addressed this topic in the question i posted in MichaCo/DnsClient.NET#43.

There might be additional answers in the query result which resolve the FQNs of the nameservers.
Public DNS servers usually don't recursively resolve answers though and you'd have to do that yourself.

i didn't see this in my testing but with a repro (as mentioned above), it should be easy to address. i'll just have to walk the results until the end of the line. @WouterTinus this makes supporting async all the more important... ;)

[davidpeden3]

@ericcan i need a real example in order to fix this. if you are not comfortable posting one here, you can shoot me an email at [my username]@gmail.com. thanks

[davidpeden3]

@WouterTinus @ericcan i have pushed a fix in my fork for your review and feedback. i have a supporting test that verifies this code works as expected using both my personal and @ericcan's personal dns configurations.

please review davidpeden3@96c32cb and provide feedback. once we get things settled (including figuring out the testing part), i will push the pr here.

@WouterTinus, please shoot me an email (see comment above for address) so that i can loop you into the conversation that @ericcan and i have going, specifically around testing with potentially sensitive data.

thanks.

[WouterTinus]

I've just sent you an email!

[ericcan]

Just to summarize, there are two separate issues with the preliminary DNS search that occurs during DNS validation (both result from usage of the acme-dns server):

1. Handling multiple TXT records
2. Handling CNAME records when using an authoritative DNS Server for the preliminary test.

I definitely think it's worth handling the first one. For the second, given the added complexity, I could make the case that it would be a reasonable tradeoff to go back to the approach of using a recursive DNS server (like OpenDNS) instead of building in all the logic of recursing. For an informational preliminary test, relying on a publicly available option will provide nearly as much information without a lot of extra complexity.

If we did want to utilize our newly found DNS expertise, I think it could be a nice feature for the acme-dns plug-in to actually check that the challenge domain was CNAME'd to the appropriate location, but again, not a requirement by any means.

[davidpeden3]

My PR adds support for both of the issues that you cite, @ericcan. And, if you prefer, you can override the name server via configuration to get your desired behavior. In my case, the default name server didn't know about my DNS records which is why I pursued going to an authoritative source.

Regarding your feature request, can you explain that in more detail?

[ericcan]

Current behavior:
In AcmeDnsClient, the user is instructed in the case of a new registration to create a CNAME for the _acme-challenge subdomain. In the case of an existing registration, the user is asked to confirm that the mapping exists as well.

Proposed behavior:
New registration: Once the user confirms they have set up the CNAME record, we could do a DNS lookup to see that the mapping indeed exists and matches what it should. If it doesn't, we would allow the user to choose to retry (to allow for double checking their DNS records or just to give additional time for the change to propagate) or to ignore.

In the case where the the registration already exists, we could do the lookup proactively and only wait for input if a dns query shows that the CNAME mapping is not yet established. In the case of waiting, we would offer the same retry/ignore as the new registration case.

[WouterTinus]

@ericcan I like your idea, that way we could even make AcmeDns work in unattended mode. But I think it deserves it's own issue, so that we can close this one when the bug fixes are in. Would you mind copying this proposal into a new thread?

[ericcan]

@WouterTinus Done! (#1070)

[WouterTinus]

I've done some refactoring and improved reliability based on two of my own DNS providers, so this will be in 2.0.5.

[WouterTinus]

Released in 2.0.5