We found an interesting bug in the SRS/competition system for splitting off
domain resellers such as TUCOWS.  It is fairly rare, and a bit confusing -
but we've demonstrated this twice, and have been told in "vague terms" that
"if we switched to network solutions" that it wouldn't happen again.

This error occurs with nameserver entries:

1. When you register nameservers with opensrs, these are updated in the NSI
registry and the root servers correctly.

2. However, the Network Solutions "Registrar" often fails to get these
changes in a timely manner, and are even sometimes updated with invalid
data.

3. Many foerign "registries", the Network Solutions Registrar themselves,
and many U.S. registrars use the Network Solutions "Registrar" as
"authoritative" for DNS servers.  This is for the purposes of validating
nameservers.  This is supposedly incorrect behavior, but it is a very common
practice, especially since the Network Solutions "Registrar" sells their
whois database to partners.

4. This problem occurs *only* for ISP's who use nameservers registered at
any registrar besides network solutions (IE: tucows) .  They will have
problems and numerous support headaches when their customers attempt to
register domains at Network Solutions or their partners (who are numerous
and account for a large portion of all domains sold).  Those customers will
get errors when attempting to register domains saying that the IP addresses
don't match - and will invariably call the ISP.

5. Network Solutions does not honor host record changes unless the domain
name was registered with them - so there is no way to fix the error.


Example:

    ns2.zoneedit.com (compare registry/root to the registrar entries - they
are different)
    ns5.zoneedit.com (compare registry/root to the registrar entries - they
are different)


Proposal that we're thinking of telling ICANN about:

I would propose that Network Solutions should be REQUIRED to sell accurate
information for nameservers to it's partners until a sufficient number of
these partners have switched to use the registry database as authoritative.

Can anyone see the holes in this error?  Is there something that we're
leaving out?

                        - Erik


Reply via email to