ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    Registrars Why .biz is the Spam TLD
    posted by tbyfield on Monday January 05 2004, @05:51AM

    jmason writes "Anyone with a passing interest in spam -- or its avoidance -- will have noted the massive preponderance of .biz URLs in those mails. Ever wondered why? Well, wonder no longer."



    Reportedly, the root nameservers for the .biz TLD can be updated in real-time, rather than waiting for a once-daily refresh as with other TLDs. If true, this is a killer feature for spammers, who regularly find their webservers and nameservers shut down in accordance with ISP AUPs -- and hence need to update their spamvertized domains ASAP."

     
      ICANNWatch Login  
    Nickname:

    Password:

    [ Don't have an account yet? Please create one. It's not required, but as a registered user you can customize the site, post comments with your name, and accumulate reputation points ("karma") that will make your comments more visible. ]

     
      Related Links  
    · jmason
    · More Registrars stories
    · Also by tbyfield
     
    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
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    What's Your Point?...
    by lextext on Monday January 05 2004, @08:58AM (#12814)
    User #6 Info | http://www.lextext.com
    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 EPP and the benefits are enormous
    by dmehus on Monday January 05 2004, @10:22AM (#12815)
    User #3626 Info | http://doug.mehus.info/
    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 ]
    You forgot that each record has a TTL
    by KarlAuerbach on Monday January 05 2004, @11:17AM (#12818)
    User #3243 Info | http://www.cavebear.com/
    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 ]


    Search ICANNWatch.org:


    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