| At Large Membership and Civil Society Participation in ICANN |
|
|
|
|
|
This discussion has been archived.
No new comments can be posted.
|
Why .biz is the Spam TLD
|
Log in/Create an Account
| Top
| 13 comments
|
Search Discussion
|
|
The Fine Print:
The following comments are owned by whoever posted them.
We are not responsible for them in any way.
|
|
 |
That feature certainly would make it easier for spammers, but does that mean that the feature should be withdrawn? I wouldn't think so. Real time updating has benefits for the rest of the user community too, and I'm not aware of any way to distinguish between "good" uses of the feature and "wicked" uses.
-- Bret
|
|
|
[ Reply to This | Parent
]
|
|
|
 |
It's called the Extensible Provisioning Protocol, as opposed to the Registrar-Registry Protocol (RRP) used by VeriSign for COM and NET gTLDs. It allows for real-time updating at the TLD root and the registry Whois database (usually about 10 minutes of lag time). It's deployed for .org, .info, .biz, and the various sponsored TLDs including .pro, .name, .coop, and .aero. The CN and US ccTLDs also use it.
I believe the benefits of EPP are enormous and outweigh any negative consequences for spammers. Is it perfect? No, probably not. But neither is RRP, which can create up to 24 hours of down time, or at the very least it creates different outputs for visiting Web site users (depending on which NS they get during propagation), due to a change in the name server and frustrates the domain or Web site owner to no end.
Should EPP be repealed? Absolutely not. In fact, I would encourage a more rapid transition to EPP for COM and NET.
Cheers, Doug Doug Mehus
http://doug.mehus.info/ [mehus.info]
|
|
|
[ Reply to This | Parent
]
|
| |
|
 |
Even if a zone is updated, records that have been previously fetched from that zone will tend to still exist in the net for the duration of their TTL. This period can be several days or even weeks.
In addition, DNS zones are identified by a 32-bit number. The rate of republication of a zone ought not to exceed once every second or so else there is risk that that number will wrap. I have not experimented with zone identifier wrap issues but it wouldn't surprise me if some implementations didn't get the arithmetic right.
(Even at once per second, it takes about 70 years for a 32-bit counter to trigger the high order bit and another 70 years to reach roll over. There is a Y2K type issue in this regard waiting for us in about 34 years when the standard time_t value used in a mountain of code wraps - the precise time is 19-January-2038 at 3:14:07 AM GMT)
|
|
|
[ Reply to This | Parent
]
|
| |

Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their
respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com
|