Some commentary on other replies.
@balaji.bandi has touched upon one of the classical issues in blocking traffic to another site not under your control, i.e. IPs might change (as first noted by @Blue_Bird ). His suggestion of using scripting, including possibly on-router scripting, to recurrently check DNS to block IP, and remediated IP on router, is a great way to avoid the need, in theory, to manually monitor and reconfigure the router if DNS to IP changes.
Oh, and BTW, another possible approach would be to block the DNS resolution for that name, but that would allow someone that otherwise knows the IP to get to the site.
An ACL blocking access might be used as an ingress or egress ACL. Generally, ACLs are recommended to be applied ASAP to avoid needless processing of packets that will be dropped. However, keep in mind, that as initial session setup packets will be dropped, such sessions won't be formed, i.e. most of to be blocked traffic would be the follow on session traffic, where you block the traffic probably matters little, except for convenience. For example, doing all the blocking in one place, such on the Internet connecting router (as as the ISP connecting interface, which you asked about), would likely be the easiest to maintain.
The logic also applies to using the null route approach too (i.e. you should only need to do that in the Internet connecting router).
In M02@rt37 's example ACL, he shows an ACE with the log option. Which is great for logging what host IP is attempting access, but, in theory, slightly more resource intensive (I recall, traditionally an ACL is more resource intensive than a null route), however, keep in mind what I wrote above, since sessions are being initially blocked, there shouldn't be a huge number of such packets to block to route to null. (In other words, again, don't worry about "efficiency">)
