Forward First on Master Zone (bypass SOA)

[Kevin Darcy]

On 3/29/2013 6:12 PM, Lawrence K. Chen, P.Eng. wrote:
> ----- Original Message -----
>> On Mar 28, 2013, at 12:28 PM, Ben-Eliezer, Tal (ITS) wrote:
>>
>>> I’ve spent hours researching a way to accomplish this without any
>>> luck. Is there any way to accomplish what I’m trying to do?
>> No, not unless you want to monkey around with static zones and
>> $INCLUDE directives -- something like this:
>>
>> Internal zone file:
>>
>> $INCLUDE internal.zone.apex
>> $INCLUDE example.com.common-records
>> $TTL 86400
>> some.internal.host	A	192.0.2.1
>> [...]
>>
>> External zone file:
>>
>> $INCLUDE external.zone.apex
>> $INCLUDE example.com.common-records
>> $TTL 86400
>> some.external.host	A	192.0.2.254
>> [...]
>>
>> where the *.zone.apex files look something like this:
>>
>> $TTL 86400
>> @	SOA	[... 7 data fields ...]
>> 	NS	ns1.example.com.
>> 	NS	ns2.example.com.
>> 	MX	10 mx1.example.com.
>>
>> This way, you mostly maintain 3 files of DNS records for the zone --
>> external, internal, and common. Note that this is not compatible
>> with dynamic zones.
>>
>> If you need to support dynamic zones (and who doesn't, these days?),
>> you're out of luck.
>>
>> Chris Buxton
>> BlueCat Networks
> I/we maintain a 'single' zone file (with help of subversion/cfengine) which is then processed into 4 different zone files through a Makefile on my master nameserver.
>
> Basically, the as-is zone file is the external view state.
>
> All the internal (campus) view lines/$includes are prefixed with:
>
> ;CAMPUS;
>
> where sed removes those comments to generate the 'campus' view zone file.
>
> There there are lines that will have different comments after the line.
>
> one is ;GUEST_NETWORK and another is ;DISASTER_RECOVERY
>
> sed script will replace the IP part of ;GUEST_NETWORK with the IP of a static page informing the user that the resource is available from the guest network. (this is for services where we couldn't have the service owner to do this within their application.)  And, ;DISASTER_RECOVERY replaces the IP with the IP of the server at our DR site.  With the intent that the result is sent by alternate means to our off-campus secondaries, where they can switch to using this file....etc.  Due to DNSSEC, we have to generate a DR version of our zone file (instead of have secondary edit the transfer file and present that.)
>
> These are also based off the external view (since internal services aren't exposed to the guest network, and DR is an alternate external).
>
> All the different zone files are signed using dnssec-signzone with the '-N unixtime' option....to avoid serial number issues. (especially now that I'm not the only one handling dns requests....)
>
> Before split-DNS, we had created our own TLD ... but the problem with that was we couldn't buy SSL certificates for these services, and there was no interest in having our users to accept self-signed certs or to add a private CA to everything....  so the TLD became a subdomain that was only in the internal view (originally)...though later added a stub in the external view to publish an MX record so that users/apps sending mail without setting a correct from address would still work. (sure I've told people they need to do this lots of times...but then an important app was upgraded and the setting lost....but it needed to work anyways.)
Not to start a religious war, but is all of this really simpler than 
basing your maintenance systems around Dynamic Update? Dynamic Update 
could also be used to do your DR switchover, if you don't already have 
dedicated load-balancer devices performing that function.

         - Kevin