I have a .is domain hosted at deSEC. The ISNIC .is registry demands that all DNS servers return the same serial number for a domain. It also demands that the primary DNS server (which I run outside of deSEC) has an IP that reverse resolves to ns.mydomain.is.
Because of these two demands, the seemingly spontaneous incrementing of the serial that deSEC does, is making my domain fall out of compliance regularly, jeopardising the domain name and everything that runs on it.
How can I stop the deSEC DNS server from changing the serial number on my domain spontaneously and without changes to the domain’s configuration?
The serial numbers change without them changing on the primary name servers. I don’t see how the deSEC servers would even be aware how they are used.
That’s kind of the problem, because there is no mechanism that lets you tell the Desec servers that they are meant to be secondaries (and the provider* of this service apparently thinks that’s not how Desec is intended to be used). You can’t configure Desec servers to act as primaries to external secondaries either, so they behave as the only servers, and that means they can change the serial at any time without giving notice to anyone. That means you can’t reliably configure your server to be a secondary, and neither can your server be a primary to a Desec server that doesn’t want to be secondary.
the deSEC forum does not tolerate violations of its code of conduct. Personal attacks are such a violation. I’m asking everyone to reconsider their involvement in this thread, reread their own messages and adjust their tone if needed. Thanks you all for keeping the forum a welcoming place for technical discussions with relation to deSEC’s services.
I’m deleting sections of this discussion that are in violation of the code of conduct.
The serial numbers are used to synchronize DNS data across the various deSEC DNS servers. Because both ns1 and ns2 are collections of servers it is entirely possible that different users talk to different physical machines at the same point in time, even if both use the “ns1” label. If these two servers have different versions of the DNS data, the two users may receive different responses to the same question.
Updates are caused by deSEC users making changes to their data and by deSEC doing regular DNSSEC chores. This usually involves an update once a week but deSEC doesn’t guarantee any particular interval. The chores are an integral part of DNSSEC, which is part of deSEC’s mission and thus non-negotiable.
The only guarantee that deSEC gives is that the serial numbers are monotonically increase and that the server state after each update is eventually consistent. We are working to finish updating the servers globally by 3s after the change, but are currently facing difficulties and are more in the 300s region
To answer the question, no there is no way deSEC allows influencing the serial numbers (except that an update will trigger a monotonic increase that will be eventually consistent across all name servers).
It may help to wait a little and then retry with ISNIC once deSEC distributed the last update. Chores usually happen Thursdays 00:00hrs UTC and take a few hours.
If trouble with ISNIC resurface regularly, please let deSEC support know, so we can engage with ISNIC directly. I believe there are good arguments to relax the “consistency" requirement with regard to the SOA serial number.
It is because DNSSEC is used to add signatures to our DNS responses, and signatures need to be refreshed periodically (in our case, once a week). Updating signatures is actually a change to the DNS contents of the domain, so the serial increases.
While true, the problem at hand here was that deSEC and non-deSEC servers were in use simultaneously, and serial changes (from DNSSEC resigning) are not synchronized between them.
(In fact, nothing was automatically synchronized, as neither set of name server acted as secondary for the other; instead, this is like a multi-primary setup. Note that this is common; for example, github.com has a similar setup and serials differ. This is not a DNS problem; rather, ISNIC’s policy is not fit for purpose.)
