1) In DNS Zone Settings, we can set "Allow zone transfers to these IPs (comma separated list)". Is it valid to have IPV4 comma IPV6 addresses for the AXFR and NOTIFY fields? 2) To set transfers for ALL zones, do we need to use ISPConfig to set the AXFR and NOTIFY per-zone? Or is it acceptable to set allow-transfer and allow-notify manually in named.conf.local with one setting that applies to all? 3) Does ISPConfig have a place to set named.conf.local settings, or do changes there need to be made from shell? 4) When we set AXFR/Notify in ISPConfig, it bumps the zone serial#. That can't hurt, though I don't think it's required. If we make a global change in named.conf.local, do we need to manually bump the serial# in each zone (pri file)? I can script the process but it would help to know if there is already something that does this. I think @Taleman was looking at this. 5) In general, is there any conflict with ISPConfig if we have back-end scripts that modify zone (pri) files and bump the serial#? I am making a Lot of DNS changes now, most of them are the exact same changes to many zones. I'd like to reduce the pain of using the UI for each of these. Thanks!!
I believe so, although I have not used IPv6 as name server address. Check what syntax the IPv6 must be. It should work, but since you are managing name service with ISPConfig, you should not go messing about in the bind configuration files. Would such a change alter zone data? If not, there is no need to transfer zones to secondary servers. After migrating sites to new server, I have stopped name service, edited zone data directly in database with SQL queries, used ISPConfig | Tools | Resync to get zone files written and started name service back. I have name servers where I do not have ISPConfig. There I use Emacs to edit zone files, it has DNS mode that knows to increment serial number.
Test and see You can set it as default in your DNS templates with Code: xfer= also_notify= ISPConfig overwrites this file, so you shouldn't modify it manually. You should never modify the zone files yourself as ISPConfig will overwrite them when the zone is updated in ISPConfig. I think you must make up your mind wether you want to use ISPConfig to manage your DNS server, or you want to do it manually and leave ISPConfig out of it. If you want to make changes in batch, you can do this in the dns_rr table of the ISPConfig database and then trigger a resync of all zones under Tools > Resync > DNS records.
> > If we make a global change in named.conf.local, > Would such a change alter zone data? If not, there is no need to transfer zones to secondary servers. I should have been more specific... Here is one operation I'm considering in this Ubuntu system : named.conf.options: Code: options { allow-transfer {0.0.0.0;11:11:11::11:1;}; notify yes; also-notify {0.0.0.0;11:11:11::11:1;}; } That avoids the need for this in named.conf.local (written by ISPConfig with individual zone changes) : Code: zone "aaa" { allow-transfer {0.0.0.0;11:11:11::11:1;}; also-notify {0.0.0.0;11:11:11::11:1;}; } zone "bbb" { allow-transfer {0.0.0.0;11:11:11::11:1;}; also-notify {0.0.0.0;11:11:11::11:1;}; } zone "ccc" { allow-transfer {0.0.0.0;11:11:11::11:1;}; also-notify {0.0.0.0;11:11:11::11:1;}; } That's the whole reason for the hierarchy of config files. When the name service is restarted all domains should respect the single named.conf.options directive. And to do this properly I should probably include a custom file from named.conf rather than (yes) messing about in a primary file. Someone might say "don't put transfer info in the higher level named.conf file because it will transfer default-zones, which is invalid". I dunno if that's true. That's why I'm asking these questions. But you did say something that is extremely relevant! That's exactly what I'm asking. If ISPConfig is saving data to the database and then mirroring it to the file system, then our freedom to make a change to named.conf.options and named.conf.local depends on what ISPConfig stores in the database. I'm learning here that we should not edit named.conf.local or zone (pri) files because all of that data is in dbispconfig. OK, no problem. The question remains as to whether ISPConfig saves and then writes any data for named.conf.options. I don't think so. I have had other edits in there for a couple years. I am getting more info as I am writing this and checking files, so I'm sorry if it seems like I'm answering my own questions. I'm documenting this for anyone who reads it, including myself later. But is that still accurate in the most recent and upcoming ISPConfig updates? Someone might say "in the upcoming v3.x there is a new page for higher level bind options" and then I'll know what the limits are on this. Thanks again.
>> In DNS Zone Settings, we can set "Allow zone transfers to these IPs (comma separated list)". Is it valid to have IPV4 comma IPV6 addresses for the AXFR and NOTIFY fields? Thom said > Test and see Yeah, that's what I'm doing, but I don't know if the receiving system (NS2) is getting notifications on the second IPV6 or just the primary IPV4. The /var/log/bind/notify file doesn't say which server(s) is/are being notified, just that it's "sending notifies". Unless I can set higher logging detail on that or ask the owner of the NS2, I don't know if IPV6 is being used at all for outbound transactions.
The options for transferring zones are managed by ISPConfig on zone level, so putting them in named.conf.options globally makes not much sense to me. But you can try it to see how good it works and where it collides with ISPConfig. Manual changes in named.conf.options can be overwritten by ISPConfig updates as named.conf.options is a installation template, so you must create a custom template then to make your alterations update safe. If you want to change DNS records automatically, use the remote API.
Thom said: Ahh! I already have a template for DNS records, didn't know what other variables were valid here. The problem with this is that there are a ton of existing zones and I don't think we can apply a template to an existing zone.
This is not ISPConfig specific, ISPConfig just writes values you set into config files. So you can either try to get such a very specific answer from a BIND developer on their mailinglist, if you can't find an answer on the internet or in the BIND documentation. Or try it by, e.g., blocking IPv4 traffic with a firewall to see if it still works.
Thom already explained that you that you can update zones by SQL in the database and use resync to write out the changes.
till > Thom already explained that you that you can update zones by SQL in the database and use resync to write out the changes. Yeah, which is what Taleman is doing and in this thread I'm learning what ISPConfig manages and what it does not. th0m > ISPConfig overwrites this file, so you shouldn't modify it manually. till > Manual changes in named.conf.options can be overwritten by ISPConfig updates as named.conf.options is a installation template That's exactly the insight that I was looking for. I didn't know that detail.
You can easily look this up yourself, btw. if there is a template for a file in the ispconfig /usr/local/ispconfig/server/conf/ folder or in the folder install/tpl/ of the ISPConfig tar.gz, then the file you are editing is managed by ISPConfig.
th0m > I think you must make up your mind wether you want to use ISPConfig to manage your DNS server, or you want to do it manually and leave ISPConfig out of it. No... I enjoy using ISPConfig to manage DNS. I just didn't know how far it does that management or how it does that management. I don't want to maintain DNS manually. I'm just trying to transfer NS2 responsibilities to another server - preferably with three lines of config data in a single file rather than manual UI updates for a lot of zones. The fundamental inquiry has been about how to make global changes without having to make them all one at a time in each zone. Till said "The options for transferring zones are managed by ISPConfig on zone level". Using a UI for individual record updates is painful. At one time or another doesn't everyone have the same desire to change a large number of mailboxes, websites, or other records? ISPConfig doesn't have features to select and modify sets of records. That leads to the quest for detailed information: What OS files are involved, and does ISPConfig save dbispconfig data to maintain those files, or are the files updated directly? In this case I knew ".local" and "pri." data is curated in the database and then written to the file system. So I knew a mass change would require a database update then a resync event. But since my named.conf.options file is never updated, and I don't see anything in the UI for it, I had to ask about it's status. The lack of mass update capabilities is not a criticism. It's just the way it is. I just want to know what I need to do to continue managing my systems given this state of the art. If any effort was painful enough, I'd script it and offer it as FOSS. If I had the time I'd create and offer enhancements to do the kind of mass updates that I'm talking about from the UI. But ... this is what it is. So for now all we can do is to ask where data is and if and how it's updated. Till's entire quote was "The options for transferring zones are managed by ISPConfig on zone level, so putting them in named.conf.options globally makes not much sense to me." Meh, just give it a minute. BIND, Apache, Postfix, and most other big apps cascade configuration data from the least-specific to the most-specific. When we go to System>Server Config we do have higher level options for apps including DNS. This entire discussion would never have been created if there was a single text box on the Server Config DNS page for local options. The contents of that box would be written to something like /etc/bind/named.conf.ispconfig, which would be included from the BIND named.conf path. I dunno if an enhancement request like that would be processed, but it's certainly valid given the way we all do things here. For more refined features and less chance of bad data, we tend to see individual fields and not open text boxes. I don't think anyone would want all possible individual fields for applications like this - that would be unmaintainable (borderline insane). ISPConfig provides a great balance, with most features we need in the UI and references to the back-end for skilled operations when more refinement is necessary. We know there is a line there between what the platform does and what it doesn't do. Many questions in this forum are about trying to figure out exactly where the line is, and how to navigate between what we can do with the software and what we need to do ourselves. Questions about this shouldn't lead to "I think you must make up your mind whether you want to use ISPConfig to manage...". I owe you guys an apology. After I got started with ISPConfig I really wanted to make significant contributions to the documentation, whether in wiki or blog format, to help people figure this stuff out and reduce the number of questions here. I failed to allocate time for that FOSS contribution. I still hope to do some of that after we've finished some server migrations. Thanks as always for your patience - and fine software and support.
In ISPConfig, this can be done with a single line of SQL code plus a single click on a button to resync this; no config file editing is needed at all. See post from @Th0m. This has been answered by Thom in post #3 already. And I added a second method in post #6. There is no lack of mass update capability here and nobody said you shall edit all zone manually. We showed you two completely different ways of doing this in ISPConfig. One uses the built-in resync tool, and the other uses the remote API. Both features are built into ISPConfig. There is a misunderstanding here. What I meant is that it does not make sense that you put it there while ISPConfig manages it on the zone level. For ISPConfig itself, we decide from case to case what the best way is to achieve a certain goal to configure a service, and this can indeed be a global file. Otherwise, ISPConfig won't write a template for the name.conf options. But If we want to configure a service more fine-grained, in this case on zone level, it makes no sense to do it globally and on zone level as for a software that writes a config file, there is no difference if the same option is indeed present in each file or not. Having two places for the same settings, which might prevent the other setting from working, makes things more complicated. That's why it is often better when you want to have fine-grained control over service to just put the setting in one place and then replicate it for all configs.
Thanks again for the information. I already did this in the config file and will revise the process to a SQL query soon. For now... Mass transfer HowTo Edit /etc/bind/named.conf.options Top section is "options{ ... };". Bottom section is "logging { ... };". Bottom of options is something like this: Code: //======================================================================== // If BIND logs error messages about the root key being expired, // you will need to update your keys. See https://www.isc.org/bind-keys //======================================================================== dnssec-validation yes; version "unknown"; allow-transfer {none;}; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { none; }; }; Modify to: Code: //======================================================================== // If BIND logs error messages about the root key being expired, // you will need to update your keys. See https://www.isc.org/bind-keys //======================================================================== dnssec-validation yes; version "unknown"; // allow-transfer {none;}; include "/etc/bind/named.conf.local1"; // any name works auth-nxdomain no; # conform to RFC1035 listen-on-v6 { none; }; }; Note that there are only two lines changed, one commented and one inserted. Now create named.conf.local1 : Code: notify yes; allow-transfer {11.11.11.11;22.22.22.22;}; //semicolon-delimited/terminated also-notify {11.11.11.11;22.22.22.22;}; // same detail Be sure not to put anything else in there, and do not duplicate any fields that are in named.conf.options. Activate it: systemctl restart named systemctl status named The service should show "active (running)". If not, `journalctl -xe | grep named` and look carefully to see what is wrong. Fix, restart, check status. If it worked and you have already configured the receiving server, then you should see a stream of transfer messages "AXFR started" and "AXFR ended". Summary of actions in time order: journalctl -xe | grep "named\[.*]: client.*ended" | awk '{print $1, $2, $3, $9}' Summary in domain order: journalctl -xe | grep "named\[.*]: client.*ended" | awk '{print $9, $1, $2, $3}' | sort It is probably better to modify the database records. This option is purely for anyone who needs an alternative, perhaps for settings that aren't managed in ISPConfig. HTH
True, and that is the reason I do not modify configuration files if I use ISPConfig. If you set up allow transfer in named.conf.options, you must do it also on secondary servers. Allow transfer is to allow zone transfers to secondary servers and between secondary servers, but also to prevent third parties doing zone transfers. The secondaries have the same data, so malicious party could get the info they want from secondary also.
That's a great point, @Taleman - thanks. I used SQL for a number of operations to understand how that works (now with the great info in this thread). Here is a summary for anyone who stumbles on this thread... The scenario has been that all zones have two NS records which point to ISPConfig DNS 'myns1' and 'myns2'. One recent big change has been to retire our 'myns2' and use external secondary DNS services from Mythic Beasts (a really fine company, IMO). This eliminates the need for us to maintain a VPS just for DNS, with the added benefit that we get NS1 and NS2 servers as backups from MB, for a total of three NS. So the goal with ISPConfig was to change the current NS2 from 'myns2' to 'ns1.mb', and then add NS records for 'ns2.mb'. [ GET A BACKUP! ] This is to move from myns2 to ns1.mb: Code: UPDATE dns_rr SET data = 'ns1.mythic-beasts.com.', `stamp` = NOW(), `serial` = '2024080801' WHERE type = 'NS' AND data = 'myns2.'; This duplicates the ns1 references into new records for ns2: Code: INSERT INTO `dns_rr` (`sys_userid`, `sys_groupid`, `sys_perm_user`, `sys_perm_group`, `sys_perm_other`, `server_id`, `zone`, `name`, `type`, `data`, `aux`, `ttl`, `active`, `stamp`, `serial`) SELECT DISTINCT `sys_userid`, `sys_groupid`, `sys_perm_user`, `sys_perm_group`, `sys_perm_other`, `server_id`, `zone`, `name`, `type`, 'ns2.mythic-beasts.com.', `aux`, `ttl`, `active`, NOW(), '2024080801' FROM dns_rr WHERE type = 'NS' AND data = 'ns1.mythic-beasts.com.'; That was followed by a ISPConfig resync. Because I have a new named.conf.local1 with allow-transfer and allow-notify, all updated records immediately went out to update the MB NS. While probably not required, I also refreshed localhost DNS cache: systemctl restart systemd-resolved rndc flush I also took this opportunity to delete old site challenge records and others that are no longer valid. A mass update feature in the UI would be really helpful rather than doing this from the back door, but ... oh well. All three NS show the correct NS settings: dig @ns1.mythic-beasts.com domain.tld NS ...also @ns2 and @myns1 Yes, I will probably use SQL to add the AXFR/Notify directives as well - the zone records will get transferred properly in a server migration and updates while the custom named.conf requires manual housekeeping. It's been a great experience to learn how this stuff works so that I know the options available. And I hope anyone else who stumbles on this will get a better understanding as well.
