What *are* they smoking?

A wildcard A record in the net TLD.

$ host does.really-not-exist.net
does.really-not-exist.net has address 64.94.110.11

$ host 64.94.110.11
11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com

It even responds on port 25 (says 550 on every RCPT TO). Gah.

  -- Niels.

It's Verisign's return shot at the web browser "couldn't find this page"
searches. Doesn't seem to have much by way of advertising yet, but I'm
sure that'll change. I heard about this coming from somewhere last week,
though I don't recall where. Probably Wired or the WSJ. Verisign wants
the revenue that all those typos are generating. It's just the next shot
in the eyeball war.

Tim Wilde

Once upon a time, Niels Bakker <niels=nanog@bakker.net> said:

A wildcard A record in the net TLD.

$ host does.really-not-exist.net
does.really-not-exist.net has address 64.94.110.11

$ host 64.94.110.11
11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com

It even responds on port 25 (says 550 on every RCPT TO). Gah.

Yep, and it'll be coming soon to .com. All your typo domain are belong
to Verisign.

I would say time to null route this horribly inappropriate scam, but it
looks like a few cable modem providers have already done so, and I am no
longer seeing it in the .com zone (but I still see it under .net).

http://www.cbronline.com/latestnews/d04afc52ae9da2ee80256d9c0018be8b

Mike

-----BEGIN PGP SIGNED MESSAGE-----

Tim Wilde wrote:

>
> A wildcard A record in the net TLD.
>
> $ host does.really-not-exist.net
> does.really-not-exist.net has address 64.94.110.11
>
> $ host 64.94.110.11
> 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com
>
> It even responds on port 25 (says 550 on every RCPT TO). Gah.

Even worse of this is that you can't verify domain names under .net
any more for 'existence' as every .net domain suddenly has a A record
and then can be used for spamming...

Thank you Verisign! Now we need to check for existence of an MX
and then just break a couple of RFC's in the process :frowning:

It's Verisign's return shot at the web browser "couldn't find this page"
searches. Doesn't seem to have much by way of advertising yet, but I'm
sure that'll change. I heard about this coming from somewhere last week,
though I don't recall where. Probably Wired or the WSJ.
Verisign wants the revenue that all those typos are generating. It's just
the next shot in the eyeball war.

Who said the internet wasn't commercial again ?
Thank you goverment of the United States of America for
allowing such money hungry organisations to abuse one
of the original tld's.

Wasn't .net meant for *networks* ? aka ISP backbone infrastructure
and not for commercials?

(And I thought that domain reselling was a yucky business)

Greets,
Jeroen

Once upon a time, Richard A Steenbergen <ras@e-gerbil.net> said:

> $ host does.really-not-exist.net
> does.really-not-exist.net has address 64.94.110.11

I would say time to null route this horribly inappropriate scam, but it
looks like a few cable modem providers have already done so, and I am no
longer seeing it in the .com zone (but I still see it under .net).

Someone has already brought up the idea on the BIND list of modifying
BIND to recognize this response and converting it back to NXDOMAIN.
Blackholing the IP means that your customers will get an error that the
site is unreachable, not that it does not exist.

BTW: I got a "content filter" message bounce in response to my other
post on this topic - anyone else get that? I didn't see anything in my
message that looked filter-worthy to me.

It's Verisign's return shot at the web browser "couldn't find this page"
searches. Doesn't seem to have much by way of advertising yet, but I'm
sure that'll change. I heard about this coming from somewhere last week,
though I don't recall where. Probably Wired or the WSJ. Verisign wants
the revenue that all those typos are generating. It's just the next shot
in the eyeball war.

I am guessing that given the relatively light penalty Register.com got for
its "Coming Soon" web pages, Verisign was encouraged to try the same thing
and will probably be glad to take the same penalty.

Deepak Jain
AiNET

No, it accepts if the from domain exists - but only if it *REALLY* exists.

[...]
rcpt to: fooo@baaaaaaaaaaaaaaaaaaaaaaaaaaar.net
250 OK
mail from: fooooo@baaaaaaaaaaarrrrrrrrrrrr.net
550 User domain does not exist.
mail from: patrick@ianai.net
250 OK

Nice that their spam filters still work. :frowning:

And I love the 221 close message:

data
221 snubby1-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host.

That would be me -- I posted to comp.protocols.dns.bind, not realizeing it
was a mailing list gateway.

This also blows away the whole idea of rejeting mail from non-existant
domains -- never mind all the bounces to these non-existant domains when the
spammers get ahold of them. Boy, I hope they have a good mail server
responding with the 550 on that IP !

At the least we need a way for MTA's to reject mail from domains that
resolve to this nonsense. Having bind put NXDOMAIN back would be a plus.

-Chris

-----BEGIN PGP SIGNED MESSAGE-----

Tim Wilde wrote:

>
> >
> > A wildcard A record in the net TLD.
> >
> > $ host does.really-not-exist.net
> > does.really-not-exist.net has address 64.94.110.11
> >
> > $ host 64.94.110.11
> > 11.110.94.64.IN-ADDR.ARPA domain name pointer sitefinder-idn.verisign.com
> >
> > It even responds on port 25 (says 550 on every RCPT TO). Gah.

Even worse of this is that you can't verify domain names under .net
any more for 'existence' as every .net domain suddenly has a A record
and then can be used for spamming...

From: Spammer <i@spam.using.verisign.eventhoughthisdomaindoesntexist.net>
To: You <spamtarget@example.com>

Thank you Verisign! Now we need to check for existence of an MX
and then just break a couple of RFC's in the process :frowning:

