FQDN address objects support wildcard entries, such as *.somedomainname.com, by first resolving the base domain name to all its defined host IP addresses, and then by constantly actively gleaning DNS responses as they pass through the firewall.

For example, creating an FQDN AO for *.myspace.com will first use the DNS servers configured on the firewall to resolve myspace.com to 63.208.226.40, 63.208.226.41, 63.208.226.42, and 63.208.226.43 (as can be confirmed by nslookup myspace.com or equivalent). As most DNS servers do not allow zone transfers, it is typically not possible to automatically enumerate all the hosts in a domain. Instead, the firewall looks for DNS responses coming from sanctioned DNS servers as they traverse the firewall. So, if a host behind the firewall queries an external DNS server that is also a configured/defined DNS server on the firewall, the firewall parses the response to see if it matches the domain of any wildcard FQDN AOs.

• Sanctioned DNS servers are those DNS servers configured for use by firewall. The reason is that responses from only sanctioned DNS servers are used in the wildcard learning process to protect against the possibility of FQDN AO poisoning through the use of unsanctioned DNS servers with deliberately incorrect host entries. Future versions of SonicOS might offer the option to support responses from all DNS server. The use of sanctioned DNS servers can be enforced with the use of access rules, as described in Enforcing the Use of Sanctioned Servers on the Network

• For example:

  • Assume the firewall is configured to use DNS servers 4.2.2.1 and 4.2.2.2, and is providing these DNS servers to all firewalled client via DHCP. If firewalled client-A performs a DNS query against 4.2.2.1 or 4.2.2.2 for vids.myspace.com, the response is examined by the firewall and matched to the defined *.myspace.com FQDN AO. The result (63.208.226.224) is then added to the resolved values of the *.myspace.com DAO.
  • If the workstation, client-A, had resolved and cached vids.myspace.com before the creation of the *.myspace.com AO, vids.myspace.com would not be resolved by the firewall because the client would use its resolver’s cache rather than issuing a new DNS request. As a result, the firewall would not have the chance to learn about vids.myspace.com unless it was resolved by another host. On a Microsoft Windows workstation, the local resolver cache can be cleared using the command ipconfig / flushdns. This forces the client to resolve all FQDNs, thereby allowing the firewall to learn them as they are accessed.

• Wildcard FQDN entries resolve all hostnames within the context of the domain name, up to 256 entries per AO.

  For example, *.sonicwall.com resolves www.sonicwall.com, software.sonicwall.com, and licensemanager.sonicwall.com, to their respective IP addresses, but it does not resolve sslvpn.demo.sonicwall.com because it is in a different context; for sslvpn.demo.sonicwall.com to be resolved by a wildcard FQDN AO, the entry *.demo.sonicwall.com would be required, which would also resolve sonicos-enhanced.demo.sonicwall.com, csm.demo.sonicwall.com, sonicos-standard.demo.sonicwall.com, and so on.

• Wildcards only support full matches, not partial matches. In other words, *.sonicwall.com is a legitimate entry, but w*.sonicwall.com, *w.sonicwall.com, and w*w.sonicwall.com are not. A wildcard can only be specified once per entry, so *.*.sonicwall.com, for example, is not functional.