If it blocks by intercepting DNS requests, the TTL on the DNS record will stay on the client until it expires (1hr) and once you can get there, it would stay that way even with a block rule until it expires. This makes sense. An app level block is done on a protocol layer and can be done immediately.
I don't think it works via DNS. I don't use the UDM's DNS resolution (I have a Pi-hole setup). But, if it does work via DNS, then that's easy to work around and wouldn't be a real block.
Perhaps the first implementation of blocking you saw was based on some form of filtering DNS for Yahoo...and since you got to Yahoo when the rule was off...DNS was cached...and subsequent page calls go through. That would also explain why the rule will eventually work again. I have ZERO clue what the implementation actually is...that would just be my speculation. Thanks again for posting these reviews...I waited to update today until I watched your video!!!
My expectation is that these rules should not be circumventable. It should be a hard block at the firewall/gateway for them to be truly effective; DNS is fairly easy to work around. Even with this hiccup I really like what they are doing with the rules. Much more approachable than a traditional firewall rule, and the app groups are great. When I first started playing with it, I thought it might be DNS based because I don't use Unifi DNS (I use pi-hole), but then it started working... It's possible that domain rules are cached on the UDM-Pro, that would explain the lag, but I'm also grasping for an explanation :).
@@azzibee Sorry to hear that. I've had that problem with Protect with some previous releases, but both 2.0.0+ and the UDM's FW were super smooth for me. When I had issues, I was generally able to get the camera to stop bouncing by physically removing power for 30 seconds and then plugging them back in. If you haven't already tried that, might be worth a shot. LMK if you get them working. Looks like my optimism around UI software quality improvements wasn't warranted...
If it blocks by intercepting DNS requests, the TTL on the DNS record will stay on the client until it expires (1hr) and once you can get there, it would stay that way even with a block rule until it expires. This makes sense. An app level block is done on a protocol layer and can be done immediately.
I don't think it works via DNS. I don't use the UDM's DNS resolution (I have a Pi-hole setup). But, if it does work via DNS, then that's easy to work around and wouldn't be a real block.
Perhaps the first implementation of blocking you saw was based on some form of filtering DNS for Yahoo...and since you got to Yahoo when the rule was off...DNS was cached...and subsequent page calls go through. That would also explain why the rule will eventually work again. I have ZERO clue what the implementation actually is...that would just be my speculation.
Thanks again for posting these reviews...I waited to update today until I watched your video!!!
My expectation is that these rules should not be circumventable. It should be a hard block at the firewall/gateway for them to be truly effective; DNS is fairly easy to work around. Even with this hiccup I really like what they are doing with the rules. Much more approachable than a traditional firewall rule, and the app groups are great.
When I first started playing with it, I thought it might be DNS based because I don't use Unifi DNS (I use pi-hole), but then it started working... It's possible that domain rules are cached on the UDM-Pro, that would explain the lag, but I'm also grasping for an explanation :).
Since upgrading my protect system is constantly disconnecting my cameras and reconnecting. A real pain
Thanks for letting us know. Are you running the latest version (2.0.1) of Protect? 1.12.22 includes an older version (dunno why).
@@MissingRemote latest version of protect]. issues started after i upgraded to the latest firmware on the dream machine pro
@@azzibee Sorry to hear that. I've had that problem with Protect with some previous releases, but both 2.0.0+ and the UDM's FW were super smooth for me. When I had issues, I was generally able to get the camera to stop bouncing by physically removing power for 30 seconds and then plugging them back in. If you haven't already tried that, might be worth a shot. LMK if you get them working. Looks like my optimism around UI software quality improvements wasn't warranted...