CRM Integration

Migration from Existing CRM to PDNS API

If developers are available, a company may choose to avoid using the pdns-app web interface and instead base its front-end screens on API calls to https://pdns-app.planisys.net:8443, provided the application is hosted within the Planisys cloud.

For example, it is possible to develop an application using Angular, React or VueJS, and use the PDNS REST API. In this way, there is no need to modify the integrated client environment, while still being able to add, modify, or keep unchanged the DNS-related screens of the existing CRM.

For this purpose, Planisys provides APIKEYs both at the Reseller level and at the Company level (the latter with fewer privileges). These are sent as Authorization Headers in the REST API, specifying the customer company or reseller short-name together with its APIKEY.

Note

A reseller may modify its APIKEY if it believes it has been compromised, or as part of a general security policy. A customer company may also change its own APIKEY. Likewise, a reseller may modify the APIKEY of a customer company if considered necessary due to policy requirements or if the customer requires a managed service.

Transparent CRM Integration Without Modifications

If an existing CRM already provides an interface to generate bind zones, the solution offered by PDNS is to use a Hidden Secondary Nameserver technique.

Using this technique, one of the customer’s Bind9 servers must make the zone list available through rsync and must also allow zone transfers from its Bind9 server to the hidden secondary nameserver.

In this way, periodically (for example every 1 minute), PDNS can retrieve the zone list through rsync and detect whether there is a delta. If there is no delta, no action is taken regarding the zone list. If a delta exists, the Hidden Secondary is reconfigured to add or remove zones from the delta. Then, a simple reload is enough to retrieve missing zones or remove changed zones.

In parallel, every minute (unless the customer’s Bind9 configures NOTIFY-ALSO to notify serial changes), the serials of all zones are checked. If any serial changes, PDNS will perform a dump of the modified zone, then parse and import it into its own MySQL backend.

In this way, changes made in the customer’s DNS servers (triggered by modifications in the customer’s CRM) can be propagated, incorporated into the backend, and later distributed through the authoritative servers.

Note

When using pdns-app instead of the On-Premise model, it is important to remember that a reseller’s recursive and authoritative servers do not necessarily need to be hosted in the Planisys cloud (where pdns-app runs), and may operate in any architecture or cloud environment.

This diagram shows the transparent and automatic integration process using an RSYNC+AXFR technique, where PDNS-APP uses its integrated Bind9 as a Shadow Secondary: