This is getting very involved - or I'm getting confused. Maybe both :-) I've tried to work out how this can work, but each solution seems to uncover another question. I don't want to experiment to get to "seems to work", only to find the next problem much later...
There doesn't seem to be much description of stub zones in the ARM. I take it that a stub zone will fetch data from the zone using non- recursive queries, but the view can provide recursive service to queries zones served elsewhere? I gather that they contain just an SOA and NS records. Presumeably This means I have to create a new set of zone files for the master - E.g. grep for SOA and self (but not delegating) NS records. How are these maintained? It wouldn't be too bad if the master stub server would grab SOA & NS changes from the full zone & propogate them to the primary copy of the stub zone. But the full zone is in a different view from the stub... If this is to work, these queries would have to be non-recursive for the match-recursive view selection to support it. Since we know that the server is authoritative for each zone, it would seem that the stub should always have a 'masters' clause that points itself (even if the non-stub zone is in fact a slave). Otherwise there's a good chance that resolving a query would go across the wire to some other server, ignoring the local data. But then update-forwarding won't work, will it? It would be helpful if someone expert in all the interactions could trace out the flows (where starts, goes, how destination/view selected) for: o Initializing the stub zones on the master and their replication to the slaves o Adding or removing a nameserver for the full zone (Specifically, how this propagates to the stub) o A client's recursive query o Dynamic update o Zone notifies/refreshes (full and stub) Sorry if I'm being opaque -- though if we expect DNSSEC to be used, I won't be the only person trying to get this work! --------------------------------------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. -----Original Message----- From: Chris Buxton [mailto:chris.p.bux...@gmail.com] Sent: Saturday, September 11, 2010 22:41 To: Phil Mayers Cc: bind-users@lists.isc.org Subject: Re: DNSSEC, views & trusted keys... On Sep 11, 2010, at 2:34 AM, Phil Mayers wrote: > On 09/10/2010 11:12 PM, Timothe Litt wrote: >> >> So it looks like the new (r-internal) view is starting at the root when it >> resolves -- ignoring what it has data for locally. It sorta works for > > You'll need a: > > zone "name" { > type forward; > forward only; > forwarders { > ips; > }; > }; > > It won't automatically detect that another view contains the zone and redirect it; you have to tell it. Use a stub zone instead of a forward zone, so that the query will actually reach the authoritative view. With a forward zone, the query is recursive, so will be picked up by the recursive view - the view will query itself and not receive an answer. zone "zone.name" { type stub; file "/path/to/recursive-view-data/zone.name"; masters { 127.0.0.1; }; // or whatever the correct IP is to reach the internal view }; Chris Buxton BlueCat Networks _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
