[prev in list] [next in list] [prev in thread] [next in thread] 

List:       unbound-users
Subject:    Re: [Unbound-users] forward zone vs stub
From:       Johan_Ihrén <johani () johani ! org>
Date:       2012-10-23 15:31:20
Message-ID: 8FECDFB4-322D-482B-B830-B292A3CB4F42 () johani ! org
[Download RAW message or body]

Hi Paul,

On Oct 23, 2012, at 17:07 , Paul Wouters wrote:

> On Tue, 23 Oct 2012, Johan Ihr=E9n wrote:
> =

> I agree with the below story line.....
> =

>> 1. Drop all your views. That's mostly a vendor lock-in that you don't ne=
ed these days.
>> =

>> 2. Run separate auth nameservers for the internal and external versions =
of the zone. Whether that's separate physical boxes or if you're just repla=
cing the views with separate virtual machines is up to you.
>> =

>> 3. Use "stub-zone:" to direct your recursive server to the internal vers=
ion of the zone (you're already doing this).
>> =

>> 4. [If needed] Use "forward-zone:" to arrange forwarding to the outside =
if your firewall requires that.
>> =

>> 5. If or when you do DNSSEC, use the same keys for both internal and ext=
ernal version of zone, and do validation in the recursive server; both vers=
ions of the zone will validate nicely, to the benefit of both external and =
internal users of your data.
>> =

>> Done.
> =

> You forgot to add that you need to load the trust anchor for the internal=
 only
> zone loaded on the internal resolvers. This is assuming the internal
> zone is not visible in the external view. I guess if you leave an empty
> "internal" zone out in public, (with NS and DS) then you could
> potentially skip this part, but I have never tested that.

No, that's not needed. As long as you use the SAME keys (as I said) when si=
gning the internal and the external zones the signature chain from the publ=
ic root, via the DS in the external parent, to the internal signed zone (th=
at you find through the stub-zone: declaration) will work just fine. I've u=
sed that for years (after Wouter long ago fixed a bug for me to make it wor=
k).

You only need the trust anchor for root, nothing else, for validation of th=
e internal version of "example.com".

Umm, well, now I see what you actually wrote, "internal only zone". My assu=
mption (based on his example) was that the zones exist in a public version =
and an internal version, i.e. "example.com" does exist on the public side (=
as well as the internal side), and does have a DS. For zones that do not ex=
ist on the public side (like RFC1918 reverses, if you really need DNSSEC va=
lidation for them) your point is correct.

>> But now I really must get back to what I really should be doing today.
> =

> So say we all :)

And we all fail ;-)

Johan


_______________________________________________
Unbound-users mailing list
Unbound-users@unbound.net
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
[prev in list] [next in list] [prev in thread] [next in thread]