Hi markus,
Thank your very much for reporting the issue, and welcome to deSEC! 
We do appreciate users reporting these things. I am going to give a bit of a longer response, because we have been receiving similar reports repeatedly, and I would like to write down what I think is the fundamental issue with these tools. This is in no way meant to diminish your report!
Domains have so-called REFRESH and RETRY values, which dictate details of synchronization timing for DNS data within the DNS provider’s systems (“replication”). So we’re talking about values that only carry meaning internally (although they are, unfortunately, visible from the outside – that’s by design).
DENIC now thinks that the RETRY value should fall within a specific range of fractions (1/8 and 1/3) with respect to REFRESH. We use REFRESH=86400, so according to DENIC, RETRY should lie between 10800 and 28800. But we actually think that we know better what’s an adequate value for our use case (namely 3600, see below for details).
The DENIC recommendation also is in violation of a recommendation by RIPE, which suggests 7200 as a static value. So even in case we followed DENIC’s advice, it could happen that some other registry’s checker software will complain about not following the RIPE recommendation.
As you can see, there’s no way to satisfy all the recommendations. The root of the problem is that recommendations are given without technical merit. There is absolutely no reason why domains under .de should not work correctly for any RETRY value; the DNS provider just need to get their replication mechanism right. What’s the warning supposed to mean, even? (“Warning: Your DNS provider may be using custom replication” - so what?) It’s a fallacy to think that all replication mechanisms need RETRY values as DENIC (or anyone) thinks, and the fault lies with those making the recommendation.
If anything, this “warning” should actually be classified as a “hint” or “notice”, as its cause is not actually a technical problem. If you feel disturbed by the message, I think the best way forward would be to take it up with DENIC and ask them to change their tooling.
In fact, we need a high REFRESH and a low RETRY value. Here’s why: In standard DNS replication, each secondary server (of which we have 15) will send an SOA query to the primary server for each domain under management, every REFRESH seconds, to learn whether it needs to update its local copy of the domain’s records. We want global propagation of updates within seconds, and if we would rely on this mechanism, we would have hundreds of thousands such queries per second. We therefore use an entirely unrelated, push-not-poll mechanism for secondaries to discover updates. – This only works for actual record updates triggered by the user or API. We also recompute signatures periodically (weekly), even when nothing else changed. There is no rush to roll out these new signatures, as the validity windows of old and new ones overlap by around a week. So we use REFRESH=86400 to stretch out those signature updates across one whole day, with evenly distributed load on the primary. Still, when such an update fails, we want to start a new attempt timely, after an hour (RETRY=3600). – Did you notice? None of that has anything to do with DENIC.
We have received similar reports repeatedly, and we think it is not helpful that checking tools report things that are entirely inconsequential from the parent’s perspective. We think that parents should leave DNS operators alone, and let them operate their things as they like to do it (unless there is actual breakage). Other instances of this problem from various checkers are (1) Invalid SOA record, (2) Reachability of digga.desec.io, and (3) NIC.it CNAMEHostTest Failed changing nameservers.
In any case: Again thank you for your report!
Stay secure,
Peter
