Verisign Responds

> > > > > Courts are likely to support the position that Verisign has control of .net
> > > > > and .com and can do pretty much anything they want with it.
> > > > ISC has made root-delegation-only the default behaviour in the new bind,
> > > > how about drafting up an RFC making it an absolute default requirement for
> > > > all DNS?
> > > That would be making a fundamental change to the DNS
> > > to make wildcards illegal anywhere. Is that what you
> > > want?
> > no it wouldnt. it would ust make wildcards illegal in top level domains,
> > not subdomains.
> really? and how would that work? (read be enforced...)

Well yes thats part of the problem. It looks like verisign doesnt care
what anyone (ICANN, IAB, operators) thinks. But if we can mandate via RFC
it for dns software (servers, resolvers) etc. Then we go a ways to
removing verisign from the equation. Verisign can do what they like,
everyone will just ignore their hijacking.

  lets try this again... why should a valid DNS protocol element
  be made illegal in some parts of the tree and not others?
  if its bad one place, why is it ok other places?

--bill

  lets try this again... why should a valid DNS protocol element
  be made illegal in some parts of the tree and not others?
  if its bad one place, why is it ok other places?

because some engineers think that all social and business problems
can be solved by technical hacks. it's the godess's revenge for
the lawyers who think all engineering problems can be solved at
layer nine.

randy, who will go back to work now

Well one point is from http://www.icann.org/tlds/ only domains classed as
'sponsored' previously had wildcards. Domains that are unsponsored including
.net and .com are supposed to operate under policy established from the global
community thro ICANN.

Also this is a specific case, .net/.com have legacy implications and no one
including Verisign is naive enough to believe that this would have been ok.

This is why they have done it in the way they have without consultation. A
number of people claim they are acting in breach of their charter with ICANN,
sure (Randy) this is a social argument, but theres technical ones as well but
they dont stand up so well in the courtroom..

Steve

There's a simple answer and a not so simple. The simple answer is because in one part of the tree it was expected by all players up front, and in the other it wasn't. However in general I tend to agree. The things that Verisign broke (and which have cost my company several thousand dollars in lost time and unplanned programming tasks, never mind the increase in spam) are also broken by other TLDs that use wildcards. The issues weren't clear because the impact was small. Now that they are clear, those decisions should also be revisited.

Dunno about some engineers, but engineers in general can do a lot to avoid
creation of many problems in the first place. This wildcard flop is a
perfect example of a bad design decision coming back to bite.

I'd say that engineers pay too little attention to the social and business
implications of their decisions.

--vadim

>
> > > > > > Courts are likely to support the position that Verisign has control of .net
> > > > > > and .com and can do pretty much anything they want with it.
> > > > > ISC has made root-delegation-only the default behaviour in the new bind,
> > > > > how about drafting up an RFC making it an absolute default requirement for
> > > > > all DNS?
> > > > That would be making a fundamental change to the DNS
> > > > to make wildcards illegal anywhere. Is that what you
> > > > want?
> > > no it wouldnt. it would ust make wildcards illegal in top level domains,
> > > not subdomains.
> > really? and how would that work? (read be enforced...)
>
> Well yes thats part of the problem. It looks like verisign doesnt care
> what anyone (ICANN, IAB, operators) thinks. But if we can mandate via RFC
> it for dns software (servers, resolvers) etc. Then we go a ways to
> removing verisign from the equation. Verisign can do what they like,
> everyone will just ignore their hijacking.
>

  lets try this again... why should a valid DNS protocol element
  be made illegal in some parts of the tree and not others?
  if its bad one place, why is it ok other places?

--bill

Because of who is affected by the element. At the TLD level, many are
affected, at the domain level, then its a much smaller subset.

Ultimately, as Randy has already said, it is a business and social
problem. From a business standpoint, why should an organization be forced
to use its own resources to work around Verisign's plan to put more money
in its own packet.

From a social aspect, since Verisign has grown to be one of the most hated

(a decidedly non-business adjective) and distrusted organizations
existing. It pisses people off that they have found an unfair advantage to
use resources in bad faith, to generate revenue from people's typos and
ignorance. It smacks of being unethical, underhanded, illegal, and
generally the opposite of generating revenue by providing a quality
service to your loyal customers.

The technical hacks are a testament to our culture and provide instance
gratification while the slower moving social and business issues are
worked it. They help to gratify the emotional need to generally do the
right thing.

andy

Bingo!

Folks,

        lets try this again... why should a valid DNS protocol element
        be made illegal in some parts of the tree and not others?
        if its bad one place, why is it ok other places?

There very much _is_ an operational issue here, but it needs to be
characterized very carefully.

To that end, the IAB note is nicely careful and, I think, exactly right in
classifying a core "coordination" problem that comes with wildcarding.
Standards are, after all, about coordinating details among independent
participants.

The problem with wildcarding a gTLD is not that the construct
should be made illegal but that it requires a degree of coordination that was
not attempted. In this regard, the sponsored TLDs are not a problem
specifically because they are run in a more heterogeneous manner.

The IAB note captures this quite with:

     In particular, we recommend that DNS wildcards should not be used in a
     zone unless the zone operator has a clear understanding of the risks, and
     that they should not be used without the informed consent of those
     entities which have been delegated below the zone.

d/