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
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
