IP-1801: Listener::Named::OverrideDefaultRecords is fatally flawed

Quote from Youtrack

Reporter	Marc Pujol (kilburn)
Created	Oct 9, 2018 6:10:15 AM
Updated	Oct 9, 2018 6:13:18 AM
Priority	Normal
Type	Bug
State	Submitted
Assignee	Laurent Declercq (nuxwin)
Subsystem	No subsystem
Affected versions	1.5.1
Milestone	1.6.0
Severity	No severity

This listener is supposed to prevent collisions between the panel-created DNS entries and user-entered custom DNS records.

Unfortunately, the logic is fatally flawed. At first glance it seems simple enough:

In the beforeNamedAddCustomDNS event, any default records that have an overriding custom record get deleted.
In the afterNamedAddCustomDNS event, any default records that no longer have an overriding custom record are readded.

However, there is an important problem: whenever some property of the domain is modified, the alias is maked toedit, meaning that the entire addDmn chain will be run for it. Let's see what happens with an example:

1. Customer adds domain.tld to the panel. The addDmn chain creates a zone with the default records for it.
2. Customer adds a www IN A xxx.xxx.xxx.xx record for that domain. Modules::customDNS is run, calling beforeNamedAddCustomDNS, that clears the default www IN CNAME record. Then Modules::customDNS creates the custom record, and everything is fine up to here.
3. Customer changes some property of the domain (i.e.: the php settings). The Modules::Domain chain is run. This ends up calling Servers::named::bind::addDmn, that recreates the zone's default records. Now domain.tld has both www IN CNAME (from the defaults) and www IN A (custom) records, and named-compilezone fails fatally because the zone data is incorrect.

Unfortunately, I see no way to fix this using listeners only. The reason is that during the addDmn chain the custom DNS records are never loaded. We can listen to the beforeNamedAddDmn and afterNamedAddDmn events, but the listener can't know which custom DNS records exist at this point.

Display More

Source: https://youtrack.i-mscp.net/issue/IP-1801