[Unbound-users] forward zone vs stub
johani at johani.org
Tue Oct 23 16:49:54 CEST 2012
>>> That is a thought but I should think of it's implications it might have on secondary authoritative servers...
>> As long as you don't go down the rabbit hole of trying to use the same nameserver address for multiple views, with multiple roles, you'll be fine. If you're using the same address, and do src address matching on the queries, and intend to keep it that way... then I'll have to leave you to your current and upcoming pain.
> I still don't get the advantages on using different IPs on the authoritative NS server instead of src matching.
> So far it has served as well. If you could point to some documentation with complete setup and advantages I would be happy to read and see the whole picture.
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.
But now I really must get back to what I really should be doing today.
More information about the Unbound-users