The DNS-based ACLs are used for wireless client devices. When using these devices, you can set pre-authentication ACLs on the embedded wireless controller to determine the data requests that are allowed or blocked.

To enable DNS-based ACLs on the embedded wireless controller, you need to configure the allowed URLs or denied URLs for the ACLs. The URLs need to be pre-configured on the ACL.

With DNS-based ACLs, the client when in registration phase is allowed to connect to the configured URLs. The embedded wireless controller is configured with the ACL name that is returned by the AAA server. If the ACL name is returned by the AAA server, then the ACL is applied to the client for web-redirection.

At the client authentication phase, the AAA server returns the pre-authentication ACL (url-redirect-acl, which is the attribute name given to the AAA server). The DNS snooping is performed on the AP for each client until the registration is complete and the client is in SUPPLICANT PROVISIONING state. When the ACL configured with the URLs is received on the embedded wireless controller, the CAPWAP payload is sent to the AP enabling DNS snooping for the URLs to be snooped.

With URL snooping in place, the AP learns the IP address of the resolved domain name in the DNS response. If the domain name matches the configured URL, then the DNS response is parsed for the IP address. The AP adds the IP address to the allowed list of IP addresses and thus the client can access the URLs configured.

During pre-authentication or post-authentication, DNS ACL is applied to the client in the access point. If the client roams from one AP to another AP, the DNS learned IP addresses on the old AP is valid on the new AP as well.

This feature supports:

• A maximum of 32 URL lists.

• A maximum of 32 URLs per URL list.

• Up to 30 IP addresses per URL.

• A maximum of 16 URL lists with wild-cards.

• A maximum of 10 URLs per wild-card URL.

Note	When configuring wild-card based URLs, generic wild-card URLs are not allowed; wild-cards cannot be present between the domain name; multiple wild-cards are not allowed in a URL. Wild-card specification in a URL can only be at a third-degree level or a higher level.

Note	Conflicting or invalid configurations are not allowed. The same URL cannot have different actions. For example, Deny and Allow cannot be configured on www.yahoo.com.

Note	URL filter needs to be attached to a policy profile in case of the local mode. In the flex mode, the URL filter is attached to the flex profile and it is not need to be attached to a policy profile.

Note	DNS based URLs work with active DNS query from the client. Hence, for URL filtering, the DNS should be setup correctly.

Note	URL filter takes precedence over punt or redirect ACL, and over custom or static pre-auth ACL.s

The restriction for DNS-based ACLs is as follows:

• Only supported for FlexConnect local switching APs with Central Authorization.

• Post-Auth DNS based ACL is not supported for FlexConnect with local Authorization when AP is in FlexConnect local switching mode.

• Fully qualified domain name (FQDN) or DNS based ACLs are not supported on Cisco Wave 1 Access Points.

• The URL filter considers only the first 20 URLs, though you can add more.

• The URL filter employs regular regex patterns and permits wildcard characters only at the beginning or at the end of an URL.

• The URL ACLs are defined and added to the FlexConnect policy profile in which they associate with a WLAN. The URL ACL creation follows a similar mechanism as that of local mode URL ACLs.

• In FlexConnect mode, the URL domain ACL works only if they are connected to a FlexConnect policy profile.

• The ACL can be attached to a WLAN by associating a policy profile with a WLAN or local policies. However, you can override it using "url-redirect-acl".

• For the Cisco AV pair received from ISE, the policy that needs to be applied for a particular client is pushed as part of ADD MOBILE

  message.

• When an AP joins or when an existing URL ACL is modified and applied on FlexConnect profile, the ACL definition along with mapped URL filter list is pushed to the AP.

• The AP stores the URL ACL definition with mapped ACL name and snoops the DNS packets for learning the first IP address for each URL in the ACL. When the AP learns the IP addresses, it updates the controller of the URL and IP bindings. The controller records this information in the client database for future use.

• When a client roams to another AP during the pre-authentication state, the learned IP addresses are pushed to a new AP. Otherwise, these learned IP addresses are purged when a client moves to a post-authentication state or when the TTL for the learned IP address expires.