Introduction to PDNS
PDNS is a product for managing DNS, both authoritative and recursive.
Usage Modes
The product is deployed in two modes: Cloud and OnPremise.
In the Cloud mode, each client receives a Reseller account, from which administrative logins can be created to set up Companies and within them, DNS Zones.
In the OnPremise mode, the client receives a SuperAdministrator account and has the additional ability to create Resellers, who can in turn create Companies that can create Zones.
Both schemes align with the concept of Multi-tenancy, which allows for granular permissions and delegation of responsibilities.
In both cases, an HTTPS Web interface, an HTTPS API, and at least two authoritative Bind9 servers are available, optionally along with one or more recursive Bind9 servers or resolvers.
How to forward to the Planisys cloud IP using unbound
If you already have one or more unbound servers in your own on-premise cloud, and want to forward everything not found in unbound’s cache, apply the following configuration in unbound:
server:
interface: 0.0.0.0 # listen on all interfaces
access-control: 0.0.0.0/0 allow # or restrict to your network
# Forwardear todos los DNS queries que no estén en caché a través de Planisys
forward-zone:
name: "."
forward-addr: <PLANISYS_IP>
Note
las direcciones IP cliente logueadas, serán las de los servidores unbound, perdiéndose el rastro de cual es la verdadera IP cliente
OnPremise Requirements
To deploy an OnPremise installation, Virtual or Physical Machines are required with
Debian12 con paquete nativo 9.18.24+ |
In this way, we ensure versions of
ISC Bind 9.18.24 or higher |
Python 3.9 or higher |
MariaDB 10.5 or higher, |
as well as kernels with modern cryptographic capabilities, e.g., excluding deprecated protocols like SHA1, or using SHA256 as the default.
Virtual machines can be KVM from Openstack or Proxmox, VMWare, or VirtualBox.
Obviously, virtual servers from Public Clouds such as AWS, Google Cloud Platform, Azure, Linode, etc., can be used.
Warning
The version of Bind used by PDNS since September 2022 is 9.16.33, which fixes CVE-2022-2906, CVE-2022-3080, CVE-2022-38177, and CVE-2022-38178. However, starting in February 2024, we use version 9.18.24 which fixes Keytrap, the resolver exploit that recognizes DNSSEC (CVE-2023-50387).
Note
El motivo por el que utilizamos la distribución Bind9 de Debian12 (o a partir de noviembre 2025 Debian13 Trixie), es porque es la versión OFICIAL de Internet Software Consortium , la empresa con la cual colabora Planisys para el desarrollo de bind9 y es la que contiene DNSTAP lo que nos permite realizar Log Shipping
Recursive Servers
The deployment of recursive servers or Resolvers is also done OnPremise, in the Planisys Cloud, or in other Public Clouds, with the same operating system requirements.
In the case of Resolvers, one or more Load-Balancers are used to balance traffic over recursive servers in UDP and TCP, allowing protocols such as DNS-over-HTTPS and DNS-over-TLS, and balancing according to the load distribution measured in QPS or Queries-Per-Second distributed among the Resolvers.
Warning
It should be noted, however, that while DoH and DoT are protocols that improve browsing privacy on exposed public networks (e.g., public Wifi), they can also be dangerous in polymorphic viruses that within an organization make DNS queries to execute Command & Control functions. The deployment of DoH and DoT protocols should be done within the framework of a Cybersecurity policy with a risk assessment or Risk Assessment. The risk lies in providing malware with a means to camouflage and blend with legitimate traffic.
Note
Using DNS-over-HTTPS and DNS-over-TLS is recommended on corporate laptops/portables/tables/mobiles that operate physically outside the corporate environment.
Warning
Todas las instalaciones deberán contar con un certificado SSL para el TLS, que es parte de la instalacion. El mantenimiento (reemplazo del certificado) correrá a cargo del Operador que deberá realizar un rndc reconfig y rndc reload despues del cambio En caso de existir sobrecarga se deberá realizar systemctl restart named lo que provocará una interrupción temporaria del servicio. Se recomienda realizar estos cambios en ventana de mantenimiento.
If deploying more than one Load-Balancer, it is recommended to use resolv.conf options to minimize timeouts and allow round-robin distribution among the LBs.
The installation of RPZ or Response Policy Zones with more than 500k malicious domains as part of Zero-Day Feed is an optional product that operates as Endpoint Protection.
However, a list of domains can be configured for which the Load-Balancer provides a direct negative response, as part of the PDNS product.
Another optional feature within PDNS is to provide a Blackhole Landing, which is a web page where one lands with the web browser when resolving certain domains provided by the client manually via the PDNS web interface, to include them in RPZ. This optional product is useful as Endpoint Protection for browsing, e.g., to catch malicious links sent by SMS or WhatsApp or emails or even within a web page. Its effectiveness has been tested in massive SMS attacks on large corporations to minimize the impact.
User Roles
There are 4 possible roles:
Superadministrator |
Reseller Administrator |
Reseller Operator |
Company Operator |
The Superadministrator can create, delete, and modify any of the users with lower roles, but cannot modify or delete other Superadministrators.
NS-Sets and Authoritative Nameservers
An NS-Set is a group of authoritative servers that share a TSIG SHA-256 key for zone transfers from a primary to secondary servers. Every domain is delegated to a group of authoritative servers, for which NS records are declared within the same zone.
The primary server has a CI/CD pipeline that instantly reflects changes made via WEB or API in the zones, in the zone list, or in ACL configurations to allow zone-transfers, and notifies the secondary servers if there are changes in the zone records via the DNS NOTIFY protocol.
The secondary servers also have a similar CI/CD pipeline, to eventually reconfigure if there are changes in the zone list or in the ACL transfer permissions.
Zone transfer permissions, when dealing with Master zones (i.e., those delegated to an NS-SET), are established based on a secret TSIG apart from IPs as an anti-spoofing measure, because the zone is also transferred with a signature or hash that uses the TSIG key.
When declaring an authoritative server for a zone, we must ensure that it is registered with ICANN. For this, we consult the website https://webwhois.verisign.com/webwhois-ui/index.jsp?language=en_US# and enter the nameserver name to which we want to delegate a domain.
If the nameserver we want to use is not listed as valid, we must declare its name and IP address in the Registrar where the domain was purchased, e.g., Godaddy, Gandi, Verisign, etc.
If you want to delegate a domain, e.g., xyzabc.com, to nameservers dns1.xyzabc.com and dns2.xyzabc.com, these nameservers are known as Glue Records because they belong to the same domain they serve as authoritative for. Of course, they must be declared in the Registrar before delegating the domain to them.
The user must verify, before creating an NS-SET or list of authoritative servers, that they are declared with ICANN, otherwise an error will occur when trying to resolve the zone. Although PDNS allows defining authoritative servers, it has no way of verifying that they are declared with ICANN.
ACLs
An Access Control List is a list of CIDR blocks or IP addresses (ipv4 or ipv6), and possibly TSIG keys, to apply as permissions so that a zone under our administration can be transferred to an external server.
The transfer action is known as AXFR, and by default is completely denied, so a list of authentication conditions must be explicitly provided.
The purpose of an ACL is to apply it to a zone to allow it to be transferred to a server outside our networks, for example, if a client requires having a copy of their zones on their own servers.
This case occurs when a domain is marked as allowed to transfer, in which case it is mandatory to assign an ACL to determine what the transfer permissions are. The “transfer permissions” are requirements that the server requesting the content of a zone must meet (there must be a match in the ipv4 address, ipv6 address, or TSIG key, which is usually a hash generated via SHA256).
In case you want to massively mark a large number of domains as allowed to transfer with an ACL, it is more convenient to use the PDNS API rather than doing it through the Web interface.
Reverse Zones vs Direct Zones
A reverse zone is a zone that has PTR records to specify reversals of IP addresses in both IPv4 and IPv6. During the web setup, the block for which reverse lookup is desired is specified in CIDR format, and PDNS translates it to in-addr.arpa format. Reverse zones also obligatorily require SOA (mandatory Start-Of-Authority) and NS (Nameserver) records.
A direct zone can contain, in addition to the mandatory SOA and NS, records of type CAA, SRV, A, AAAA, TXT, CNAME, ALIAS or DNAME (similar to CNAME but allowed at the top or Apex of the zone, resolved by a Resolver) and MX.
These records are known as RRs or Resource Records.
Zone Delegation
The delegation of a domain under a TLD (such as .com, .co, or .ar), as well as the delegation of sub-TLDs (e.g., com.ar), must be done at the appropriate Registrar. The same applies to reverse zones, for example, by visiting www.lacnic.net to delegate reverse resolution to the corresponding nameservers.
NS records must not point to a CNAME
In the Domain Name System (DNS), NS (Name Server) records are essential for domain delegation, as they indicate which servers are responsible for answering queries about a specific zone. However, according to DNS standards, an NS record must never point to a CNAME (alias).
This is prohibited by RFC 1912 (Section 2.4) and RFC 2181 (Section 10.3), due to the resolution issues it may cause.
RFC 2181 (Section 10.3)
Why is this configuration not allowed?
Delegations must be direct
An NS must always point to a hostname with an A or AAAA record, not to a CNAME.
Risk of resolution loop
Some resolvers do not follow CNAMES in NS delegations, which can cause the domain to become unresolvable.
Inconsistency between TLD delegation and final resolution
The TLD delegates to an NS that is actually a CNAME, causing discrepancies that may prevent some users from resolving the domain correctly.
Using CNAME in NS records is a serious error and must be avoided. Whenever a name server is configured, ensure that NS records point to names with valid A or AAAA records. Otherwise, the domain may become inaccessible to some users and cause resolution issues throughout the DNS infrastructure.
Lame delegations
On the other hand, the authoritative servers that a zone resolves to according to the Registrar must all respond with at least the same set of NS records as declared at the registrar. We say at least because authoritative servers can include stealth servers, meaning servers that are added but not listed at the Registrar.
These stealth servers must also ensure that the NS record set matches the one used by the declared nameservers. Even though stealth servers are not declared at the registrar, they must maintain consistency in their NS configuration to avoid issues.
If any nameserver, whether declared or stealth, does not respond with the complete set of NS records, we have a lame delegation. That means a query may fail depending on which resolver is used.
- For a delegation to be valid, all authoritative nameservers of a zone must respond with the same set of NS records as declared at the domain’s registrar. However, a lame delegation occurs when:
An authoritative server listed at the registrar does not respond correctly or lacks the expected NS records.
A stealth server (an additional authority not listed at the registrar) does not maintain consistency in the NS records.
A resolver may receive inconsistent responses depending on which server replies, resulting in intermittent resolution failures.
The world of resolvers
When rules are established to avoid lame delegation or to prohibit CNAMEs in NS records, they are not aimed at public resolvers, but rather at the hundreds of millions of CPEs or ADSL/Fiber routers running a resolver that comply with the RFCs.
Many times, Public Resolvers do not adhere to the aforementioned RFCs in order to simplify resolution for end users. However, this has the downside of hiding delegation issues. It may mask real problems and give the false impression that a domain works correctly, when in fact it has configuration errors.
This issue affects not only small resolvers, but also corporate environments and Internet providers that implement stricter resolvers.
Recommendations to Avoid Lame Delegations
- To ensure correct delegation and avoid resolution issues, it is essential to:
Maintain consistency in NS records:
- All nameservers must return the same set of NS records, both those declared at the registrar and stealth ones.
Verify delegation using DNS tools:
- It is recommended to use tools like dig, nslookup, or dnsviz.net to detect delegation discrepancies.
Avoid misconfigured stealth servers:
- If stealth nameservers are added, ensure that they reflect exactly the same information as the servers listed at the registrar.
Test with different resolvers:
Do not rely solely on public resolvers. Test with resolvers from different ISPs and enterprise environments to detect possible failures.
DNSSEC Zones
PDNS supports DNSSEC and allows obtaining via web the necessary information to provide the parent domain with a DS record with the items linking to the DNSKEY record to have a verified parent/child inheritance chain (Chain of Trust):
Domain |
Algorithm (e.g., ECDSAP256SHA256) |
Hash Algorithm (typically SHA256) |
Hash |
KeyTag |
These are the data that a Registrar typically requests when we buy a domain and want it to have DNSSEC, as a DNSKEY record containing the public key that signs the zone must be published, and the DS record in the parent zone must contain a hash of that public key. This is known as Chain of Trust.
When a zone is marked as DNSSEC, PDNS automatically creates a key pair (public and private), securely storing the private one, and publishing the public one in the DNSKEY record. This is known as ZSK or Zone-Signing-Key.
Resolvers, when resolving records from a DNSSEC zone, verify the authenticity of the obtained records using the public key from the DNSKEY. The primary authoritative server, upon each addition or change of records (Resource Records), signs the record using the private key of the ZSK.
Note
DNSSEC uses public key cryptography or PKC to verify the authenticity of the data (verifying the sender) and their integrity (ensuring they were not modified while being transported over the Internet). However, this should not be confused with privacy, as DNS records are transported in clear text, unless query protocols like DNS-over-TLS or DNS-over-HTTP are used.
Chain of Trust
The process that occurs, for example, when we want to access a website from a PC, Mac, Cell Phone, or Tablet, is that we need a DNS Resolver to translate a name, e.g., www.planisys.com, to an IP address (ipv4 or ipv6, depending on the network where our device is).
So that the resolver, when attempting to obtain the IP address of www.planisys.com, is not poisoned by a malicious attacker (Cache Poisoning), a chain of trust is established through authenticated delegation records via DNSSEC, allowing it to reach one of the authoritative servers for the domain planisys.com, which will provide the correct response.
The Resolvers provided by PDNS have DNSSEC validation enabled to verify the Chain of Trust.
Languages
The PDNS web interface is currently available in Spanish, English, and Portuguese. You can access the language settings in Settings by clicking on the icon at the top right.
Última actualización en 2025-07-14