After testing DNS-01 certificate issuance noticed a token in the content remained in the DNS TXT entry for more than an hour, so I deleted it manually.
This should be deleted asap normally.
All remaining entries used for this challenge (two at the same time can be seen) were deleted automatically.
The TTL for this kind of record is default 3600.
Is this common or some misconfiguration on my settings can cause it?
What should be checked to mitigate this in future?
Manually deleting the stuck entry was the right thing to do.
The record was put there by an ACME client and that client should have removed it after the record had served its purpose. If the client was interrupted or the configuration was changed or deleted between runs, the record would be orphaned. There is another way this can happen:
These clients work by reading the TXT resource record set (“all TXT records”), making the change and writing the modified TXT resource record set back. If there is a stuck record, the client won’t delete it because it could have been set by a different client. Deleting all TXT records and just setting the one that the client currently needs would be a bug. Due to the way the API works (read-modify-write without locking), there can be a race condition when multiple clients modify the zone at the same time. Try to avoid that by spacing cron jobs accordingly. Race conditions aren’t a concern if the API offers atomic deletes of individual records from a set, but this isn’t the case here.
The TTL is not the lifetime of the record in the zone, just the time a DNS client should cache it before asking the server again.