no. of Views and Zones
Kevin Darcy
kcd at chrysler.com
Thu Nov 11 00:31:53 UTC 2010
Alans,
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 facebook.com while
> customer2 wants normal access to facebook.com, how a single view can
> do that?
> And we are talking about thousands of domains here.
>
> Alans
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
More information about the bind-users
mailing list