Puzzling scenario involving views

[Kevin Darcy]

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