FQDN filtering in Cloud Next Generation Firewall: A complete guide

Ever struggled with managing firewall rules for sites like Google? In the past, it meant manually listing every single IP address associated with your domain. Talk about a headache!

But guess what? Things just got a whole lot easier! With the new FQDN feature in Cloud Next Generation Firewall (NGFW), you can simply specify the domain name (like www.google.com) in your firewall rule. No more endless lists of IP addresses to keep track of!

In the dynamic landscape of cloud computing, security is paramount. Cloud NGFW offers a robust set of features to safeguard your infrastructure, and among them is the fully qualified domain name (FQDN) feature. FQDN adds an extra layer of flexibility and precision to your firewall rules, allowing you to enhance security measures while simplifying network management. Let’s explore how.

Understanding FQDN

Fully qualified domain names (FQDN) represent the complete domain name for a specific host on the internet that ultimately gets translated to an IP address when a connection to the host is established. 

In the context of Google Cloud NGFW Standard, FQDN enables users to create firewall rules based on domain names rather than just IP addresses. This introduces a more flexible approach to controlling network traffic, as it allows for rule definition based on specific services or applications hosted on those domains even when associated IP addresses change dynamically.

Benefits of using FQDN

• Improved reliability: FQDNs do not change when the underlying IP addresses change, such as traffic that’s routed through load balancers. This can help to reduce downtime and improve the reliability of your cloud workloads.

• Easier to use: FQDNs are more human-readable and easier to remember than IP addresses. This can make your firewall rules more readable and easier to maintain.

• Enhanced security: FQDNs can help to improve the security of your applications by making it more difficult for DNS spoofing attacks. 

Important considerations: What to know before you switch to FQDN

• FQDN objects must adhere to standard FQDN syntax by following supported domain name format.

• FQDN objects can be used in firewall policy rules within hierarchical, global, and regional network firewall policies to regulate traffic to or from specific domains.

• Cloud NGFW periodically updates firewall policy rules containing FQDN objects with the latest domain name resolution findings, based on the VPC name resolution order of Cloud DNS. Cloud DNS notifies Cloud NGFW of any changes in DNS records. These updates are consistent with underlying VMs which ensures egress control reliability.

• If multiple domain names resolve to the same IP address, the firewall policy applies to the IP address itself, treating FQDN objects as Layer 3 entities.

• In egress firewall policy rules, if a domain includes CNAMEs in the DNS record, ensure all potential aliases are configured to guarantee consistent policy enforcement during DNS record changes. Failure to include all relevant aliases may result in policy malfunction.

• Compute Engine internal DNS names can also be used in network firewall policy rules, provided that alternative name servers are not used in outbound server policy configurations.

• For incorporating custom domain names in network firewall policy rules, Cloud DNS managed zones can be utilized for domain name resolution. Ensure that alternative name servers are not configured in the VPC network's outbound server policy so that the records in managed zones are consulted.

Implementing FQDN filtering 

Follow below guides for detailed step by step implementation of firewall policies using FQDN:

• Implementing hierarchical firewall policies

• Implementing global firewall policies

• Implementing regional firewall policies

Understanding FQDN limitations

The following restrictions apply to both ingress and egress firewall rules employing FQDN objects:

• FQDN objects do not support wildcard (*) or top-level (root) domain names, such as *.example.com and .org.

• A domain name can resolve to a maximum of 32 IPv4 addresses and 32 IPv6 addresses. If DNS queries yield more than 32 IPv4 or IPv6 addresses, only the first 32 addresses are included. Therefore, avoid including domain names resolving to more than 32 IPv4 and IPv6 addresses in ingress firewall policy rules. However, note that this does not have any impact for using FQDN in egress firewall rules.

• Certain domain name queries yield unique answers depending on the location of the requesting client. Firewall policy rules perform DNS resolution in the Google Cloud region containing the VM to which the rule applies.

When incorporating FQDN objects into ingress firewall policy rules, be aware of the following limitations:

• Avoid using ingress rules utilizing FQDN objects if domain name resolution results are highly variable or if DNS-based load balancing is employed. For instance, numerous Google domain names utilize a DNS-based load-balancing scheme.

FQDN exceptions during DNS resolution

When using FQDN objects within firewall policy rules, you may encounter the following exceptions during DNS resolution:

• Bad domain name: If a firewall policy rule contains one or more domain names in an invalid format, an error occurs. The rule cannot be created unless all domain names are correctly formatted.

• Domain name does not exist (NXDOMAIN): If a domain name does not exist, Google Cloud disregards the FQDN object in the firewall policy rule.

• No IP address resolution: If a domain name fails to resolve to any IP address, the associated FQDN object is disregarded.

NOTE: Cloud NGFW considers NXDOMAIN and IP address resolution failure cases functionally identical.

• Unreachable Cloud DNS server: If a DNS server becomes unreachable, firewall policy rules employing FQDN objects apply only if previously cached DNS resolution results are accessible. Otherwise, the FQDN objects within the rule are ignored, either due to the absence of cached results or expiration of the cached DNS data.

Benefits

• Improved reliability: FQDNs do not change when the underlying IP addresses change, such as traffic that’s routed through load balancers. This can help to reduce downtime and improve the reliability of your cloud workloads.

• Easier to use: FQDNs are more human-readable and easier to remember than IP addresses. This can make your firewall rules more readable and easier to maintain.

• Enhanced security: FQDNs can help to improve the security of your applications by making it more difficult for DNS spoofing attacks. 

What’s next

• Dive into the docs: Start exploring the Google Cloud NGFW documentation for a deeper understanding of FQDN objects and firewall rules.

• Test it out: Create some FQDN objects and try implementing them in your own firewall rules. See how they simplify your workflow and enhance your security.

• Share your knowledge: Help others benefit from FQDN objects by sharing this article with your colleagues and network.

With FQDN objects in your toolkit, you're well on your way to a more secure and streamlined cloud environment. Enjoy the newfound ease and flexibility in your firewall management!