Running a Hidden Primary

Categories: Secondary DNS

This article discusses using Secondary DNS with a hidden primary DNS server (sometimes referred to as blind secondary DNS). Yes, Secondary DNS will support this, but there are some specific pitfalls to avoid which we'll discuss in this article.

What is a Hidden Primary?

A hidden primary is nothing more than a primary/master name server which is not listed in the delegation for the domain and which is not listed in the NS records in the zone file for the domain.

You may want to do this because your primary/master server is located behind a slow or unreliable link (DSL with a static IP address for instance). Or, the primary/master server may be on a network which has strict access controls.

In any event, a hidden primary is used in those cases where you don't generally want DNS traffic to go to your server.

The NS Records and Delegation

When setting up a zone to use our Secondary DNS service with a hidden primary, delegate the domain to

ns2.mydyndns.org
ns3.mydyndns.org
ns4.mydyndns.org
ns5.mydyndns.org

and list all four of these servers in your zone file as NS records:

example.com.
21600
IN
NS
ns2.mydyndns.org.
example.com.
21600
IN
NS
ns3.mydyndns.org.
example.com.
21600
IN
NS
ns4.mydyndns.org.
example.com.
21600
IN
NS
ns5.mydyndns.org.

The SOA Record

This is where many problems occur. Customers will often enter ns2.mydyndns.org as the MNAME in their SOA, generating an SOA like this:

------------------------------ Wrong Way -------------------------------
example.com.
IN
SOA
ns2.mydyndns.org. zone-admin.example.com. (
2004040169 ; serial number
14400
; refresh
1800
; update retry
604800
; expiry
1800
; minimum
)
------------------------------------------------------------------------

This is done in an effort to hide the primary/master server entirely, but doing this causes a problem. BIND (and other DNS servers that behave similarly) use the MNAME value when determining which servers to send NOTIFY events to. When BIND loads a zone file and determines that it has been modified, it builds a list of servers from the NS records EXCLUDING the server in the MNAME value and sends NOTIFY events to those servers.

So, if you put ns2.mydyndns.org in the MNAME field this will prevent the NOTIFY events from being sent to ns2.mydyndns.org. ns2.mydyndns.org will eventually get the new zone file, but the timing will be determined by the REFRESH TTL value and you will lose the benefit of having this controlled on your end by the NOTIFY event.

So, your SOA records should instead contain the hostname of your primary/master server in the MNAME field like this:

------------------------------ Right Way -------------------------------
example.com.
IN
SOA ns.example.com. zone-admin.example.com. (
2004040169 ; serial number
14400
; refresh
1800
; update retry
604800
; expiry
1800
; minimum
)
------------------------------------------------------------------------

Note that the MNAME field is NOT used by resolvers to determine where to send queries, and listing this in the MNAME value will not cause DNS traffic to go to your primary/master server.

Using Explicit Notifies

At this point you may be saying "But, I want to completely hide my primary/master server because I don't want anybody to know where it is."

If you insist on listing ns2.mydyndns.org in the MNAME field, you should use the explicit notify syntax in your named.conf file to specify the servers to send NOTIFY events to.

However, we really do not recommend doing this and we can not be responsible for problems that might arise out from using an invalid value in the MNAME field of the SOA.