why setting view with recursion option is invalid in BIND 9.5.0-P1

[Chris Buxton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 9, 2008, at 2:18 PM, Kevin Darcy wrote:
> Chris Buxton wrote:
>> On Sep 8, 2008, at 8:11 PM, Kevin Darcy wrote:
>>> If you are hosting zones to the Internet, then create a separate  
>>> view
>>> for that (call it e.g. "hosting" or "external"), with a "match-
>>> clients {
>>> any; };" and "recursion no", and then place that view *after* the  
>>> one
>>> which has a "match-clients" for your clients' address ranges, and
>>> which
>>> they use for resolution.
>>>
>>
>>
>>
>> It would be simpler, if the BIND version in use is 9.4.1-P1 or later,
>> to not use views at all. Just use allow-recursion, which also implies
>> the behavior of allow-query-cache (assuming the latter is not
>> otherwise set), to control access to the cache.
>>
>> Views should only be used when necessary, and with full understanding
>> of their ups and downs.
>>
>>
> If one is able to convince one's users to use a totally different  
> domain
> (or subdomain) for internal devices, than is visible from the  
> Internet,
> then yes, I suppose one could get away with not using views.

The OP showed a single view matching all requests. I was pointing out  
that views are not terribly useful for that case and simply add  
unneeded complexity to the configuration.

Views definitely have their place, but you have to understand them  
fully or they're just a nuisance.

> But, users being users, chances are one is going to have at least two
> different versions of one's "main" zone (e.g. chrysler.com), i.e. an
> "internal" versus an "external" version, and that requires views,
> separate named instances, or separate boxes. Of the 3 choices there,
> views tend to have the best balance of (hardware-cost) economy and
> maintainability. Running multiple named instances on the same box is
> messy, I did it for years before views existed, and was glad to  
> finally
> get rid of that kludge.

That depends on your security needs. A case can easily be made in  
favor of separate boxes because, in this case, there is no functional  
difference as far as who gets what data. The difference is in paying  
for extra hardware and networking resources, versus having the  
security of knowing that your internal users' malware infections can't  
take down your public presence by overwhelming your name servers.

I've seen a case where views are not simply a substitute for multiple  
boxes. In that case, the only alternative would be some kind of fancy  
NAT setup. Views were by far the best solution to that problem.

Chris Buxton
Professional Services
Men & Mice

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjG644ACgkQ0p/8Jp6Boi04nQCdEgzIKYBpCDbg95eUn7yXL3l1
oyYAnRc3KhTu7gB71h5ELtkc72NWeKKO
=joNK
-----END PGP SIGNATURE-----