But then a month or two later the Akami cluster would change and I would have to reprobe/update all the IPs. My only solution was to setup a script to probe DNS for all the results over time and add them all to an IP address object group included in the do-not-decrypt rule. You can get around this doing URL inspection for normal rules, but for doing decryption bypass this is a major pain. So the end result is that you can never be certain that the PA and end client are going to have the same DNS results at the same time. 15 seconds after the PA first queried the FQDN in DNS, it refreshes again and gets yet another set of results, invalidating the first set.
But when the client does a nslookup a second or two later it gets 6 different results with a short TTL. With FFDNS this may be a half dozen results with a very short TTL, say 30 seconds (the PA will cache a maximum of 10 results I believe). The PA will do a DNS lookup for the FQDN object and cache the results. Basically, you can never insure the DNS result the firewall gets and the result the end client gets, will be the same. What you are describing is Fast Flux DNS. Do you think its only periodically pulling one IP but then the traffic is coming from one of their other IPs? Its on an akami CDN and we don't want to whitelist all of akami. Without knowing all of their IP's or knowing if they would ever change. Here's the thing, If I do an nslookup or go to and look it up across multiple DNS servers, it always gives a different IP address.
0 kommentar(er)
