MNAME in External Zone Files

[Kevin Darcy]

Merton Campbell Crockett wrote:

>At work, a split-DNS is used.  I have three name servers defined in  
>the roots that will answer DNS queries originating from the  
>Internet.  Two of the name servers are in network enclaves behind a  
>Sidewinder G2 firewall.   The Sidewinder G2 has a DNS proxy that  
>forwards DNS requests originating from the Internet to the name  
>server in the network enclave.
>
>It appears that a bug in the DNS proxy that was fixed in an earlier  
>version of the Sidewinder G2 has been re-introduced.  The Sidewinder  
>G2 will stop accepting DNS requests sent using UDP.  On one of the  
>name servers, the trigger event for this denial of service was   
>identified as remote systems attempting dynamic DNS updates using a  
>list of valid, internal system names.  All of the system names belong  
>to Windows-based systems.
>
>Windows systems that have been configured to be in an Active  
>Directory domain will, at boot, attempt to register their current IP  
>address.  If none of the cached Active Directory domain controllers  
>can be reached, they query for the domain's SOA record and attempt to  
>perform dynamic DNS updates to the MNAME system.
>
>Since the mid-eighties, I've always set MNAME to the name assigned to  
>the primary master name server for the domain.  I am curious what  
>others use for MNAME in a split-DNS environment.
>
>Due to the problems encountered with the Sidewinder G2, I am  
>contemplating replacing MNAME with the domain name of the internal  
>primary master name server.  This would side-step the denial of  
>service problem as there is no policies that allow forwarding of DNS  
>queries to the internal system and all DNS requests to the system  
>will be discarded.
>
>Are there any "gotchas" in this approach?
>
The two main uses for SOA.MNAME are for a) NOTIFY, b) Dynamic Update. 
But even in those two cases, the SOA.MNAME only comes into play in the 
*default* behavior. The default NOTIFY behavior can be overridden using 
"also-notify"/"notify explicit", and the default Dynamic Update behavior 
can be overridden using nsupdate's "server" directive, or the equivalent 
mechanism in other Dynamic Update clients. Given the ability to override 
default behavior, ultimately it shouldn't matter that much what the 
SOA.MNAME is set to. We arbitrarily set it to match one of the names to 
which we typically delegate our domains, but that's not the real master, 
the real master is "hidden", so the SOA.MNAME is a fib...

- Kevin