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.
OnPremise Requirements
To deploy an OnPremise installation, Virtual or Physical Machines are required with
RedHat9 with Fedora ISC package |
Ubuntu22 with ISC package |
Debian12 with native 9.18.24 package |
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).
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.
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.
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 2024-08-15