[Unbound-users] forward zone vs stub

[Johan Ihrén]

Hi,

On Oct 23, 2012, at 12:59 , Kapetanakis Giannis wrote:

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

You didn't answer the question of which matching rules you're using for your views. So, not trying to be overly picky here, but when someone tries to help you and to be able to do that asks specific questions about your setup then you really should try to answer those questions, because otherwise... I cannot help.

> The unbound is on the internal view so it queries for zone.priv.

So my guess here is that you're matching on the src address. Don't Do That(tm). If you have to use views (you don't) then match on destination, i.e. regard your servers as multiple distinct nameservers with individual addresses collapsed into a single box. Then it becomes quite obvious that you should use distinct IP addresses for the nameserver for the internal view and the nameserver for the external view.

> The external authoritative NS records are on both files. You're suggesting I should alter .priv zones to list only
> internal DNS servers?

No, I'm suggesting that you should alter the internal zone to only list servers that are authoritative for the internal zone. The internal and external versions of the zone are distinct, but they must each be internally consistent otherwise you'll break DNS coherency.

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

Regards,

Johan