Just started with deSEC and created a domain via API and now discovered that the SOA record is wrong Sample respond with drill:
desec.io. 60 IN SOA set.an.example. get.desec.io. 2020044840 10800 3600 604800 60
desec.org. 45 IN SOA set.an.example. get.desec.io. 2020035327 10800 3600 604800 60
How can I correct this record now?
thanks in advance
Thank you for your message, and welcome to deSEC!
What’s wrong about the SOA record?
The mname points normally to the primary name server and the rname to a email (hostmaster) of the domain owner.
Or am I wrong?
It is true that the
mname is supposed to be “the name server that was the original or primary source” of data for this zone" (RFC 1035). However, the
mname host needs not to be publicly accessible (think of hidden master setups, which is in fact what we use). Also, Internet participants are not going to care about the
There may replication systems that rely on
mname, but ours doesn’t. There also may be an edge case in case we implement RFC 2136 dynamic updates; the RFC admits though that the
mname host could or could not be reachable, and update clients can equally well contact any of the
It would be meaningless to put our hidden master’s hostname, and it would be arbitrary to prefer any one of our
NS hosts in the
mname. We wanted to put a value that is guaranteed to have no side effects, and given the considerable degree of freedom arising from the fact that
mname is practically irrelevant, we figured it’s time for an easteregg! So, set an example, and get desec.io!
rname value actually corresponds to an email address that is forwarded to our support mailbox.
Considering everything, we think our
SOA fields are perfectly compliant, but they read much nicer than what other providers tend to put there.
OK, nice try with the egg, but for different zone tests, for example Zonemaster, this is not fully compliant.
According RFC 2606 is “.example” a reserved top-level domain.
From my humble point of view, it would be more trusting if no jokes were made here.
SOA ‘mname’ nameserver (set.an.example) is not listed in “parent” NS records for tested zone (ns1.desec.io; ns2.desec.org).
… and declares this as a warning, not an error. Warnings may indicate a misconfiguration, but do not necessarily indicate a real misconfiguration. For such cases, Zonemaster has the error category.
Let me quote RFC 2136, Section 1:
The primary master is named in the zone’s SOA MNAME field and optionally by an NS RR.
Thus, this setup is perfectly compliant.
Exactly, and that’s why our choice will not interfere with anyone else’s application. It’s a very safe choice
We run our service so that is is compliant, free of side effects, and covers all use cases. We’re happy to revisit our decision if there is any evidence of it being in conflict with these goals. Anything else, I fear, is dogmatic.
OK, I agree so far and I’ll contact you if something doesn’t work.
many of those checkertools, such as mxtoolbox DOT com are not exactly happy with “set.an.example” and seem to lack the sense of humor required these days.
I wonder, though, how in fact this is supposed to be called an “easter egg” as it sticks out like a sore thumb from any checker-tool report such as mxtools. Aren’t easter eggs meant to be kinda hard to find?