Make aliases that don't transfer?

Kevin Darcy kcd at daimlerchrysler.com
Mon Apr 2 23:07:58 UTC 2007


Always remember that the use of a single file as the source data for 
multiple zones is a *hack*. named loads that data as separate zones, and 
that's the way they are viewed in protocol terms, including zone 
transfers -- as separate zones. As John Wobus pointed out, if you want 
to treat *files* as *files* instead of *zones*, you could use an 
out-of-band mechanism, such as rsync, to replicate your data. Some 
caveats of doing things that way:
1) If you care about security at all, you'd want to set up a trust 
relationship so that no-one can spoof the data,
2) You might need to open up additional ports in your firewall(s), if any,
3) You'd need some way of getting the "slave" nameservers (defined as 
"master" for the zone(s) in question) to reload/refresh the data 
whenever it changes since, unlike with AXFR/IXFR, this is not automatic.

                                                                         
                           - Kevin

Jeff Lightner wrote:
> We have multiple domains that are aliased to our main domain.   This
> works fine.
> I've noticed on doing zone updates and transfers from master to slave
> that it essentially transfers the alias zone file for EACH aliased
> domain.   This seems unnecessary since the zone file is a single one for
> all these domains so it seems the transfer for the first alias should be
> sufficient.   I was curious how I would insure it only transferred once.
> Is there a type other than "master" or "slave" or should I just take out
> the "allow transfer" line?   I don't want to delete the entry entirely
> from the slave for obvious reasons.
>
> Example from my master:
> zone "4waters.com" {
>         type master;
>         file "watercom-aliases";
>         allow-transfer { watercom; };
> };
>
> >From my slave:
> zone "4waters.com" {
>         type slave;
>         file "watercom-aliases";
>         masters { 10.0.21.21; };
>         allow-transfer { watercom; };
> };
>
>
>
>
>
>   



More information about the bind-users mailing list