Right now the provision_dns.module is geared towards managing a master DNS server. But the DNS system is a redundant architecture and it doesn't make sense to just have one server. So we need to be able to manage slave servers.

The way AlternC.org does it is to have a private (password-protected) listing of all the zones that it fetches through HTTP.

I think we can do better than that, so here's what I propose.

A "dns server" should have a "type": "master" (all servers are masters right now) or "slave". Slave servers would be provisionned remotely (so #366418: 0.4: multiple web server support kicks in here). All that would need to be done over there would be to manage a named.conf with the list of zonefiles to sync with. The config file would look like this:

zone "example.com" {
    type slave;
    allow-query { any; };
    file "example.com";
    masters { 1.2.3.4; };
};

"1.2.3.4" would be the address of another master server. So we would also need, in the slave dbserver nodes, a node reference to the "master" server. That master server would in turn tweak automagically its config to allow zone transfers only to those slave servers.

Coming back to the slave: since it's only one file to be transfered, no PHP need to be installed on the slave DNS server, only one file transfered, preferably over SSH or another secure protocol.

Comments

spiderman’s picture

Assigned: Unassigned » spiderman

taking this one, as I plan to implement at least the framework for doing this in upcoming commits..

anarcat’s picture

Issue tags: +dns

This should be a flag sent to the backend. Since we pass around the $node object, simply having a type object should be enough. We will have to fire the tasks on both hosts however, which will be tricky.

adrian’s picture

this can be done now with the current architecture.

we just need to implement a bind_slave class.

anarcat’s picture

Status: Active » Fixed

that class has been implemented and we now create the required bind configuration on slaves for zone transfers (AXFR) to work properly.

Status: Fixed » Closed (fixed)
Issue tags: -dns

Automatically closed -- issue fixed for 2 weeks with no activity.