I want to setup a Hidden Primary DNS server, i.e. I host the zone files on my own server, but all requests should go to Secondary DNS servers hosted by a dedicated DNS company. My own DNS server should not be used by recursive resolvers or end users. Said company will copy the zone files with a zone-transfer from my server. Ideally, nobody should even know that my server exists in this DNS setup.

Of course all NS records in such a setup will point to the nameservers of the DNS company. But I am unsure about the SOA record.

According to my understanding this setup would mean that my server is the "start of authority" and thus I would have to specify it in SOA - which would make it public knowledge that my server is the real primary server. According to another answer on serverfault MNAME has to be set to "the <domain-name> of the name server that was the original or primary source of data for this zone."

If it's possible without much trouble, I would prefer not to list my NS server in SOA and instead point SOA to my nameserver hosting company.

What are the consequences if I actually set company.example.com as SOA instead of my own server myserver.example.org?

  • Will I violate the RFC?
  • Will some parts of the DNS system not work anymore? (I read that the entry of SOA is used for dynamic updates, but I do neither plan to accept dynamic updates from foreign people nor do I plan to send them myself)
  • Will my nameserver hosting company come to me, because I wrongly specify their email address as contact for the primary DNS? (mail address field of SOA)
  • Can I maybe mix different hostname and mail address in SOA to solve some issues? E.g. point to company.example.com as SOA server, but to myprivatemail@example.org for mail contact?
  • The SOA record is mostly only for maintenance and basically has little use outside of the maintainer of the zone, if any (except for the negative TTL). The RNAME is long useless now, and the MNAME is mostly there just because some OS sends dynamic updates there even if it shouldn't. See fr. as an example. The SOA lists a nameserver that is not resolvable nor reachable by the public (but is in fact the real hidden primary). – Patrick Mevzek Jun 1 '20 at 0:31
  • "I read that the entry of SOA is used for dynamic updates" Yes, theoretically clients are expected to send their DNS update packets to the server listed in the MNAME (if sent to secondaries they are expected to forward the message to the primary). Even if you do not intend yourself to use dynamic updates you can not forbid some people, volountary or not, to happen to send messages there. You should just need to make sure to handle those properly. – Patrick Mevzek Jun 1 '20 at 0:32

Using outsourced name servers (from other domain) isn't a violation of DNS standard, but that doesn't sound like a hidden primary configuration. The NS given as a primary in SOA should be within the NS records, but it doesn't really mean the servers must be configured so that the primary server introduced to the world is the actual orginal source of the data.

It could e.g. be that you don't want to expose the primary server having your private DNSSEC keys to the world. That's especially useful if the publicly announced primary server has other functions that may be easier to compromise, like some web applications.

Let's take an example. Configurations are assuming BIND.

$ORIGIN example.com.
@       IN      SOA     ns1.example.com. hostmaster.example.com. (
                        2020053100 ; serial
                        7200       ; refresh (2 hours)
                        3600       ; retry (1 hour)
                        604800     ; expire (1 week)
                        86400      ; minimum (1 day)
@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.
@       IN      NS      ns3.example.com.

ns1     IN      A
ns2     IN      A
ns3     IN      A

Diagram of DNS server locations and interactions

  • Hidden master not listed in the zone.

    • This server is only on a private network, having IP address
    • This server does the DNSSSEC signing, therefore I've used example.com.signed.
    • It's configured as the master for example.com, allowing zone transfers from the public primary, but only using the LAN (or it could also be a VPN).

      zone "example.com" {
          type master; 
          file "/etc/bind/db/example.com.signed";
          allow-transfer {; };
          notify explicit;
          also-notify {; };
    • The notify is configured manually using notify explicit & also-notify, because notify yes would only notify the servers listed as NS except the one listed as primary in the SOA. That simply wouldn't work out-of-the-box.

  • Public primary server ns1.example.com

    • This server has two IP addresses: public and private
    • It's configured as a slave for the zone, and allows zone transfers from the other NS:

      zone "example.com" { 
          type slave; 
          file "/etc/bind/db/example.com"; 
          masters {; };
          allow-transfer {;; };
          notify yes;
  • Public secondary servers ns2.example.com & ns3.example.com.

    • In this example, these servers are completely elsewhere providing both the required network diversity and geological redundancy.

    • These servers performs zone transfers from the public primary.

      zone "example.com" { 
          type slave; 
          file "/etc/bind/db/example.com"; 
          masters {; };
  • "The NS given as a primary in SOA should be within the NS records," This is really not often the case or at least not always. See the configuration of the fr. TLD for one example. Since the SOA is just for nameserver maintenance, and that the NS RRset is the only things needed to put the delegation into existance and make it work, noone should bother about what is in the SOA record. – Patrick Mevzek Jun 1 '20 at 0:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.