> ... 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
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
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.