Thilanka Samarasekera wrote: > Thank you for the prompt response. > > Is there some place I can read about how to incorporate several BIND 9 > server to be managed one unxsbind? I understand your naming scheme but > when a user logs into the control panel I don't think they should see > the "tZone", "tBlock", "tView", "tClient" and "tJob" on the first page. > If this is so then I understand, but I think something is not right with > my install. A screenshot would be the best way I can show what I am > talking about. I do not want to waste your valuable time. > >
Thilanka, Thank you for your questions that will help us all stay on course and prod us to improve. Improve what is becoming a widely used DNS management environment for enterprises/organizations that wish to delegate zone modification to either internal or external customers. Or to provide true DNS SaaS for many organizations (via unxsBind multiple NS sets and our organization/contact/role model.) --- First, regarding your comments about schema object naming in a "control panel": You are probably referring to the backend interface iDNS. IMPORTANT: This backend is not meant as a user friendly interface. It is meant as a technical schema based db manager with a mix of production, alpha and beta functionality to be used by developers (and maybe in some cases by the DNS root admin in extraordinary circumstances) to create their own web 2.0 interfaces. We provide several examples: idnsAdmin, idnsOrg and vdnsOrg. --- Second, there are many different ways to setup a cluster of NSs managed by one unxsBind system. And of course unxsBind was designed from the start to not only manage one set of NSs but even multiple disjoint NS sets. E.g. unxsBind controls N NS sets on M servers. For now only one NS can coexist on one "server." (With the popularity of virtual servers this issue is not as important as it was and the solution has been "slow" tracked.) For complex multi view DNS data we prefer to use all MASTER NSs (avoiding the complex master to slave zone xfer multiple VIP setup that is required by BIND.) For standard single external view systems, MASTER-SLAVE managed by unxsBind works just fine. The other major issues to take into consideration are the db distribution method (for failover and painless multi server backup) and the local server connection to the backend db. This can be done with a db multi-master replication scheme where the local unxsBind job queue processor connects via a local socket (good for small clusters.) Or a standard star topology where the NSs connect to a remote backend -if through uncontrolled WANs then usually via an ssh tunnel to avoid MySQL SSL issues and overhead. (In the future we will separate read and write db query code to better use replication clusters with only a single write server and many read servers.) --- Hope these short comments can be used as a starting point for clarifying some issues. And that will use as a source for expanding wiki pages at http://openisp.net/openisp/unxsVZ/wiki/InstallingBindYum (has some setup info for small clusters.) http://openisp.net/openisp/unxsVZ/wiki/GettingStartedBind (should be expanded. Any volunteers?) Right now we are trying to quickly finish the last 1.x rpm/yum release (with NAPTR, AAAA RR support and LDAP orgainzation/contact/role model integration) before we start releasing the new 2.x series with major extensions (but backwards compatible) for automated DNSSEC support. Best Regards, Gary Wallis. _______________________________________________ unxsBind mailing list [email protected] https://lists.openisp.net/mailman/listinfo/unxsbind
