[Unbound-users] forward zone vs stub

[Kapetanakis Giannis]

On 23/10/12 17:49, Johan Ihrén wrote:
> Let me put it this way:
>
> One of your users complain that a nameserver is giving out the wrong response. Which nameserver and what query you ask. The user says "the nameserver at [wherever] responds wrongly when I query it for [qname] [qtype]. Now what do you do? Well, you do this:
>
> dig @[wherever] [qname] [qtype]
>
> Everything is fine, right? Except that if you do source matching then this nameserver may treat you and the user differently so you will never see the problem unless the user actually reports it.
>
> Now replace the user with an expensive box that doesn't complain (or a user that doesn't complain for that matter). I.e. the only way to KNOW how the nameserver behaves is to put on your roller-blades, skate over to the next building where the user is, unplug his machine, plug in your laptop and test using HIS IP address. That's not convenient for debugging and it is completely impossible to monitor.
>
> On the Internet it is possible to do so-called "source routing". For some reason that's not much in favour. The entire Internet works on routing based on where the packet is going, not from where it is coming. Same problem, at the bottom.
>
> Here's the five cent summary of what I think you should do with your setup and your problems. I may have misunderstood a detail or two but I think this ought to work much better:
>
> 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.
>
> But now I really must get back to what I really should be doing today.
>
> Regards,
>
> Johan

Thanks for your help. I will really think about the setup you 're proposing.

thanks again for your time.

Giannis