Ensure that your Domain Name Server (DNS) is reliable and continuously available. If you cannot depend on your DNS to resolve the hostnames, do not use hostnames in zones.

Do not use zones that include hostnames to deny access, that is, do not use such zones in DenyServices. If PNS cannot resolve a hostname, it will omit the hostname from the zone. If the zone contains only a single hostname (because you want to use it to restrict access to a specific site), the zone will be empty, that will never match any connection. If you have a firewall rule that is more permissive than the DenyService you are using the zone with the hosname, this more permissive rule will be effective, permitting traffic you want to block. (For example, you create a rule that permits HTTP traffic to the Internet, and a DenyService to block HTTP traffic to the example.com hostname. If PNS cannot resolve the example.com hostname, then the broader, more permissive rule will permit traffic to the example.com site.)

If the hostname is resolved to an IP address that is explicitly used in another zone, then PNS will use the rule with the explicit IP address. For example, you have a zone that includes the example.com hostname, another zone that includes the 192.168.100.1/32 IP address, and you have two different rules that use these zones (Rule_1 uses the hostname, Rule_2 the explicit IP address). If the example.com hostname is resolved to the 192.168.100.1 IP address, PNS will use Rule_2 instead of Rule_1.

If more than one hostname is resolved to the same IP address, PNS ignores each hostname and logs an error message. For example, this means that you cannot use a hostname in a zone if the server uses name-based virtual hosting.

Zones are global in PNS, and apply to all firewalls of the site, so carefully consider every modification of a zone, and its possible side-effect.