What about if the IP address returned by the DNS query is the same one as
does.really-not-exist.net then the spam is returned to the owner of
the IP address? In this case Versign. I think this is already done
by some automated spam reporting tools. If AOL does it Verisign will
probably get crushed by the load (if one is having a spam war with AOL's
mail servers AOL will always win).

> It's Verisign's return shot at the web browser "couldn't find this page"
> searches. Doesn't seem to have much by way of advertising yet, but I'm
> sure that'll change. I heard about this coming from somewhere last week,
> though I don't recall where. Probably Wired or the WSJ.
> Verisign wants the revenue that all those typos are generating. It's just
> the next shot in the eyeball war.

Who said the internet wasn't commercial again ?
Thank you goverment of the United States of America for
allowing such money hungry organisations to abuse one
of the original tld's.

Wasn't .net meant for *networks* ? aka ISP backbone infrastructure
and not for commercials?

That has been going on for several years now (unfortunately).

(And I thought that domain reselling was a yucky business)

Yep, but it can be profitable. I'm just waiting for someone to put out
a typo in a large press release and then sue Verisign for stealing all
the traffic.

According to the article in the link posted from cbronline.com this has
been done by NeuStar who runs the .biz and .us domain registries. The
company which runs this service for NeuStar claims to be able to
differentiate between http and other requests. I'm still waiting to
see how they do this as you can't tell from a DNS request alone.

bye,
ken emery

Checking for NS or SOA record(s) is sufficient, neither are being returned,
only A records.

Of course, you could just block anything that resolves to netsol.

Once upon a time, Christopher X. Candreva <chris@westnet.com> said:

This also blows away the whole idea of rejeting mail from non-existant
domains -- never mind all the bounces to these non-existant domains when the
spammers get ahold of them. Boy, I hope they have a good mail server
responding with the 550 on that IP !

At the least we need a way for MTA's to reject mail from domains that
resolve to this nonsense. Having bind put NXDOMAIN back would be a plus.

I see a few of ways to distinguish the responses at the moment (without
hard-coding the IP address or reverse DNS for that IP):

- the TTL on the bogusdomain.net responses in 15M instead of 2D

- on bogusdomain.net responses, the ADDITIONAL and AUTHORITY records all
  point to gtld-servers.net servers, while normal requests get records
  pointing somewhere else

- there are no NS records for bogusdomain.net

None of these help MTAs today.

For sendmail, you could do something with the dns map to look for NS
records for something.net when you get @blah.something.net. However, it
means one more DNS lookup for everything ending in .com or .net.

I'm waiting for Illuminet^HVeriSign to add this "feature" to their
global title translation database and redirect all non-existant 800
numbers to recorded advertisements.

-----BEGIN PGP SIGNED MESSAGE-----

Matthew S. Hallacy wrote:

>
> Even worse of this is that you can't verify domain names under .net
> any more for 'existence' as every .net domain suddenly has
a A record
> and then can be used for spamming...
>
> From: Spammer
<i@spam.using.verisign.eventhoughthisdomaindoesntexist.net>
> To: You <spamtarget@example.com>
>
> Thank you Verisign! Now we need to check for existence of an MX
> and then just break a couple of RFC's in the process :frowning:

Checking for NS or SOA record(s) is sufficient, neither are
being returned,
only A records.

Of course, you could just block anything that resolves to netsol.

example.com. NS ns1.example.com
        A 10.100.13.42
blaat A 10.100.13.42

It's completely legal, per RFC, to mail user@blaat.example.com
as it is a host, but blaat.example.com doesn't need an NS record.

Having an extra lookup checking with a NS if the first
level domain exists is an option though.

But the best option is just to let dns servers return NXDOMAIN
and let people use google or let them *type* correctly.

Or is Verisign suddenly also all knowledgable about which
url's are going to be valid? "oops the user is going to make a typo,
lets point everything on our box and let that log and figure out
what the dumb user really meaning"... go figure..

Btw it doesn't do IPv6 which is bad and doesn't scale into the future :slight_smile:
And no HTTP SSL support either. No POP3/IMAP support telling people
they typed in the wrong hostname for their mailserver etc...

Any kiddie group already planning to "take down" the advert server ?
It's just 1 IP to take out a *lot* of domains, anything you can mistype :wink:
"Look mommy we took down <think up something>.net, now you see it now you..."

I also wonder what privacy implications this has, stupid example:
http://www.thawhaithouse.net/login/?user=president&password=cannedremember

There goes your privacy act (if you still thought there was any :slight_smile:

Greets,
Jeroen

Can they realistically enforce a TOS on a site like that, and how can they
provide a remedy for it?

I, for one, do not agree to their terms of service.

Thanks

-a-

http://www.verisign.com/corporate/about/contact/index.html

Give 'em hell.

apl

Niels Bakker wrote:

so, every spammer in the world spams versign. The down side of this is ... what? I don't remember...

FYI: A quick look shows 14 TLDs that appear to have wildcard records:

ac
cc
com
cx
mp
museum
net
nu
ph
pw
sh
tk
tm
ws

The following TLDs answer for '*.tld' but do not appear to have wildcard
records:

bz
cn
tw

It appears that the most reliable way to detect a wildcard response for
'somedomain.tld' is to query for '*.tld'; if the results match, then
'somedomain.tld' doesn't really exist.

I called VeriSign the registrar and got a supervisor, Forsyth. I spoke to him briefly about this filthy practice.

He said that VeriSign GRS deals *only* with registrars; customer support at NetSOL (great abbreviation) can't even get in contact with them. It doesn't seem like they have much communications or unification between the GRS (which handles the TLDs), the registrar (which does actual registrations), and their security arm.

He relayed me to the corporate office, and gave me this contact information:

487 East Middlefield Road
Mountain View, CA 94043

1 (650)-961-7500

Good luck! :slight_smile:

apl

Alex Lambert wrote: