Filter
Top Products
Network > Address Objects
307
SonicOS 5.8.1 Administrator Guide
FQDN wildcard
support
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). Since most DNS
servers do not allow zone transfers, it is typically not possibly to automatically enumerate all the
hosts in a domain. Instead, the SonicWALL will look 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 which is also a configured/defined DNS server on the SonicWALL, the SonicWALL will
parse the response to see if it matches the domain of any wildcard FQDN AOs.
Note Sanctioned DNS servers are those DNS servers configured for use by the SonicWALL firewall. The
reason that responses from only sanctioned DNS servers are used in the wildcard learning process
is 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 Enhanced 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 later in the “Enforcing the use of sanctioned
servers on the network” section.
To illustrate, 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 will be examined by the
firewall, and will be matched to the defined “*.myspace.com” FQDN AO. The result
(63.208.226.224) will then be added to the resolved values of the “*.myspace.com” DAO.
Note If the workstation, client-A, in the example above had resolved and cached vids.myspace.com prior
to 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 will force the client to resolve all FQDNs,
allowing the firewall to learn them as they are accessed.
Wildcard FQDN entries will resolve all hostnames within the context of the domain name, up to
256 entries per AO. For example, “*.sonicwall.com” will resolve www.sonicwall.com,
software.sonicwall.com, licensemanager.sonicwall.com, to their respective IP addresses, but it
will 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, and would also resolve
sonicos-enhanced.demo.sonicwall.com, csm.demo.sonicwall.com,
sonicos-standard.demo.sonicwall.com, etc.
Note 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, will not be
functional.
FQDN
resolution
using DNS
FQDN Address Objects are resolved using the DNS servers configured on the SonicWALL in the
Network > DNS page. Since it is common for DNS entries to resolve to multiple IP addresses, the
FQDN DAO resolution process will retrieve all of the addresses to which a host name resolves,
up to 256 entries per AO. In addition to resolving the FQDN to its IPs, the resolution process will
also associate the entry’s TTL (time to live) as configured by the DNS administrator. TTL will then
be honored to ensure the FQDN information does not become stale.