search

TechnitiumSoftware / DnsServer

Technitium DNS Server
https://technitium.com/dns/
GNU General Public License v3.0
3.84k stars 400 forks source link

DDNS / RFC2136 Logging? Having issues with records not being created #811

Closed alexhorner closed 4 months ago

alexhorner commented 6 months ago

I am currently trying to set up acme.sh to use DDNS / RFC2136 to update records for certificate issuance and it believes it has sucessfully created these records, however they do not appear to have been created at all, nor can they be looked up.

Is there logging around this? I don't see a Zone update message in the normal log.

ShreyasZare commented 6 months ago

Thanks for the post. Yes, the dynamic DNS request gets logged but it does not list all the contents of the request though.

The acme script will cleanup the records that it adds so you wont find those records in the zone later. If the cert renewal is succeeding then its working well.

alexhorner commented 6 months ago

Sadly the renewal is not working and I am not seeing any logs anywhere.

Curiously, if I make the TSIG token incorrect it does error, so something is working correctly, but records are not being created and no logs are appearing, and the SOA serial number doesn't change either which is further evidence of this.

alexhorner commented 6 months ago

Here are logs from acme.sh and the configuration on my server (I have redacted the domains):

[Tue Dec 19 08:12:06 UTC 2023] Using CA: https://localhost:9856/acme/acme/directory
[Tue Dec 19 08:12:07 UTC 2023] Multi domain='DNS:ca.domain.com,DNS:ca.containers.servera.domain.com,DNS:stepca.containers.servera.domain.com'
[Tue Dec 19 08:12:07 UTC 2023] Getting domain auth token for each domain
[Tue Dec 19 08:12:08 UTC 2023] Getting webroot for domain='ca.domain.com'
[Tue Dec 19 08:12:08 UTC 2023] Getting webroot for domain='ca.containers.servera.domain.com'
[Tue Dec 19 08:12:08 UTC 2023] Getting webroot for domain='stepca.containers.servera.domain.com'
[Tue Dec 19 08:12:08 UTC 2023] Adding txt value: Eyq2w_wmYVB3-srfRULImKWQTdghRcWXQap3ECh0E0E for domain:  _acme-challenge.ca.domain.com
[Tue Dec 19 08:12:09 UTC 2023] The txt record is added: Success.
[Tue Dec 19 08:12:09 UTC 2023] Adding txt value: Ahn7BpDP5-IBlFiOK3EcPe-8hBrn6RRfE-hr1Rq3x84 for domain:  _acme-challenge.ca.containers.servera.domain.com
[Tue Dec 19 08:12:09 UTC 2023] The txt record is added: Success.
[Tue Dec 19 08:12:09 UTC 2023] Adding txt value: 6GDqAXcZG9hZxlL5HoG9o24jPqAfRlTz6Bi3EDT4aa8 for domain:  _acme-challenge.stepca.containers.servera.domain.com
[Tue Dec 19 08:12:10 UTC 2023] The txt record is added: Success.
[Tue Dec 19 08:12:10 UTC 2023] Let's check each DNS record now. Sleep 20 seconds first.
[Tue Dec 19 08:12:31 UTC 2023] You can use '--dnssleep' to disable public dns checks.
[Tue Dec 19 08:12:31 UTC 2023] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck
[Tue Dec 19 08:12:31 UTC 2023] Checking ca.domain.com for _acme-challenge.ca.domain.com
[Tue Dec 19 08:12:33 UTC 2023] Not valid yet, let's wait 10 seconds and check next one.
[Tue Dec 19 08:12:45 UTC 2023] Checking ca.containers.servera.domain.com for _acme-challenge.ca.containers.servera.domain.com
[Tue Dec 19 08:12:46 UTC 2023] Not valid yet, let's wait 10 seconds and check next one.
[Tue Dec 19 08:12:58 UTC 2023] Checking stepca.containers.servera.domain.com for _acme-challenge.stepca.containers.servera.domain.com
[Tue Dec 19 08:12:58 UTC 2023] Not valid yet, let's wait 10 seconds and check next one.
[Tue Dec 19 08:13:10 UTC 2023] Let's wait 10 seconds and check again.
[Tue Dec 19 08:13:21 UTC 2023] You can use '--dnssleep' to disable public dns checks.
[Tue Dec 19 08:13:21 UTC 2023] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck
[Tue Dec 19 08:13:21 UTC 2023] Checking ca.domain.com for _acme-challenge.ca.domain.com
[Tue Dec 19 08:13:21 UTC 2023] Not valid yet, let's wait 10 seconds and check next one.
[Tue Dec 19 08:13:33 UTC 2023] Checking ca.containers.servera.domain.com for _acme-challenge.ca.containers.servera.domain.com
[Tue Dec 19 08:13:33 UTC 2023] Not valid yet, let's wait 10 seconds and check next one.
..... goes on forever

image image image

ShreyasZare commented 6 months ago

