Re: Puzzling scenario involving views

Peter Rabbitson wrote:

>Hello list,
>I have a bind9 serving the domain example.com, with a secondary backup dns
>(secondary.com) at a remote location. I wanted to achieve redundancy of
>both domains provided to each other (example.com has secondary.com as
>2nd NS, and vice versa), and at the same time I wanted to define internal
>and external views in example.com for internal network naming purposes. I
>got it working fairly quick with the example below, however here is my
>problem: members of the insiders acl would not receive an AA answer when
>inquiring about secondary.com.
>
Is this important? I have yet to find an application that cares about
the setting of the AA bit.

> I was thinking that views are not terminating
>and "insiders" would see both the internal and external view at the same
>time.
>
No, that doesn't make any sense. What if a zone is defined in multiple
views but the zone data is different? Which view would "win" in that
scenario? The best way to conceptualize views, I think, is a bunch of
"virtual" nameservers, with a somewhat simplistic "traffic cop" or
dispatcher logic in front of all of them, to decide which client gets
which "virtual" nameserver. Once the dispatch has been made, you can't
go back to the dispatcher and ask for a second opinion on a particular
name. So there's no such thing as a name or a zone being "in" multiple
views at the same time, as far as any given client is concerned. At
least, not as views are currently implemented...

>If however this is not the case - how do I place secondary.com in
>both views without breaking AXFRs?
>
The simple approach is to define the zone as slave in both views. I
think you'd be safest to define those with different file names, since
I'm not sure that BIND 9 would recognize the same file in different
views, so there would be a possibility of corruption if multiple zone
transfers wrote to the file at the same time.

If you don't want to waste the WAN bandwidth of doubling your
zone-transfer traffic, and you have a spare physical interface on the
box, or don't mind configuring a virtual interface, then you could have
one of the views slave from the other using query-source,
transfer-source, notify-source, also-notify/notify explicit and so forth...

>Can I specify a slave zone reference to
>the same zone file and then explicitly allow-notify { none; }; in the
>internal slave zone statement?
>
See above. I think you'd risk corruption if you did that. What would
multiple references to the same file buy you anyway? It wouldn't reduce
your WAN bandwidth consumption, since each view would have to make the
same number of zone transfers regardless. Are you thinking that named
checks the contents of the slave file prior to each refresh check? Why
would it? It expects to be the only thing modifying the file. Perhaps it
could be a feature request for BIND 9 to recognize multiple references
to the same slave file in different views and, minimally, perform the
necessary locking to prevent corruption of the file, or, optimally,
short-circuit the normal serial-check/zone-transfer process, when
possible, in that special case (instead, it would just copy the zone
data internally from the most recently-updated view to the other(s)
whenever an actual physical zone transfer is performed)...

- Kevin