... shouldn't they get to decide this for themselves?
Returning NXDOMAIN when a domain does not exist is a basic requirement. Failure to do so creates security problems. It is reasonable to require your customers to fix known breakage that creates security problems.
that sounds pretty thin. i think you stretched your reasoning too far.
VeriSign has a public trust to provide accurate domain information for the COM and NET zones. They have decided to put their financial interest in obscuring this information ahead of their public trust.
i'm not sure how many people inside verisign, us-DoC, and icann agree that COM and NET are a public trust, or that verisign is just a caretaker. but, given that this is in some dispute, it again seems that your customers should decide for themselves which side of the dispute they weigh in on.
Microsoft, for example, specifically designed IE to behave in a particular way when an unregistered domain was entered. Verisigns wildcard record is explicitly intended to break this detection. The wildcard only works if software does not treat it as if the domain wasn't registered even though it is not.
then microsoft should act. and if it matters to you then you should act. but this is not sufficient justification to warrant a demand by you of your customers that they install a patch (what if they don't run bind?) or that they configure delegation-only for particular tld's (which ones and why not others?)
Verisign has created a business out of fooling software through failure to return a 'no such domain' indication when there is no such domain, in breach of their public trust. As much as Verisign was obligated not to do this, others are obligated not to propogate the breakage. ISPs operate DNS servers for their customers just as Verisign operates the COM and NET domains for the public.
the obligations you're speaking of are much less clear than you're saying.