On 23/10/12 13:47, Johan Ihrén wrote:
You're right about the views. The views are on BIND (authoritative) and have
different data for external clients.
What I really want is my internal users to use unbound servers with the
following options:
a) unbound should forward all requests for local zones (*.example.com,
123.123.x.x, 10.x.x.x) to local authoritative servers (BIND)
Yes, I get that. However, I'd strongly advise that you don't call that to "forward". "Forwarding"
is something you implement with "forward-zone:", which is distinctly different from what you do with a
"stub-zone:". Forwarding by definition is one recursive server forwarding a query to another recursive
server. That's not what's happening when you're using stub-zone:, which is basically pre-loading the cache with static
entries for the nameservers of a particular zone.
Yes I've already read in the manual that stub-zone is really what I want
and that's why I've setup stub-zones and not forward-zones. It does it
for the zones but not for the sub-zones. Should I list every
zone/sub-zone or is there a trick?
b) the local zones should not be cached on the unbound because I want the
updates to be automatically propagated.
This is yet another requirement. However, let's ignore that for the moment, as
that's orthogonal to the issue of your stubs.
In another similar setup (but with bind only) the the caching server is also
secondary for each zone, but is not listed in the NS records.
Yeah, I know that's a popular party trick, but let's not go there as this is
the Unbound-list.
However, you never answered my question: Which zone file is it that contains
"external authoritative DNS servers as well"?
Regards,
Johan
The authoritative server keeps two files for most of the zones.
On each view they load different file with different entries (zone.pub,
zone.priv)
The unbound is on the internal view so it queries for zone.priv.
The external authoritative NS records are on both files. You're
suggesting I should alter .priv zones to list only
internal DNS servers? That is a thought but I should think of it's
implications it might have on secondary authoritative servers...
G
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
