Forward First on Master Zone (bypass SOA)

[Lawrence K. Chen, P.Eng.]

----- 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.)

Though there were some issues the stub, that were helped by upgrading to bind 9.9.... wildcards and DNSSEC :)

Fortunately, I don't have to support dynamic zones on the central server....its a delegated subdomain.

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkchen at ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library