DNSSEC, views & trusted keys...
Timothe Litt
litt at acm.org
Tue Sep 14 20:28:24 UTC 2010
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
More information about the bind-users
mailing list