Just curious: What does the "DNS zone function" do when an API user has this enabled? The question arises because there's also individual dns zone functions like "DNS a function" "DNS cname function" "DNS mx function". So what's the purpose of the "DNS zone function"?
Is the "DNS zone function" permission necessary to udpate the zone serial? It seems when I just alter only a TXT record through the api, then it won't update the serial and hence changes are not transmitted to slave servers. Or how can I tell - through the API - to push changes to slaves?
yes. The serial is not updated autmatically. But we should change that so that the serial gets updated automatically, there is already a report in the bug tracker for that.
I don't think, that this is a bug. If fwe increase the serial for each changed / updated dns-records, there will be a lot useless restarts for bind.
But the problem is if I only want to give access to a user to a specific part of the dns functionality - as it's currently handled - I'd also need to give access to the "DNS zone function" which allows to remove the whole entry. So then why even give granular access? Also as said: In the current situation the dns is being reloaded on the master when altering entries (e.g. add TXT record or removing it). No further action is needed. The problem is, that this change isn't reflected to slave servers.
As long as you run ispconfig on all dns-slaves, this is not a problem as bind reloads on each slaves. I run ispconfig on my first dns and the othe dns are running as bind-slaves so i have to increase the serial after any update. But i don't see any problems with the current api.
No, it doesn't seem to reload. Through the API I add a TXT record. I don't issue any command or anything. Let's Encrypt's DNS-01 challenge finds that TXT record. However if you have slave setup or multi-server, then editing the TXT record on the main server works but changes are not propagated to the slaves. Since Let's Encrypt will using any of the designated DNS servers it can pick one that wasn't updated.
Are you running ispconfig on all dns (slaves)? You need a new serial, when you use bind-slave (i.e. no ispconfig on the dns).
I don't use multiple dns server or master-slave setup but others do. Current situation on single ISPC setup: 1) add new TXT record through the api 2) bind reloads and presents TXT record to let'x encrypt Current situation on multi-server setup: 1) add new TXT record through the api to the master 2) bind on the master reloads; change is not transmitted to slaves 3) let's encrypt can't find TXT record when checking a slave You mentioned before "useless restarts of bind" - but that's already how master handels it. The problem is with the slaves.
Maybe we should just add a function parameter to all dns record functions like $newserial = true/false with default false to keep the current behavior for compatibility reasons and when you want to create a new serial directly, then set it to trie in api call.
If you add/update a dns-record, ispconfig writes the new zone-file and restarts bind afterwards. This is not a problem as long as all dns are managed by ispconfig - the will always present the value for a changed/created record. BTW: you get a new serial if you change a record using the interface - this is also an additional call: store value + increase serial. I don't see any way to increse the serial in the bind-plugin as this can create different serials on each dns-server running ispconfig. It should be possible, to extend the api as till suggested. But you will not see a new serial in the api-result. @till is it possible to bind a plugin to api-calls? But it's not very difficult to increase the serial using the api: Code: $dns_records = $client->dns_txt_get($session_id, array('zone' => *ID*, 'type' => 'TXT', 'name' => "%.3")); $soa = $client->dns_zone_get($session_id, *ID*); $soa['serial']=increase_serial($soa['serial']); foreach($dns_records as $rr) { $rr['data'] = $data; $client->dns_txt_update($session_id, $rr['id'], $rr['id'], $rr); } $client->dns_zone_update($session_id, *ID2*, *ID*, $soa);
Plugins listen to datalog changes and you can use sys actions. If a datalog record is created by the api or the UI doe snot matter (but is also not visible) for the plugin. I guess the problem of @sjau is not that it's complicated, he just did not wanted to hand out the permission to alter the zone itself, which is currently nescessary to alter the serial. Therefore my suggestion that we might add a parameter to the dns record functions for that, so that we can alter the serial within the api function automatically. I won't alter the plugin code here, just add some code in the api lib that calls a zone update with new serial right after the DNS record update.
Well, as ISPC API offers manipulation of just certain records - in this case add/remove of TXT record for Let's Encrypt DNS-01 challenge - it should be possible to apply that change to all nodes/slaves. Otherwise what is the reason for such granular access then if you are required to get access to the zone file and be able to remove the whole zone? Thinking in terms of security I could add a general remote api user that only can manipulate the TXT record. With that, I could hand out that user to multiple persons. Damage that can be done with just TXT records are minimal. Other recrods that use TXT that come to my mind is spf and dkim.
Using acme, I am looking forward to that. Especially as presently even opening and just (unchanged) saving a record seems to increase the serial (that's how I get acme presently working in a bind master-slave environment, start acme, wait for the zone, save a record, acme updates successfull, save a record again to propagate the removal of the TXT records).
