slave on per-zone basis only?

[WebReactor Networks]

Matt:  Is SteveP correct in his interpretation of your question?

SteveP:  To answer your question, no, you need to add each zone to named.conf on both primary and secondaries, like Barry says...

...so here's what you can do to get around that.  It's not pretty, but it will work under *most* circumstances, and it is the basis for the WebReactor Networks DDNS service.  I expect lots of flame for this, but here goes.

Let us assume that you will be adding zones which reside under multiple TLDs (com, net, org, uk, cz, etc.).  Make your master and slave servers root name servers.  

  // Master named.conf 
  zone "." {
    type master; 
    file "db.root";
  };

  // Slave named.conf 
  zone "." {
    type slave; 
    file "db.root"; 
    masters port 53 { 1.2.3.4; };
  };
  
Your db.root can contain records for "www.this.domain.tld" and "mail.that.domain.tld", or you can break them up with $INCLUDEs. 

It is probably more practical to break up zones by TLD, having one for "com", one for "net", etc.  Normally a server has a very limited number of TLDs under which its zones reside.  They can still be subdivided with $INCLUDEs.

Now, having said that, what negative side effects can be expected from a configuration like this?  It has been working well for almost a year now, and the only complaint I've received was that the registrar for Switzerland (.ch) and Liechtenstein (.li) requires SOA records for a domain before they will register it.

  - John R. S.  


-------- Original Message --------
Subject: Re: slave on per-zone basis only?
Date: Thu, 21 Feb 2002 21:57:55 GMT
From: Barry Margolin <barmar at genuity.net>
To: comp-protocols-dns-bind at isc.org

No, there's no built-in mechanism that will cause a slave to automatically load all the zones that some other server is master for.
<snip>

-------- Original Message --------
Subject: Re: slave on per-zone basis only?
Date: Thu, 21 Feb 2002 09:58:48 -0500
From: "Biff" <sperraul at nospam.mnsi.net>
To: comp-protocols-dns-bind at isc.org

What I think the original poster was trying to ask, (I hope he was asking,
as I'd like to know) is can you have a secondary DNS server and not have to
edit the domains as often as the primary.  So, if you were to update the
primary, the secondary would automagickally update without requiring ftp,
rsync, or scripts.

- SteveP


"Kevin Darcy" <kcd at daimlerchrysler.com> wrote in message
news:a514dc$lhj at pub3.rc.vix.com...
>
> WebReactor Networks wrote:
>
> > Matt asked:
> > >I have a general question about the configuration of
> > >slave nameservers.  Does a slave have to have an entry
> > >for every zone that a master serves?
> >
> > Danny replied:
> > >No.
> >
> > Sorry... in my earlier post I made the assumption that by "slave" you
meant "a slave for all zones served by the master", based on the context of
your question.  Danny is correct.
> >
> > Matt asked:
> > >Does an entry such as this need to added for *every* domain
> > >that this server is a slave for?
> >
> > Danny replied:
> > > No.  A slave zone only needs to be set up for those domains
> > > that have been delegated to it
> >
> > On the contrary, a server can be a slave for any zone.  I can set up a
slave server for the zone "ibm.com" if they haven't secured their zone
transfers
>
> Hence the term "stealth slave".
>
> > I have used this method on internal networks when I want to avoid
traversing a WAN link for every query, but don't require quick updates via
NOTIFY.
>
> You can have NOTIFY for stealth slaves, if you want. That's what
"also-notify" is for.
>
> Note that the decision of whether to be a stealth slave or a
caching/forwarding/stub'ing server, for any given zone, can be a complex
one. You have to take into consideration your query patterns, the speed at
which you want changes to the zone to propagate, how big the zone is, how
often it changes, whether IXFR is in use, etc. to get the best tradeoff
between redundancy,
> immediacy, query performance and resource usage (the resources of both the
network and the servers involved should be taken into account).
>
>                                                                           
                                              - Kevin