Invalid SOA record

Hello

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

1 Like

Hi Matthias,

Thank you for your message, and welcome to deSEC! :slight_smile:

What’s wrong about the SOA record?

Stay secure,
Peter

Hallo Peter

The mname points normally to the primary name server and the rname to a email (hostmaster) of the domain owner.

Or am I wrong?

Hi Matthias,

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 mname value.

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 NS hosts.

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!

The 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.

Stay secure,
Peter

Hallo Peter

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.

Regards
Matthias

Hi Matthias,

Zonemaster says:

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 :slight_smile:

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.

Stay secure,
Peter

OK, I agree so far and I’ll contact you if something doesn’t work. :wink:

1 Like

https://www.digwebinterface.com/?hostnames=desec.io&type=SOA&showcommand=on&colorize=on&stats=on&onlyfirst=on&location=on&dnssec=on&useresolver=1.1.1.1&ns=auth&nameservers=ns103.cloudns.net.

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?