Change to .com/.net behavior

Mailman List Mirror (Read Only)
1

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

2

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

  Feel free to point out the step that's stretching too far. There definitely
do exist security validation schemes that rely upon domain existence that
are fooled by Verisign's bogus reply.

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

  Then who does ICANN represent? Doesn't ICANN operate under the authority of
the DOC? Doesn't Verisign operate pursuant to a contract with ICANN? Aren't
we all intended third party beneficiaries of those contracts? Is this really
in dispute?

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

  I would hope that Microsoft would respond with a lawsuit rather than a
patch. Otherwise, Verisign will respond with a 'technical solution' and
we'll be in a war with the people we have to trust.

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?)

  It really depends upon the specifics of the contractual situation. What if
one of your customer's customers lets through some spam because Verisign
broke their validation check? And what if that person is sued? Now, where
does that leave you, aware of the problem and having not taken actions to
correct it that you could have taken?

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

  Yes, oviously they are much less clear to Verisign. I want to hear from
IANA how they feel about a.net being pointed to Verisign. Simply put,
Verisign is telling me that 'a.net' has address '64.90.110.11' and it does
not.

  DS

3

On 9/17/2003 1:55 PM Paul Vixie noted that:

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?)

I was with you up to this point. Behaviorally speaking, what Dave is doing is no different, in my mind, than what Verisign did when they rolled out their required upgrade this week. At least Dave's customers have the option of applying his "required upgrade" whereas those that don't are forced into Verisign's worldview.

It all works both ways - or should at least. This, as you pointed out in your "expectations" post is a big part of the "problem" we are trying to sort out.

4

It may be unclear who they are supposed to represent, but they
do the bidding of their funders. I'm going to go out on a limb
here and postulate that their decisions, therefore, are not
always in the best interests of the Internet Community.

5

Paul Vixie wrote:

... shouldn't they get to decide this for themselves?
     

<snip>

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.

In my eyes that is the whole issue. I believe that Verisign is holding the zones for the public internet and that they do have obligations to the public. Verisign does not.

Without the "for the public" justification, there is absolutely no moral ground for IANA,ICANN and Verisign to maintain this three way stranglehold on the contents/structure of the DNS system for the entire world population.

6

If there's a disagreement on this concept, we have *BIGGER* problems than
just DNS b0rkage.