Thanks for the details. Your zone config looks good. Do you see any log entries in the DNS logs section on the panel? There will be a log entry for each dynamic update request that the DNS server receives.

alexhorner commented 6 months ago

I'm not seeing anything related to the update request. Am I looking in the correct place?

image

ShreyasZare commented 6 months ago

I'm not seeing anything related to the update request. Am I looking in the correct place?

Yes, you should see the logs here. Did you had logging disabled from Settings > Logging section?

alexhorner commented 6 months ago

Logging is enabled, but I have now turned on Log All Queries and I see this:

[2023-12-19 13:12:04 UTC] [10.0.10.190:57270] [TCP] QNAME: ca.domain.com; QTYPE: SOA; QCLASS: IN; RCODE: NotAuth; TSIG: NoError; ANSWER: []
[2023-12-19 13:12:05 UTC] [10.0.10.190:57280] [TCP] QNAME: ca.containers.servera.domain.com; QTYPE: SOA; QCLASS: IN; RCODE: NotAuth; TSIG: NoError; ANSWER: []
[2023-12-19 13:12:05 UTC] [10.0.10.190:57284] [TCP] QNAME: stepca.containers.servera.domain.com; QTYPE: SOA; QCLASS: IN; RCODE: NotAuth; TSIG: NoError; ANSWER: []

acme.sh is behaving identically. Not sure if this is an error or just informational?

ShreyasZare commented 6 months ago

It seems that the queries are not being received by the DNS server and are being sent somewhere else. I would suggest that you run Wireshark/tcpdump and confirm if the request is being received.

alexhorner commented 6 months ago

I haven't run a tcpdump, but changing the IP address of the ddns server causes acme.sh to fail almost immediately, so it is definitely getting through

ShreyasZare commented 6 months ago

I would still recommend that you run tcpdump and check the request and response. If you can share the pcap file over email then it would be good to see the request & response details. Without these details, it will be difficult to find out what exactly is the issue.

alexhorner commented 6 months ago

I have sent you an email containing a raw pcap dump and unredacted configuration screenshots to support@technitium.com

ShreyasZare commented 6 months ago

I have sent you an email containing a raw pcap dump and unredacted configuration screenshots to support@technitium.com

Thanks for the details.

The issue is that the dynamic request is being sent with zone name as "cc.domain.com" while the actual zone is "domain.com" which is why the DNS server is rejecting the request. So, you need to configure your acme client settings to use the correct zone name to fix the issue.

alexhorner commented 6 months ago

I am currently investigating issues with both acme.sh and DNS-Lexicon and will report back findings which will hopefully fix this

alexhorner commented 6 months ago

Lexicon issue tested and reported: https://github.com/AnalogJ/lexicon/issues/1840

alexhorner commented 6 months ago

acme.sh issue tested and reported: https://github.com/acmesh-official/acme.sh/issues/4921

ShreyasZare commented 6 months ago

There could be many DDNS clients with issues like these. So I did some analysis and looks like updating the DNS server to find the closest parent zone for a given domain name in the request should be ok to implement. Will get that done in the next update.

alexhorner commented 6 months ago

@ShreyasZare Does this fit the RFC? I haven't read it that closely, but if not then your product shouldn't have to compromise for the failings of others which are not following the RFC. The only real argument against this is if you can find other DNS servers which collectively all take this same "closests matching" approach. If you are certain that you want to do this, may I suggest you make it configurable?

May I also suggest additional logging for both successful and failed DDNS update queries?

ShreyasZare commented 6 months ago

@ShreyasZare Does this fit the RFC?

The RFC says to use the zone name which I interpreted as the exact zone name.

I haven't read it that closely, but if not then your product shouldn't have to compromise for the failings of others which are not following the RFC.

Most implementations are usually done such that they accept requests with flexibility but always respond as per standard. This allows to work with common issues without any breakage. Such decisions are made in many places in most implementation if it does not break anything.

The only real argument against this is if you can find other DNS servers which collectively all take this same "closests matching" approach.

Probably there are other DNS servers that do it already which is why those DDNS clients did not bother to have any option to specify correct zone.

If you are certain that you want to do this, may I suggest you make it configurable?

Its not a big change and as per my analysis and its not going to break anything else (except for case when NS or DS record needs to be updated in which case the zone must be exactly specified in the request). So no need to add another option for the user to think about which they may not fully understand.

May I also suggest additional logging for both successful and failed DDNS update queries?

There is logging already being done but its done only after the DNS server ensures that the zone exists. There is no logging done when the zone does not exists just to prevent someone from flooding the logs with irrelevant DDNS requests.

alexhorner commented 6 months ago

Alrighty, sounds good, I just don't want to be the one which causes a breakage due to my issue :P Hopefully it won't be an issue for acme.sh soon anyway but I wouldn't want to guess how many other clients are also broken

ShreyasZare commented 4 months ago

Technitium DNS Server v12 is now available which now finds the closest parent zone for dynamic updates. Do update and let me know your feedback.