Our DNS RPZ blocking policy is shaped to some extent by what is technically reasonable to implement.
Even if we tried to impose these blocks across the entire University, it would be easy for you to bypass them. So our realistic ambition is just to provide these blocks as a convenient default.
When evaluating a blocking mechanism, some key criteria are:
Scope: What set of hosts and users are affected?
These blocks apply to users of the central DNS resolvers run by the UIS; other DNS servers in the University might or might not perform similar blocking. Our recursive server information page has more details.
Granularity: How specific is the blocking? Will blocking one service also block others?
A block applies to a particular domain name. This means it isn't possible for us to block an individual web page: it is the whole web site or nothing. And a block applies to all protocols, not just HTTP. However, other domains pointing at the same IP address(es) are not affected.
Efficacy: How easy is it for a resource or service to avoid being blocked?
There is a rapid turnover in the domains used to host malware and phishing sites. The efficacy of these blocks depends to a large extent on new malicious domains being listed promptly.
The limited scope of the blocks also limits their efficacy - many University people frequently use non-University Internet connections which are not protected by these blocks.
Security: How does the blocking impact existing trust infrastructures?
The fundamental point of these blocks is to deny service to malicious sites. We redirect your browser to an explanatory web page to make it clear what is going on; this is a favour rather than an absolutely crucial feature. There are cases when it isn't possible for us to provide this explanation without undermining other security protocols (such as TLS / https and DNSSEC) so in those cases we prefer to just block, as we do for non-web protocols.