Hi @smnheints,
This is quite a common problem with using FQDNs in firewall rules. As we know, FQDN rules work by performing a DNS lookup and using the resolved IP address to create a dynamic ACE/rule, which are temporary according to the DNS TTL as of course you've mentioned. This especially creates problems when clients and firewalls are using different DNS servers for their resolution, as they both may resolve different IP addresses at a given time. Ideally the firewalls and clients both use the same DNS server to prevent this disparity. However, that does not always fix the problem... there is still no guarantee (although in many cases it does work) that the responses will be identical even if both were using the same DNS server. This is especially the case when dealing with services that are fronted by CDNs. In the case for id.cisco.com connectivity is provided by Akamai CDN. There are certain domains where two clients could use the same DNS server, query an A record at exactly the same time, and it will return different IP addresses to both of them. Some firewalls have a DNS proxy functionality that can be enabled to synchronise the IP addresses that are used and injected to the policy engine of a firewall. Generally the firewalls have a built-in DNS client that can perform some form of DNS enumeration (like dig I suppose?) to properly retrieve all IP addresses which gets around the round-robin DNS problem.
To answer the question, it may be not be possible with using an FQDN rule. My only advice would be to make sure the client and the firewall are using the same DNS server. Check if the firewall can override the TTL for the specific FQDN - not many give this option from what I know. Usually, the suggestion when using firewalls is to permit traffic using a URL rule to either match on the URL (if decrypting and inspecting) or match on the certificate CN/SAN to match the traffic, which by nature can match on the subdomains too. Of course this may not be possible if using a simple L4 firewall. Possibly adjust the default TTL value, but that is a last resort I'd say. Overall it does depend on the firewall vendor you are using, as the capabilities/solutions to this problem are different between them. I could only really suggest the documentation as a concrete answer
