Disabling RPZ for a few clients / views sharing zones
What is the best way to disable RPZ for a few clients (without forcing those clients to use different DNS server IPs)? I think I could create a new view that has all the same zones and zone contents except for the RPZ one. If I go this route, is it still required to set up per-view IP aliases on the master and slaves so that NOTIFY and transfers work properly? All of my client-facing DNS servers are secondaries with a shadow master. I was kinda hoping that newer versions of BIND could share zones (with identical zone contents) between views without requiring the messy multiple IP alias setup. Thanks. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling RPZ for a few clients / views sharing zones
On 02/06/2014 06:27 AM, Chuck Anderson wrote: I was kinda hoping that newer versions of BIND could share zones (with identical zone contents) between views without requiring the messy multiple IP alias setup. You have always been able to do this with include files. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling RPZ for a few clients / views sharing zones
On Thu, Feb 06, 2014 at 09:50:26AM -0800, Doug Barton wrote:
On 02/06/2014 06:27 AM, Chuck Anderson wrote:
I was kinda hoping that newer
versions of BIND could share zones (with identical zone contents)
between views without requiring the messy multiple IP alias setup.
You have always been able to do this with include files.
I'm not sure how this helps. If you do this:
named.conf:
view no-rpz {
match-clients { 192.168.1.1; };
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { 10.0.0.1; };
};
};
view global {
match-clients { any; };
response-policy { zone rpzip.example.com; };
zone rpzip.example.com {
type slave;
file /var/named/slaves/rpzip.example.com.zone;
masters { 10.0.0.2; };
};
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { 10.0.0.1; };
};
};
Then the global view sees updates to example.com quickly, as soon as
NOTIFY is sent by the master and the zone is transferred. However,
the no-rpz view doesn't see changes to example.com in a timely
manner. I've had to wait awhile (SOA refresh) for new records to
appear and old records to disappear from the no-rpz view's
example.com zone.
I don't see how changing it to use includes helps the matter any:
named.conf.example.com:
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { 10.0.0.1; };
};
named.conf:
view no-rpz {
match-clients { 192.168.1.1; };
include named.conf.example.com;
};
view global {
match-clients { any; };
response-policy { zone rpzip.example.com; };
zone rpzip.example.com {
type slave;
file /var/named/slaves/rpzip.example.com.zone;
masters { 10.0.0.2; };
};
include named.conf.example.com;
};
Maybe I'm missing something.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling RPZ for a few clients / views sharing zones
On Thu, Feb 06, 2014 at 03:10:03PM -0500, Chuck Anderson wrote:
You have always been able to do this with include files.
I'm not sure how this helps. If you do this:
Then the global view sees updates to example.com quickly, as soon as
NOTIFY is sent by the master and the zone is transferred. However,
the no-rpz view doesn't see changes to example.com in a timely
manner. I've had to wait awhile (SOA refresh) for new records to
appear and old records to disappear from the no-rpz view's
example.com zone.
You can have one view send a NOTIFY to the other view using
TSIG; there's a recipe for this in the bind9 FAQ.
Also, in the upcoming BIND 9.10, a single zone object can be
shared between two views:
view us {
match-clients { localnets; };
zone example.com {
type slave;
masters { ... };
};
};
view them {
zone example.com {
in-view us;
};
};
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling RPZ for a few clients / views sharing zones
On Thu, 6 Feb 2014, Chuck Anderson wrote:
On Thu, Feb 06, 2014 at 09:50:26AM -0800, Doug Barton wrote:
On 02/06/2014 06:27 AM, Chuck Anderson wrote:
I was kinda hoping that newer
versions of BIND could share zones (with identical zone contents)
between views without requiring the messy multiple IP alias setup.
Evan Hunt just replied, but I already this typed so
I think that's coming in 9.10, which is in alpha now.
You have always been able to do this with include files.
I'm not sure how this helps. If you do this:
named.conf:
view no-rpz {
match-clients { 192.168.1.1; };
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { 10.0.0.1; };
};
};
view global {
match-clients { any; };
response-policy { zone rpzip.example.com; };
zone rpzip.example.com {
type slave;
file /var/named/slaves/rpzip.example.com.zone;
masters { 10.0.0.2; };
};
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { 10.0.0.1; };
};
};
Then the global view sees updates to example.com quickly, as soon as
NOTIFY is sent by the master and the zone is transferred. However,
the no-rpz view doesn't see changes to example.com in a timely
manner. I've had to wait awhile (SOA refresh) for new records to
appear and old records to disappear from the no-rpz view's
example.com zone.
I like the trick of having view A pull the zone from the real master
notify view B, while view B pulls the zone locally from view A, using TSIG
keys to indicate the other view for the notify transfer.
Adapting your config, using IPv6 loopback addresses, something like this
might work for you:
key be-internal.keys.example.com. {
algorithm hmac-md5;
secret ...secret stuff...;
};
view no-rpz {
match-clients {
192.168.1.1;
key be-internal.keys.example.com.;
};
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { ::1; };
allow-notify { localhost; };
};
};
view global {
match-clients { any; };
// define self as server using be-internal key to allow
// external-internal notify for common zones mastered by
// servers unaware of our view games
server ::1 { keys intra-dns-be-internal.keys.uiowa.edu.; };
response-policy { zone rpzip.example.com; };
zone rpzip.example.com {
type slave;
file /var/named/slaves/rpzip.example.com.zone;
masters { 10.0.0.2; };
};
zone example.com {
type slave;
file /var/named/slaves/example.com.zone;
masters { 10.0.0.1; };
also-notify { ::1; }; // internal-external trickery
};
};
The relatively new ability to specify a key in a masters statement can
also be useful, but isn't required for the above example.
Evaluate it for use in your context. I don't know how/if this interacts with
RPZ. It also assumes you don't do anything else with DNS via loopback
addresses. ...
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling RPZ for a few clients / views sharing zones
On Thu, Feb 06, 2014 at 02:49:03PM -0600, Jay Ford wrote: I like the trick of having view A pull the zone from the real master notify view B, while view B pulls the zone locally from view A, using TSIG keys to indicate the other view for the notify transfer. Adapting your config, using IPv6 loopback addresses, something like this might work for you: Neat. Is there any problem with using the exact same zone file in both views? I worry that one view might fight with the file from the other view... Thanks! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling RPZ for a few clients / views sharing zones
On Thu, 6 Feb 2014, Chuck Anderson wrote: Neat. Is there any problem with using the exact same zone file in both views? I worry that one view might fight with the file from the other view... Oh yeah, sorry, I left that bit out. The slave files do need to be unique or they will over-write each other. I use a directory per view to keep things tidy. Jay ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
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
RE: no. of Views and Zones
You would NOT use a single zone for this. Views are designed specifically to control what is seen. However, that control is mainly done by acl's specifying which networks access which views. Do you assign specific subnets to each client? If so you could do this with views but processing needed to load dozens of views is not something I can comment on as I think most people only do a couple. (Here we do only internal and external to differentiate what people on the internet see as opposed to what people on our intranet see.) What a single zone file can be used for is when you have multiple domains that all point to the same IP address and have the same basic information (e.g. domain A records, www A record, ftp A record, same MX records and same DNS servers). At that point you rely on your web server to determine actual landing page based on the URL that got the user there. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Alans Sent: Monday, November 08, 2010 1:01 AM To: bind-users@lists.isc.org Subject: Re: no. of Views and Zones 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 Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
Thanks Alan, I'll try to do more research and I really like to hear from you or anyone else about better solutions if possible. I think your best solution is to not try to play traffic cop with DNS. If customers don't want their users to access XYZ, let THEM run a proxy or firewall that filters out traffic to/from XYZ. You are always going to be playing catch-up and people will always find ways to work around your solution. Good luck, AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
Lightner, Jeff wrote: You would NOT use a single zone for this. Views are designed specifically to control what is seen. However, that control is mainly done by acl's specifying which networks access which views. Or by server IP. You can use match-destinations with views to provide a different virtual server per server IP address, all on one box, with a single instance of named. You can even combine match-destinations, match-clients, and match-recursive-only together to satisfy even more complex scenarios. That said, if it were me, I'd run separate boxes, separate VM's, or at least separate instances of named (each attached to a different IP) in the scenario posed by the OP. Do you assign specific subnets to each client? If so you could do this with views but processing needed to load dozens of views is not something I can comment on as I think most people only do a couple. (Here we do only internal and external to differentiate what people on the internet see as opposed to what people on our intranet see.) I also don't have any empirical data, but I do expect that setting up thousands of views would have a significant impact on performance — each query runs a gantlet of match-* ACL's before finding the correct view. Regards, Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: no. of Views and Zones
Right. Since we do external and internal we actually have separate NICs for our internal facing network and our external facing network. We do use virtual IPs for the zone transfers from the master to slaves though. I wasn't suggesting the OP use dozens or hundreds of views because as I noted I don't know what the performance impact is. I was mainly posting to say that a single zone file wouldn't do what he wanted. Views theoretically work but performance is a key question. Setting up VMs would probably be a good idea from a security standpoint (i.e. one client doesn't see what another one has). However, it seems one would not be able to run as many VMs as views simply because each VM would take up resources not just for DNS but for the underlying OS on each. If it were me I'd prefer doing multiple VMs at least (and as many servers as required to support the VMs) if I was concerned about security of each customer. This would especially be true if those customers also had web, mail or other servers being hosted by me as well. -Original Message- From: Chris Buxton [mailto:chris.p.bux...@gmail.com] Sent: Monday, November 08, 2010 12:32 PM To: Lightner, Jeff Cc: bind-users@lists.isc.org Subject: Re: no. of Views and Zones Lightner, Jeff wrote: You would NOT use a single zone for this. Views are designed specifically to control what is seen. However, that control is mainly done by acl's specifying which networks access which views. Or by server IP. You can use match-destinations with views to provide a different virtual server per server IP address, all on one box, with a single instance of named. You can even combine match-destinations, match-clients, and match-recursive-only together to satisfy even more complex scenarios. That said, if it were me, I'd run separate boxes, separate VM's, or at least separate instances of named (each attached to a different IP) in the scenario posed by the OP. Do you assign specific subnets to each client? If so you could do this with views but processing needed to load dozens of views is not something I can comment on as I think most people only do a couple. (Here we do only internal and external to differentiate what people on the internet see as opposed to what people on our intranet see.) I also don't have any empirical data, but I do expect that setting up thousands of views would have a significant impact on performance - each query runs a gantlet of match-* ACL's before finding the correct view. Regards, Chris Buxton BlueCat Networks Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
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? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
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? Are you suggesting a single zone with multiple domain names ? I fail to see, how that should be a possible road to follow. The idea, that I am also advocating, is a way of grouping a number of zones, so that the administration would be easier in a multi-customer setup. It is a simple extension of views. I wish people here would just have a little imagination and go beyond thinking about the current concept of views. I am wondering, why the designers of the new rndc addzone/delzone facility are not at all voicing any opinions here, but they may not subscribe to this list at all. Where can they be reached ? - Jørgen Thomsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
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
Re: no. of Views and Zones
On 11/04/2010 06:43 PM, Alan Clegg wrote: On 11/4/2010 12:22 AM, Alans wrote: On 10/31/2010 4:48 AM, Alans wrote: Have 2 questions, is there any limitation (beside hardware) on number of views? I mean creating a view/customer? And is there any limitation for number of zones/view? Since I didn't got exact answer for my questions, I was thinking if you can tell what is your largest number of views and zones that you used so far? sizeof(zone data) * count(views) - memory required If you have enough memory, you can support whatever you need. Again, I think there's a better solution out there than bunches of views. Thanks Alan, I'll try to do more research and I really like to hear from you or anyone else about better solutions if possible. regards, Alans ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
On 10/31/2010 4:48 AM, Alans wrote: Have 2 questions, is there any limitation (beside hardware) on number of views? I mean creating a view/customer? And is there any limitation for number of zones/view? Since I didn't got exact answer for my questions, I was thinking if you can tell what is your largest number of views and zones that you used so far? regards, Alans ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
On 11/4/2010 12:22 AM, Alans wrote: On 10/31/2010 4:48 AM, Alans wrote: Have 2 questions, is there any limitation (beside hardware) on number of views? I mean creating a view/customer? And is there any limitation for number of zones/view? Since I didn't got exact answer for my questions, I was thinking if you can tell what is your largest number of views and zones that you used so far? sizeof(zone data) * count(views) - memory required If you have enough memory, you can support whatever you need. Again, I think there's a better solution out there than bunches of views. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
no. of Views and Zones
Hello Everyone, Have 2 questions, is there any limitation (beside hardware) on number of views? I mean creating a view/customer? And is there any limitation for number of zones/view? Thanks in advance. Alans ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
Alans, Have 2 questions, is there any limitation (beside hardware) on number of views? I mean creating a view/customer? And is there any limitation for number of zones/view? You cannot use views to group zones for customers. I have recently on this list proposed an extension to the view concept to be able to do this, but nobody has commented on this proposal. Views are primarily used for cases, when IP-adresses are different e.g. internal addresses versus external addresses depending on the client IP address looking up the zone data. - Jørgen Thomsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
Pardon a n00b question, but wouldn't that be the case if you used a number of different IPV6 addresses? Bèrto On 31 October 2010 14:04, J. Thomsen l...@jth.net wrote: Alans, Have 2 questions, is there any limitation (beside hardware) on number of views? I mean creating a view/customer? And is there any limitation for number of zones/view? You cannot use views to group zones for customers. I have recently on this list proposed an extension to the view concept to be able to do this, but nobody has commented on this proposal. Views are primarily used for cases, when IP-adresses are different e.g. internal addresses versus external addresses depending on the client IP address looking up the zone data. - Jørgen Thomsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- == Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement viole les droits du peuple, l'insurrection est, pour le peuple et pour chaque portion du peuple, le plus sacré des droits et le plus indispensable des devoirs. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
On 10/31/2010 4:48 AM, Alans wrote: Have 2 questions, is there any limitation (beside hardware) on number of views? I mean creating a view/customer? And is there any limitation for number of zones/view? 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. Can you perhaps explain your need to fragment the DNS namespace (which was NOT supposed to be done)? AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
Alan Clegg, Can you perhaps explain your need to fragment the DNS namespace (which was NOT supposed to be done)? I cannot speak for Alans, but only for our own needs. We run DNSes for a number of customers i.e. everybody in the whole world should see the same zone data. No different views of the same zones here. Currently this is implemented by external tools maintaining include files. Recently an rndc addzone/delzone feature has been introduced. It is maintaining views and include files and making instant updates. What I am proposing is a simple generalization of this concept, so that a view can be used as a group thus eliminating the need for external tools. Conceptually this is very simple. Just make BIND search for a zone in all views matching the client until it finds it instead of only searching the first matching view as it does today. It is even backward compatible for current correct configuration of views. mvh Jørgen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
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'd like to hear if there are other ways to do this. P.S. I read the specs for DNS RPZ but I can't find enough docs about it to try it. Can you perhaps explain your need to fragment the DNS namespace (which was NOT supposed to be done)? AlanC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
