Integration with CRM
Migration from Existing CRM to PDNS API
If developers are available, a company can choose to dispense with the pdns-app web interface and base their front-end screens on API calls to https://pdns-app.planisys.net:8443, always within the scenario of having the application within the Planisys cloud.
For example, an application can be developed in Angular, React, or VueJS, using the PDNS REST API. In this way, there is no need to modify the integrated environment for Clients, allowing the addition/modification or retention of the DNS-related screens of the current CRM.
For this, Planisys provides APIKEYs at both the Reseller level and the Company level (the latter with fewer privileges), which are sent as Authorization Headers in the REST API, indicating the short-name of the client company or reseller along with their APIKEY.
Note
A reseller can modify their APIKEY if they believe it has been compromised or as a general security policy. A client company can also do the same with their APIKEY. Additionally, a reseller can modify a client company’s APIKEY if deemed necessary by policy or if the client requires managed services.
Transparent Integration with CRM without Making Changes
If a CRM with an interface for generating bind zones is available, the solution offered by PDNS is to use a Hidden Secondary Nameserver technique.
Using this technique, one of the client’s Bind9 servers must make the zone list available via rsync and also allow zone transfers from their Bind9 to the Hidden Secondary Nameserver.
In this way, periodically (e.g., every 1 minute), PDNS can retrieve the zone list via rsync and detect if there was a delta. If there was no delta, nothing is done at the zone list level. If there was a delta, the Hidden Secondary is reconfigured to add/remove zones from the delta. Then, a reload is sufficient to retrieve the missing zones or remove the zones that have changed.
In parallel, every minute (unless the client’s Bind9 configures NOTIFY-ALSO to notify us of zone serial changes), the serials of all zones are checked. If any have changed, PDNS will dump the changed zone, then parse it and import it into its own MySQL backend.
In this way, it can propagate changes made in the client’s DNSs (triggered by modifications in the client’s CRM), incorporate them into its backend, and then propagate them through its authoritative servers.
Note
In the case of using pdns-app instead of the On-Premise mode, it should be remembered that the recursive and authoritative servers of a Reseller do not necessarily have to be in the Planisys cloud (where pdns-app runs) and can be on any architecture or cloud.
This graphic shows the transparent and automatic integration process using an RSYNC+AXFR technique where PDNS-APP uses its integrated Bind9 as a Shadow Secondary.
