DNSSEC, views & trusted keys...

[Timothe Litt]

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.buxton at gmail.com] 
Sent: Saturday, September 11, 2010 22:41
To: Phil Mayers
Cc: bind-users at 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