For the moment, let us ignore the scary implications of the court's part in this and consider this from a technical perspective in a logical manner:
The hypothetical sub-domain abc.no-ip.org resolves to 1.2.3.4, a host somewhere that contains malicious payloads, is botnet C&C or is a member of a botnet. In any case, he's the bad guy - one of the people Microsoft are looking to exclude from the Internet.
So how can this be accomplished? Let's ignore for the moment that the bad guys are free to use any other dyndns service they please and assume that no-ip is the only one.
Approach 1
----------
Every time a host connects to no-ip to update its IP, Microsoft scans tcp & udp ports of the host looking for known C&C services, scans hosted data (public web or ftp). This will simply result in the bad guys hiding all of this in an undetectable manner, many bot-nets already use either Tor or SSH for C&C - without authentication it will be impossible to differentiate Joe Average with an SSH or Tor exit from the "targets".
As for scanning for content, this is possible assuming the content has to be public (ie. malicious payload) but even then, it's not practical - payloads can be hidden in anything and obfuscated beyond detection. Essentially all that's accomplished is another arms race based around signature detection for malicious content, with the disadvantage that unlike AV solutions this scanning is conducted remotely and the scan source is known. So the malicious guy with 2 or three lines just uses a stateful firewall to point microsoft's "scanning service" to good content, everyone else to the bad.
So what other options are there? A blacklist of IPs? Well, they're dynamic IPs, sooner or later you'll end up with every dynamic IP in the entire ipv4 range blacklisted as the bad dudes just release/renew.
Then there's banning the sub-domains/users! Also impractical because for each user and domain you ban, another will emerge.
Approach 2
----------
Microsoft resolves every request for abc.no-ip.org to their own service, all the time, this service performs stateful packet analysis before forwarding it on to the destination host. Impractical because you're essentially routing all no-ip traffic via Microsoft and once again you can only filter what you can detect -- and once the requests themselves are encrypted, that becomes impossible. This is effectively a MITM attack.
All the while we've assumed no-ip is the only alternative, it's not - and many others are beyond Microsoft and the courts jurisdiction. So ultimately the only way this "approach" could be temporarily feasible is if all Internet traffic were routed through Microsoft's service. So effectively you need to give control of every domain, TLD, ipv4 and ipv6 range to Microsoft. Not workable.
Someone is bound to point out that Microsoft's approach in this may be distributed, agents running on installs of their operating system which does address some aspects of my points above, but once again -- if Microsoft is capable of implementing effective detection on the workstation, remind me again why any of this is needed?
I must be missing something fundamental.