Key Features of Dynamic Address Objects

The term Dynamic Address Object (DAO) describes the underlying framework enabling MAC and FQDN AOs. By transforming AOs from static to dynamic structures Firewall > Access Rules can automatically respond to changes in the network.

Initially, SonicOS Enhanced versions 4.0, 5.0, and 5.1 will only support Dynamic Address Objects within Access Rules. Future versions of SonicOS Enhanced might introduce DAO support to other subsystem, such as NAT, VPN, etc.

Feature	Benefit
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: Wild cards only support full matches, not partial matches. In other words, “.SonicWall.com” is a legitimate entry, but “w.SonicWall.com”, “w.SonicWall.com”, and “ww.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.
FQDN Entry Caching	Resolved FQDN values will be cached in the event of resolution attempt failures subsequent to initial resolution. In other words, if “www.moosifer.com” resolves to 71.35.249.153 with a TTL of 300, but fails to resolve upon TTL expiry (for example, due to temporary DNS server unavailability), the 71.35.249.153 will be cached and used as valid until resolution succeeds, or until manually purged. Newly created FQDN entries that never successfully resolve, or entries that are purged and then fail to resolve will appear in an unresolved state.
MAC Address Resolution using live ARP cache data	When a node is detected on any of the SonicWall’s physical segments through the ARP (Address Resolution Protocol) mechanism, the SonicWall’s ARP cache is updated with that node’s MAC and IP address. When this update occurs, if a MAC Address Objects referencing that node’s MAC is present, it will instantly be updated with the resolved address pairing. When a node times out of the ARP cache due to disuse (for example, the host is no longer L2 connected to the firewall) the MAC AO will transition to an “unresolved” state.
MAC Address Object Multi-Homing Support	MAC AOs can be configured to support multi-homed nodes, where multi-homed refers to nodes with more than one IP address per physical interface. Up to 256 resolved entries are allowed per AO. This way, if a single MAC address resolves to multiple IPs, all of the IP will be applicable to the Access Rules, etc. that refer to the MAC AO.
Automatic and Manual refresh processes	MAC AO entries are automatically synchronized to the SonicWall’s ARP cache, and FQDN AO entries abide by DNS entry TTL values, ensuring that the resolved values are always fresh. In addition to these automatic update processes, manual Refresh and Purge capabilities are provided for individual DAOs, or for all defined DAOs.
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.