PDNS Deployments
This section will present multiple deployment methods, according to the client’s load requirements. It should be noted that since the product is Multi-Tenant, it is also aimed at companies that manage multiple domainswithout architectural requirements.
DNS for End Clients in the Planisys Cloud
In the Planisys cloud, the PDNS application is provided in the cloud.
Warning
In this section, we show what a client user can do, regardless of thenetwork architecture of the deployment.
Direct Planisys clients access a web page at https://pdns-app.planisys.net:8443with a single user role level, where they can create Zones (Master, Slave, IPv4 and IPv6 Reverse) and create Zone Records or RRs (Resource Records), and also use the API with their own **APIKEY**(see graphics) to, e.g., create zones, modify records, etc.
This is a shared service, in which Planisys provides the authoritative servers accredited by ICANN that the client must use to delegate their domains.
The client can use Planisys’ standard resolvers.
The types of zones that an end client can create are:
Direct Master |
IPv4 Reverse Master |
IPv6 Reverse Master |
Slave of external master |
The company can also:
Consult the domain’s WHOIS (expiration date and more data) |
View the delegation status (if it is deactivated, if it is delegated to other NSs) |
Access the Zone records via the |
Zone Records (Resource Records)
After accessing the records, you can see that immediately after the Zone is created,”to the NS-SET and an SOA record, whose data is shown separately at the top.
Any modification made at the record level (delete/edit/add) will resultin an automatic increment of the SOA Serial Number.
In this graphic, we see the reseller user logged in, but it is the same view for an end client user.
Next, an MX record will be added (by clicking the green add MX button)for the assetcrypt.com zone, and we will see how the serial number changes from 2023010500 to 2023012000. Since the Serial type of this zoneis in YYYYMMDDSS format, it will try to use the current date and thenSS from 00 to 99. Zones can be registered with a serial that is not date-basedbut rather a number from 0 to 2^32 -1 (4294967295).
Here, the list of records is shown after adding the MX, and the increasedserial number is visible. This is a trigger that causes the primary serverto regenerate the zone, and once loaded, it triggers zone transfers tothe secondaries via the NOTIFY protocol (notifying the secondaries to doan AXFR, generally using the IXFR protocol, which is an **incremental zone transfer**to fetch only the changes).
DNS for Resellers in the Planisys Cloud
A PDNS reseller is an entity that has its own NS_SET, that is, its own authoritative servers, and possibly its own resolvers.
A login is provided to the Reseller, whose initial screen looks like this:
The reseller has permissions to:
Create Companies |
Create Company Users |
Create Domains |
Declare their Authoritatives |
Declare their CIDR Blocks to limit Resolvers |
Declare ACLs for external zone transfers |
Client Companies
Initially, the reseller sees their client companies:
Zone Management
and can directly access their clients’ zones:
Even if the operation of the zones is not going to be delegated to the clients,either because they do not have knowledgeable personnel or prefer managedservice, it is advisable at the CRM level to know which zones/domains are assigned to their clients.
Warning
In the case of having domains without identifying which clients theybelong to, a company must still be created -even if fictitious- to be able to access the zones.
Change a Zone from one Company to another
In the case that we have unidentified domains, or domains mistakenly assigned to a company,we can very easily from the zone screen, by clicking on the pencil icon, access thefollowing edit screen, where by simply choosing the company in the Companies dropdown*and pressing the **Save* button, we make the ownership change.
It should be noted that the operator should use the WHOIS button from the domain list to establish the ownership or ownership of a domain.
WHOIS
With the WHOIS button, the domain information is displayed, which depends on the domain Registrars, although it must comply with ICANN policies, e.g.:
It is important to note that the expiration date of the domain appears in the WHOIS text window.
Authoritatives
To give an idea of the level of independence that a Reseller Deployment has,we show here their own authoritative servers, which can be found in any Datacenter,and can be Unicast or Anycast (see chapter on High Availability):
Note
The fact that the PDNS application is deployed in the Planisys cloud doesnot imply that the authoritative servers and resolvers are also in the cloud.In the image, two nameservers registered with ICANN are shown in the Planisyscloud, dns1.avascorp.net and dns2.avascorp.net.
Users
In this list, we see a typical case of a user with rights to operate the Zones of a company, and the Reseller itself with a lock that cannot delete itself.
Adding Users
In the Reseller deployment, you can create users. In this graphic, the creation of a Company operator user is shown.
In this graphic, the creation of a DNS Operator at the Reseller level is shown, who can create zones and companies. When selecting DNS Operator, the Company selection dropdown disappears, as it will be able to operate on all Client Companies of this Reseller.
It is important to note that the user reseller1@planisys.com is a DNS Administrator at the Reseller level, who has the ability to create different clusters of authoritative and recursive servers, that is, with more permissions than a DNS Operator.
Deployment of External Recursive and Authoritative Servers
The fact that PDNS-APP runs within the Planisys cloud does not mean that for a Reseller, their Resolvers and Authoritatives must do so in the same cloud. The Reseller can hire servers in different Public Clouds or in their own On-Premise Datacenters, so that Planisys can manage, install, and monitor their software components (pipeline CI/CD) that connect with the PDNS-APP application.
Here, an example is shown of a Reseller who chooses to locate their Resolvers and Recursives in different public clouds:
This graphic is a variation of the previous one, where the Reseller also chooses a Corporate Datacenter of their company or another along with Public Clouds:
PDNS-APP deployed On-Premise
In order to deploy the PDNS-APP application On-Premise, regardless of where the Recursive and Authoritative servers are deployed, you must have at least two VPSs (Virtual Private Servers) in the case of Redhat9 and one VPS for Debian/Ubuntu.
Taking the case of a single VPS, the measurements are:
16G - 4VCPU - 1000 to 5000 domains |
32G - 8VCPU - 5000 to 10000 domains |
64G - 16VCPU - 10000 to 25000 domains |
Note
In the On-Premise case, Planisys will provide a turnkey superadmin, that is, a login with the power to create Resellers with all the capabilities described above. If there are no real functioning Resellers, a Fake Single Reseller must still be created. If you do not want to delegate the operation to Client Companies, or if there are no Client Companies, a Client Company must still be created to assign the zones, even if it is a Fake Single Company. A superadmin has the power to create other superadmins.
From 20,000 or 25,000 domains, it becomes necessary to clusterize and have independent VPSs for MariaDB, for Bind9, and for the PDNS-APP code (3 VPSs), and in the case of high operation, use load-balancing and Galera-Cluster.
In the case of RedHat9, a subscription to the repositories is required for Planisys to install base components such as MariaDB, Python3, etc., and maintain an updated kernel. As of 2023, the alternatives are Debian11 and Ubuntu 22.04 (the Ubuntu 22.10 alternative is not viable because its support expires 9 months after the release).
Minimal installation for less than 10,000 domains
Note
Here, an installation on a single VPS is presented, with the sizing suggested above.
Warning
In this installation, the On-Premise provider is responsible for accumulating High Availability components, such as RAID disks, A+B electrical circuit, dual Internet upstream, periodic Snapshot Backups, using VMWare HA capabilities, configuring Proxmox HA Cluster with firmware fencing (IPMI/iDrac/APC) etc.
Installation for more than 25,000 domains
In this case, it is suggested to split the installation into more VPSs, use a load-balancer, and a Galera-Cluster with a quorum of 3 database servers.
It is an example of larger sizing, where Planisys delivers all the configured VPSs (including nginx/haproxy and Galera Cluster).
Note
In the graphic, the requirement for LoadBalancing according to sticky sessions is shown. This requirement to maintain the session based on the client’s originating IP and port is only necessary for the Web interface, since the API interface is stateless (does not have sessions) as it is based on the exchange of JSONs.
Warning
En el loadbalancer no debe usarse round-robin ni distribucion por carga cuando el upstream es la interfaz web. Cuando el upstream es la API el metodo mas conveniente es leastconn, es decir trata de cargar a los upstreams por igual basado en conexiones abiertas.
Ansible Jumphost (Pivot)
As part of the deployment, PDNS uses a jumphost, sometimes also called a pivot, where the orchestration tool Ansible runs. Through this tool, PDNS can support a large number of recursive and authoritative servers.
The orchestration is carried out to install the necessary components and the scripts for:
pipeline CI/CD |
monitoring |
log analysis |
alerts |
statistics |
This requires that the servers to be orchestrated have root permissions through the ssh public key of the Ansible pivot. This is done simply by adding the public key provided by Planisys to the servers to be orchestrated in the /root/.ssh/authorized_keys file.
That is, if a client/reseller or owner wants to provision authoritative or recursive servers, they can do so in the form of a container or virtual machine from any cloud, but they must give Orchestration Control to the PDNS Ansible pivot.
In this way, gradual deployments can be carried out, or even proofs of concept or PoC where PDNS-Cloud is used (in the Planisys Cloud).
NS-Set
An NS-Set or Nameserver Set is a group of authoritative servers, where one is configured as Master and the rest as Slave. The master server is the one that reconstructs the Bind zones from the information collected via Web and via API hosted in the database. The slave servers replicate the zones using the same protocol, using DNS NOTIFY to be notified of changes in the zones.
The NS-Set is a circle of trust that shares a TSIG key to avoid IP address spoofing.
On the other hand, at the company level, ACLs or Access Control Lists can be defined with transfer permissions (by IP or by TSIG), to exchange zones in both directions between the Master and External Bind9 Servers.
