no. of Views and Zones

Kevin Darcy kcd at
Thu Nov 11 00:31:53 UTC 2010

             I think you're mixing up the resolver function with the 
hosting function. With some development and implementation, you can 
offer your customers the ability to set up and maintain their own 
domains on one nameserver instance, and then have another instance set 
up for them to resolve Internet DNS names. It is that "resolving" 
instance for which you may want to set up views, so that you can have 
per-customer "blocking" of domains (although in general this is better 
done in a web proxy than with Stupid DNS Tricks, IMO) but in that case 
the number of "exception" zones would presumably be much smaller than 
the "thousands of domains" you quoted, which would be in the "hosting" 
instance. How many domains would people want to block in this manner?

As for per-customer blocking, I'd suggest having just one "blocking" 
view, with the specific domains that are to be blocked, as empty or 
wildcarded zones, running on a separate interface, and have your 
"blocking-subscribed" customers point to that. If that's not 
fine-grained enough, have a small number of blocking levels -- e.g. 
"none", "loose", "medium", "tight", "supertight" -- running on separate 
interfaces, and your customers can choose between them. If they want to 
pick and choose domain-blocks individually, then this doesn't scale 
(it's 2-to-the-power-of-n, where n is the number of domains blocked or 
not blocked), so, as another poster here suggested, for such "special" 
needs, make them run their own blocking nameserver config, either 
completely their own, or layered (through forwarding) on top of one of 
your loose/medium/tight/supertight offerings. You could offer them some 
sort of "template" for this local nameserver config, but ultimately it 
would be their responsibility to set up and run.

Make clear to them that "blocking" domains was never a designed-in 
function of the DNS, that they're essentially abusing a name-to-address 
mapping service to enforce policy controls on their respective user 
communities, enforcement that oftentimes is easily circumvented by using 
other naming mechanisms (e.g. local hosts files) or IP-address literals.

                                     - Kevin

On 11/8/2010 1:01 AM, Alans wrote:
> On 11/08/2010 12:52 AM, Doug Barton wrote:
>> On 10/31/2010 9:41 AM, Alans wrote:
>>> On 10/31/2010 05:48 PM, Alan Clegg wrote:
>>>> On 10/31/2010 4:48 AM, Alans wrote:
>>>> Instead of saying "how many views can I get", I think you would be 
>>>> much
>>>> better off saying "why am I trying to implement more views".
>>> I'm trying to implement something similar to OpenDNS in a smaller 
>>> scale.
>>> i.e. letting each customer to create their own blacklist domains.
>>> So I was thinking if I can create a view for each customer and let them
>>> edit their zones in a web interface and here my concern is the 
>>> number of
>>> views i can create and number of zones/view.
>> I'm not sure you quite understand what zones and views are. Why would
>> you not simply create a single zone per customer, and eliminate views
>> altogether?
> Well, maybe I'm not, but how to create a zone "per customer"?
> Example, customer1 wants to block access to while 
> customer2 wants normal access to, how a single view can 
> do that?
> And we are talking about thousands of domains here.
> Alans
> _______________________________________________
> bind-users mailing list
> bind-users at

More information about the bind-users mailing list