[Unbound-users] forward zone vs stub

[Johan Ihrén]

Hi Paul,

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

> 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.

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

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

Umm, well, now I see what you actually wrote, "internal only zone". My assumption (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 exist on the public side (like RFC1918 reverses, if you really need DNSSEC validation 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