Fully qualified domain name objects overview (original) (raw)

Fully qualified domain name (FQDN) objects contain domain names that you specify in the domain name format. You can use FQDN objects as sources for ingress rules or as destinations for egress rules in a hierarchical firewall policy, global network firewall policy, or regional network firewall policy.

You can combine FQDNs with other parameters. For details about source parameter combinations in ingress rules, seeSources for ingress rules. For details about destination parameter combinations in egress rules, see Destinations for egress rules.

FQDN objects supportCloud DNS response policies,VPC network-scoped managed private zones,Compute Engine internal DNS names, and public DNS zones. This support applies as long as the Virtual Private Cloud (VPC) network doesn't have an outbound server policythat specifies an alternative name server. For more information, see VPC network resolution order.

Map FQDN objects to IP addresses

Cloud Next Generation Firewall periodically resolves FQDN objects to IP addresses. Cloud NGFW follows the Cloud DNSVPC name resolution order in the VPC network that contains the firewall rule's targets.

Cloud NGFW uses the following behavior for IP address resolution:

• Support CNAME chasing. Cloud NGFW uses Cloud DNSCNAME chasing if the answer to a FQDN object query is a CNAME record.
• Program IP addresses. Cloud NGFW uses the resolved IP addresses when it programs the firewall rules that use FQDN objects. Each FQDN object can be mapped to a maximum of 32 IPv4 addresses and 32 IPv6 addresses.
  If the DNS answer for an FQDN object query resolves to more than 32 IPv4 addresses or more than 32 IPv6 addresses, Cloud NGFW limits the programmed IP addresses in the firewall rules to the first 32 IPv4 addresses and the first 32 IPv6 addresses.
• Ignore FQDN objects. If Cloud NGFW cannot resolve an FQDN object to an IP address, it ignores the FQDN object. In the following situations, Cloud NGFW ignores an FQDN object:
  • When NXDOMAIN answers are received. NXDOMAIN answers are explicit answers from a name server indicating that no DNS record for the FQDN object query exists.
  • When no IP address exists in an answer. In this situation, an FQDN object query doesn't result in an answer with an IP address that Cloud NGFW can use to program a firewall rule.
  • When Cloud DNS server is unreachable. Cloud NGFW ignores FQDN objects if a DNS server that provides the answer is unreachable.
    When an FQDN object is ignored, Cloud NGFW programs the remaining portions of a firewall rule, if possible.

Considerations for FQDN objects

Consider the following for FQDN objects:

1. Because FQDN objects map to and are programmed as IP addresses, Cloud NGFW uses the following behavior when two or more FQDN objects map to the same IP address. Assume you have the following two firewall rules that apply to the same target:
   • Rule 1: priority 100, ingress allow from source FQDN example1.com
   • Rule 2: priority 200, ingress allow from source FQDN example2.com
     If both example1.com and example2.com resolve to the same IP address, ingress packets from both example1.com and example2.com match the first firewall rule because this rule has a higher priority.
2. Considerations for using FQDN objects include the following:
   • A DNS query can have unique answers based on the location of the requesting client.
   • DNS answers can be highly variable when a DNS-based load balancing system is involved.
   • A DNS answer might contain more than 32 IPv4 addresses.
   • A DNS answer might contain more than 32 IPv6 addresses.
     In the preceding situations, because Cloud NGFW performs DNS queries in each region that contains the VM network interface to which the firewall rule applies, the programmed IP addresses in firewall rules don't contain all possible IP addresses associated with the FQDN.
     Most Google domain names, such as googleapis.com, are subject to one or more of these situations. Use IP addresses oraddress groups instead.
3. Avoid using FQDN objects with DNS A records that have a time to live (TTL) of less than 90 seconds.

Format domain names

FQDN objects must follow the standard FQDN format. This format is defined in RFC 1035,RFC 1123, andRFC 4343. Cloud NGFW rejects FQDN objects that include a domain name that doesn't meet all of the following formatting rules:

• Each FQDN object must be a domain name with at least two labels:
  • Each label must match a regular expression that includes only these characters: [a-z]([-a-z0-9][a-z0-9])?..
  • Each label must have a length of 1-63 characters.
  • Labels must be concatenated with a dot (.).
    Consequently, FQDN objects don't support wildcard characters (*) or top-level (or root) domain names, such as *.example.com. and .org, because these include only a single label.
• FQDN objects support Internationalized Domain Names (IDNs). You can supply an IDN in either Unicode orPunycode format. Consider the following:
  • If you specify an IDN in Unicode format, Cloud NGFW converts it to Punycode format before processing.
  • You can use the IDN converter to create the Punycode representation of an IDN.
  • The character limit of 1-63 per label applies to IDNs after conversion to Punycode format.
• The encoded length of a fully qualified domain name (FQDN) cannot exceed 255 bytes (octets).

Cloud NGFW doesn't support equivalent domain names in the same firewall rule. For example, if the two domain names (or Punycode representations of IDNs) differ at most by a terminal dot (.), Cloud NGFW considers them equivalent.

What's next

• Firewall policy rule components
• Google Threat Intelligence for firewall policy rules
• Address groups for firewall policies