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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
