What happens if I do not set my real primary DNS as SOA entry in a Hidden Primary setup?

Question

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?

Answer 1

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       192.0.2.10
ns2     IN      A       198.51.100.20
ns3     IN      A       203.0.113.30

• Hidden master not listed in the zone.

  • This server is only on a private network, having IP address 172.16.10.40.
  • 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 { 172.16.10.20; };
        notify explicit;
        also-notify { 172.16.10.20; };
    };     
    

  • 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 192.0.2.10 and private 172.16.10.20.

  • 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 { 172.16.10.40; };
        allow-transfer { 198.51.100.20; 203.0.113.30; };
        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 { 192.0.2.10; };
    };