Best implementation of many zonfiles containing the same info (to avoid duplicate IP-nr)

[Kevin Darcy]

Paul Colquhoun wrote:
> On 8 Sep 2006 08:45:09 -0700, news at teknologia.com <news at teknologia.com> wrote:
> | $INCLUDE seems to work but if the IP-nr change you still need to change
> | the serial number in each zone-file and restart bind to get it to work.
> |
> |
> | I know you can script such things but it would be so pleasant if the
> | only thing you need to do was to change the IP-nr in one single place.
> | CNAME would do it but is impossible to use.
> |
> | Other suggestions?
>
>
> When you write the 'zone' config section for each domain in the config
> file, point to the same file for each domain, like this:
>
>
> zone "domain-1.com" IN {
>         type master;
> 	file "data/common.zone";
> };
>
> zone "domain-2.com" IN {
>         type master;
> 	file "data/common.zone";
> };
>
>
> Make sure you use the '@' symbol in the data/common.zone file, and rely
> on the domain auto-complete feature (i.e. leave the domain off the end
> of any references, and don't use a trailing '.' character).
>
> All the domains will have identical SOA data, as well as identical
> hostnames, IP addresses, etc.
>   
You know what would be really neat? If the $INCLUDE directive honored 
"@" syntax. So, you could have a zone file with

$INCLUDE @

at the bottom, reference this same zone file from multiple zone 
definitions in named.conf, and then each of the include files could 
"customize" the zone data on a per-zone basis by adding additional 
records beyond the "core" (in cases where no customization is required, 
the include file could be zero-length). The core zone file could be 
called "core", and then all of the per-zone include files would be named 
after the zone, e.g. a "foo.com" include file for the foo.com zone, a 
"bar.com" include file for the bar.com zone, and so forth.

This feature would appear to violate no standards since all that RFC 
1035 says about "@" is "A free standing @ is used to denote the current 
origin", without limiting the context of that substitution to Resource 
Records. And of course the precedent of allowing @-substitution in 
directives is already established, since the $ORIGIN directive allows 
it. Seems like this feature wouldn't be that hard to program into the 
zonefile parser either. Maybe I'll take a shot at it...

                                                                         
            - Kevin