Re: Verisign hijacked unused .COM and .NET domains - TCP-IP

This is a discussion on Re: Verisign hijacked unused .COM and .NET domains - TCP-IP ; JB> 2. Verisign demonstrates total ownership of .COM and .NET JB> root[?] hierarchy Which, of course, is perfectly legitimate. The root organisations delegate authority over "com." and "net." to Verisign, so it does have it, and always has. As you ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Verisign hijacked unused .COM and .NET domains

  1. Re: Verisign hijacked unused .COM and .NET domains

    JB> 2. Verisign demonstrates total ownership of .COM and .NET
    JB> root[?] hierarchy

    Which, of course, is perfectly legitimate. The root organisations
    delegate authority over "com." and "net." to Verisign, so it does
    have it, and always has. As you say, it has merely _demonstrated_
    that it has it.

    JB> 5. Nameservers around the world will now cache all sorts of
    JB> useless junk

    They would already have been caching "no such name" information about
    the domain names that have suddenly been brought into existence.
    Caching "A" resource record sets (and the empty resource record sets
    for all other types) may take up more space, but information about
    these domain names _was already being_ cached.

    JB> 8. Invalid URLs can now pollute search engines and
    JB> automated systems

    There is, reportedly, a "robots.txt" file on Verisign's content
    HTTP server at 64.94.110.11 that stops it from being crawled by
    spiders.

    JB> You might want to complain to ICANN [ http://www.icann.org/ ]

    The root server organizations that delegated "com." and "net." to
    Verisign are, indeed, the ones to complain to.


  2. Re: Verisign hijacked unused .COM and .NET domains


    "Jonathan de Boyne Pollard" wrote in message
    news:3F677935.4DD683A1@Tesco.NET...
    > JB> 2. Verisign demonstrates total ownership of .COM and .NET
    > JB> root[?] hierarchy
    >
    > Which, of course, is perfectly legitimate. The root organisations
    > delegate authority over "com." and "net." to Verisign, so it does
    > have it, and always has. As you say, it has merely _demonstrated_
    > that it has it.
    >
    One question here, what entries have been added as wildcards - std .com and
    ..net
    or have they also added a fake MX record, if not then there shouldn't be a
    problem just check the domain for a valid MX record - if it doesn't have one
    then refuse the mail.

    Mike.


  3. Verisign's land grab

    JB> 2. Verisign demonstrates total ownership of .COM and .NET
    JB> root[?] hierarchy

    JdeBP> Which, of course, is perfectly legitimate. The root
    JdeBP> organisations delegate authority over "com." and "net." to
    JdeBP> Verisign, so it does have it, and always has [had it]. As
    JdeBP> you say, it has merely _demonstrated_ that it has it.

    MF> One question here, what entries have been added as wildcards -
    MF> std .com and .net or have they also added a fake MX record,

    [C:\]dnsqry * *.com. | grep /b/u Answer:
    Answer: *.com. IN A 900 64.94.110.11

    [C:\]dnsqry * *.net. | grep /b/u Answer:
    Answer: *.net. IN A 900 64.94.110.11

    [C:\]

    MF> if not then there shouldn't be a problem just check the domain for
    MF> a valid MX record - if it doesn't have one then refuse the mail.

    You aren't the first person to have suggested this. (The first one,
    that I saw, to suggest this was a Adam Aube in
    ) The flaw in
    that scheme is threefold:

    First: There are a _lot_ of perfectly valid domains that do not
    have "MX" resource record sets, and this is a perfectly legitimate
    configuration. Blocking sender mailboxes whose domain parts fail
    an "MX" lookup will block a _lot_ of legitimate senders.

    Second: Verisign can easily add a wildcard "MX" resource record set.
    (And, ironically, this is one of the few situations where a wildcard
    "MX" resource record set would perform the function that is actually
    intended.)

    Third: This is a problem with DNS, and thus as a consequence with all
    sorts of services, not just with (web browsing and) electronic mail.
+ Reply to Thread
« Problem NAT and local network | Re: Verisign's land grab »