I'll first say that what I'm doing now seems to work, though I'm unclear on whether it's correct. I have a domain registrar company (inherited from a contract) and a name server company, separate because the latter supports some features we need that the former doesn't. There are six domain names, only one of which is "main"; and the name server supports ALIAS (a workaround for the well-known no-CNAME-at-apex issue). All six domains at the registrar look like this:
SOA @ ns1.myregistrar.net [...]
NS @ ns1.mynameserver.net
NS @ ns2.mynameserver.net
NS @ ns3.mynameserver.net
NS @ ns4.mynameserver.net
NS @ ns5.mynameserver.net
At the nameserver, five domains use ALIAS, and the sixth (main) one looks like:
SOA @ ns1.mynameserver.net [...]
NS @ ns1.mynameserver.net
NS @ ns2.mynameserver.net
NS @ ns3.mynameserver.net
NS @ ns4.mynameserver.net
NS @ ns5.mynameserver.net
A @ [...]
AAAA @ [...]
Name resolution works for both IPv4 and IPv6; CNAME resolution to a subdomain works; ALIASing of the five secondary domains works. I have other questions based on my still-limited understanding of DNS delegation.
- Should the SOA set at the registrar be changed to equal that of the nameserver?
- Why is it that the registrar allows for the SOA to be manually edited, but the nameserver doesn't? Put another way, under what scenario would it be useful to manually edit a SOA?
The only DNS records which have any effect are those served by your nameservers, as specified at your registrar and appearing in your domain's whois record. Some other nameserver can say whatever it wants, but nobody is actually going to query it, because it isn't an authoritative nameserver for your domain.
As for editing the SOA, all fields in the SOA are editable, but a decent DNS provider will manage the serial itself and give you a nice UI to edit the rest of them.