Re: [sitefinder-tech-discuss] Pseudo code please

[Owen DeLong <owen@delong.com>]

> To be clear:  you have internal applications that have one code path for
> .com and .net and a separate code path for .biz, .edu, etc...?  This raises a bunch of questions:  Not that it happens all that often, but what do you do when new TLD's come on-line?  And where are you getting your spec on the TLD structure?  What are you doing for the ccTLD's?
No.  I have applications (internal and otherwise) which are not currently impacted by
activities in other domains which have chosen to implement wildcards.  They have
the same code path, but, due to usage patterns and other issues, the results of
wildcards in those domains are not problematic.  Whether you like it or not,
user expectation of behavior is an important issue in this, and, changing it without
approval of the community within the zone is not a good idea.

It doesn't matter how many times Verisign tries to rephrase the question to push
me into a hole where I can't make this clear.  Application behavior is _NOT_
the only issue.  Expected ZONE behavior is something users actually understand.
Also, the impact of wildcards in a zone with <=1,000 delegated sub-zones is a
bit less than .com or .net.  If you can't recogize that, then I suggest you
try the following experiment:

       Hand count the number of NS records in .MUSEUM.
       Hand count the number of NS records in .US
       Hand count the number of NS records in .COM
       Hand count the number of NS records in .NET

> > One of the problems is that a wildcard introduces new policy into
> > something that was previously assumed to be purely technical. VeriSign's
> > A record wildcard policy is that it provides a web site and a fake mail
> > server.  Another registry might have a completely different service they
> > make available.  How is a web browser supposed to know which is the
> > case?  Another problem is that wildcards have side effects.  VeriSign
> > incorrectly assumed that A records were used solely in order to connect
> > to the machine in question.  Therefore they assumed that if they
> > disallowed connections on other services, everything would be fine.
> > That's not true.  A records are also used to determine existence.  Sure,
> > the spec doesn't require that it work. But how many of the tens of
> > thousands of people who have written code that calls gethostbyname do
> > you think knew that?
>
> You'll get no argument here.  There do no appear to be guidelines for this.  However, VeriSign would be willing to participate in their creation.
Cool... I guess what is needed is a comment on the applicable RFC that
reads something like:

The operator of a ZONE which contains NS records for delegated sub-zones
within that ZONE MUST NOT incorporate wildcard records into that ZONE
without the consent of the overwhelming (>80%) majority of the points
of authority subsidiary to said zone.

The operator of a ZONE of public trust (.edu, .org, .com, .net) which
is operating it on behalf of ICANN/IANA in the best interests of the
internet MUST NOT make changes to the ZONE other than as prescribed
by ICANN/IANA.  This does not apply to sponsored TLDs where ICANN/IANA
has turned exclusive governance of those ZONES over to the ZONE holder
and such governance was established within the first 3 years of operation
of said ZONE.



Owen

Attachment: pgpTMiOsWDaJG.pgp
Description: PGP signature