[Unbound-users] forward zone vs stub

[Paul Wouters]

On Tue, 23 Oct 2012, Johan Ihrén wrote:


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

> 1. Drop all your views. That's mostly a vendor lock-in that you don't need 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 replacing the views with separate virtual machines is up to you.
>
> 3. Use "stub-zone:" to direct your recursive server to the internal version 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 external version of zone, and do validation in the recursive server; both versions 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.

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

So say we all :)

Paul