Verisign's DoS attack on the Internet - TCP-IP

This is a discussion on Verisign's DoS attack on the Internet - TCP-IP ; In yet another example of egregorious abuse of the monopoly power that the U.S. gov't foolishly granted them, NetSol/Verisign has started to return A records for any invalid domains. Does anyone happen to know a way to filter these out ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Verisign's DoS attack on the Internet

  1. Verisign's DoS attack on the Internet

    In yet another example of egregorious abuse of the monopoly power that
    the U.S. gov't foolishly granted them, NetSol/Verisign has started to
    return A records for any invalid domains.

    Does anyone happen to know a way to filter these out to restore the
    proper functioning of just about any kind of software, including spam
    filtering?

    -hpa
    --
    at work, in private!
    If you send me mail in HTML format I will assume it's spam.
    "Unix gives you enough rope to shoot yourself in the foot."
    Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

  2. Re: Verisign's DoS attack on the Internet

    In article , hpa@zytor.com says...
    >
    >In yet another example of egregorious abuse of the monopoly power that
    >the U.S. gov't foolishly granted them, NetSol/Verisign has started to
    >return A records for any invalid domains.
    >
    >Does anyone happen to know a way to filter these out to restore the
    >proper functioning of just about any kind of software, including spam
    >filtering?


    First off, any filtering mechanism will likely be a kludge, and a poor one
    at that. VeriSign can easily change the IPs for the wildcard and no matter
    how good the fixes are, some software will fail...especially given that a
    lot of software has been written in the past 15+ years expecting a
    particular behavior, which VeriSign has single-handily changed overnight!

    Anyways, changing gears a bit...

    What would happen if I added some IMG SRC tags to webpages we serve that
    point to unregistered domain names? ... between all the sites I operate
    that could easily drive several million hits to semi-random unregistered
    domains everyday. If others did the same, things could get interesting!

    Before someone says this is a DoS...remember, the mere reference of a
    domain name is not a DoS...especially when said domain names are
    unregistered and in addition contain extremely unique registered
    service/trade marks ... VeriSign has only itself to blame if they resolve
    unregistered domain names improperly.

    Welcome thoughts...

    Ron


  3. Re: Verisign's DoS attack on the Internet

    Ron Bennett wrote in message news:...

    > Before someone says this is a DoS...remember, the mere reference of a
    > domain name is not a DoS...especially when said domain names are


    Intent matters. Your intention is to cause a DoS.

  4. Re: Verisign's DoS attack on the Internet

    >In yet another example of egregorious abuse of the monopoly power that
    >the U.S. gov't foolishly granted them, NetSol/Verisign has started to
    >return A records for any invalid domains.
    >
    >Does anyone happen to know a way to filter these out to restore the
    >proper functioning of just about any kind of software, including spam
    >filtering?


    Sure, just check the "is this really a valid A record or one of
    thise bogus ones" bit. Ie, no.

    Other TLD registries started doing this years ago (ie, .ws) I'm
    assuming they all will in time. I don't see how this impacts
    anybody's ability to use the net though.

    How is NSI a monopoly? It's a government regulated contractor;
    and the government set the price of wholesale names.

    --
    OEM parts - Benz: http://parts.mbz.org BMW: http://buyeuroparts.com
    http://www.mbz.org | Mailing lists: http://lists.mbz.org
    633CSi 250SE/C 300SD | Classifieds: http://ads.mbz.org
    2 X 280SE | Wrist Watch list: http://watches.list.mbz.org

  5. Re: Verisign's DoS attack on the Internet

    >What would happen if I added some IMG SRC tags to webpages we serve that
    >point to unregistered domain names? ... between all the sites I operate
    >that could easily drive several million hits to semi-random unregistered
    >domains everyday. If others did the same, things could get interesting!
    >
    >Before someone says this is a DoS...remember, the mere reference of a
    >domain name is not a DoS...especially when said domain names are
    >unregistered and in addition contain extremely unique registered
    >service/trade marks ... VeriSign has only itself to blame if they resolve
    >unregistered domain names improperly.


    Sure Eugene, whatever you say.

    --
    OEM parts - Benz: http://parts.mbz.org BMW: http://buyeuroparts.com
    http://www.mbz.org | Mailing lists: http://lists.mbz.org
    633CSi 250SE/C 300SD | Classifieds: http://ads.mbz.org
    2 X 280SE | Wrist Watch list: http://watches.list.mbz.org

  6. Verisign's land grab

    HPA> Does anyone happen to know a way to filter these out to
    HPA> restore the proper functioning of just about any kind of
    HPA> software, including spam filtering?

    No. No-one knows a way, because any such filters _won't_ restore
    the proper functioning (taking that to really mean the status quo
    ante, which wasn't necessarily "proper functioning"). Indeed,
    and somewhat ironically, although what Verisign has done doesn't
    actually constitute a "DoS attack", as you put it, such filters do
    _themselves_ create the means for Verisign to perform DoS attacks,
    should it then wish to.



  7. Verisign's land grab

    RJS> I don't see how this impacts
    RJS> anybody's ability to use the net though.




    RJS> Other TLD registries started doing this years ago [...]

    There are four important differences between the two situations:

    1. "com." and "net." are a lot larger than those CC TLDs. A far
    greater portion of the namespace has been affected.

    2. "com." and "net." are more popular than those CC TLDs. Far
    more people have experienced the effects.

    3. "Append 'com.' and try again." is default behaviour in many web
    browser softwares. Appending a CC TLD and trying again is not.

    4. What those CC TLD registries did didn't result in resurrecting
    "boss.com." or long-defunct RBLs.

    Even setting those differences aside, this is a bad idea for _both_
    Verisign and the CC TLD registrars. Aging has not magically turned
    this bad idea into a good one.

    I've been advising DNS administrators to be wary of doing this sort
    of thing, for some while. Using "catch-all" wildcards, and setting
    things up so that service clients operate correctly in a
    general-purpose environment, is not trivial, and more work than most
    people think. My advice has been to take great care if one chooses
    to employ this option.




    Neither Verisign nor the CC TLD registrars have taken great care,
    or done all of the necessary work, and as a consequence people are
    hitting exactly the problems that I warned will be hit when
    "catch-all" wildcards are employed.

  8. Re: Verisign's DoS attack on the Internet

    1) My ISP's nameserver still points sites like
    http://www.nonexistent-domain-nothin...sitefinder.com
    to 64.94.110.11. However, the browser is unable to connect to the webserver there.

    2) Hasn't been the Sitefinder DDoS'ed? I bet it was or it will...

    3) There are many feasible DDoS scenarios available, for instance
    feeding e-mail addresses like
    random_number@www.nonexistent-domain...sitefinder.com
    to the spambots, bringing traffic to



    from a porn site or a Web forum... Haven't Verisign expect that?

    TJP


    H. Peter Anvin wrote in message news:...
    > In yet another example of egregorious abuse of the monopoly power that
    > the U.S. gov't foolishly granted them, NetSol/Verisign has started to
    > return A records for any invalid domains.
    >
    > Does anyone happen to know a way to filter these out to restore the
    > proper functioning of just about any kind of software, including spam
    > filtering?
    >
    > -hpa


  9. Re: Verisign's DoS attack on the Internet

    totojepast wrote:

    > 1) My ISP's nameserver still points sites like
    > http://www.nonexistent-domain-nothin...sitefinder.com
    > to 64.94.110.11. However, the browser is unable to connect to the
    > webserver there.
    >
    > 2) Hasn't been the Sitefinder DDoS'ed? I bet it was or it will...
    >
    > 3) There are many feasible DDoS scenarios available, for instance
    > feeding e-mail addresses like
    > random_number@www.nonexistent-domain...sitefinder.com
    > to the spambots, bringing traffic to
    > > src="http://www.nonexistent-domain-nothing-here-just-sitefinder001.com">
    > > src="http://www.nonexistent-domain-nothing-here-just-sitefinder002.com">
    > > src="http://www.nonexistent-domain-nothing-here-just-sitefinder003.com">
    > from a porn site or a Web forum... Haven't Verisign expect that?
    >
    > TJP
    >
    >
    > H. Peter Anvin wrote in message
    > news:...
    >> In yet another example of egregorious abuse of the monopoly power that
    >> the U.S. gov't foolishly granted them, NetSol/Verisign has started to
    >> return A records for any invalid domains.
    >>
    >> Does anyone happen to know a way to filter these out to restore the
    >> proper functioning of just about any kind of software, including spam
    >> filtering?
    >>
    >> -hpa


    I can't even resolve that stuff now. I've applied the "delegation-only"
    patch for Bind 9.2.2

    --
    Donovan Hill

  10. Re: Verisign's DoS attack on the Internet

    [I live in alt.hacker, f'up to there set]

    alt wrote:

    [http://www.nonexistent-domain-nothin...finder001.com]
    > I can't even resolve that stuff now. I've applied the "delegation-only"
    > patch for Bind 9.2.2
    >


    Paul Vixie on NANOG:
    "if you installed the first isc wildcard patch you probably want the second.
    see www.isc.org/products/BIND/delegation-only.html for details. the first
    patch didn't handle NS lookups (which don't occur in nature but it's sort of
    unnerving when they don't work in "dig").

    in addition to the "type delegation-only" zones, the latest release candidate
    has an additional "root-delegation-only" option. this looks like:

    options {
    root-delegation-only exclude { "de"; "museum"; };
    };

    thus the delegation-only behaviour becomes the default for the root domain,
    and all tld's except those listed. DE has no wildcards but they do put
    customer A RRs into the DE zone itself. MUSEUM has a wildcard but this was
    part of their application and it was approved and has not been a problem.

    f.6to4-servers.net is now running this if you want to try before you, um, buy.

    thanks very much to the membership of the bind forum who make this possible."



    Regards, Jan

    --
    /"\ ASCII Ribbon Campaign
    \ / No HTML in mail or news!
    X
    / \ Dutch Security Information Network: http://www.dsinet.org


+ Reply to Thread