-----BEGIN PGP SIGNED MESSAGE----- Tim Wilde wrote:

On Tue, 16 Sep 2003, Niels Bakker 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 :(

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 -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP2ZIvCmqKFIzPnwjEQLQkgCgtFDU1TKOrt/tz0I+GGm+Vu/P+xUAoI+s 6Czvls9qXOslOkOnJXLhU8ZC =sC7+ -----END PGP SIGNATURE-----

On Mon, 2003-09-15 at 19:35, ken emery wrote:

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.

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. -- Jeff S Wheeler

-----BEGIN PGP SIGNED MESSAGE----- Matthew S. Hallacy wrote:

On Tue, Sep 16, 2003 at 01:18:26AM +0200, Jeroen Massar 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 :(

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 :) 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 ;) "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 :) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP2ZVuCmqKFIzPnwjEQKQggCcDGgy0kXNIA89kvL9EiFPosVNy+QAn3G9 hepKhdO0XS6nTtgrYGg/jAna =9VhA -----END PGP SIGNATURE-----

"The information provided through the VeriSign Services is not necessarily complete and may be supplied by VeriSign's commericial licensors, advertisers or others." There's something immoral about *shoving it down our throats*, then, VeriSign. apl Adam 'Starblazer' Romberg wrote:

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-

---------------------------------------------------- Adam 'Starblazer' Romberg Appleton: 920-738-9032 System Administrator ExtremePC LLC -=- http://www.extremepcgaming.net

On Mon, 15 Sep 2003, Alex Lambert wrote:

"The information provided through the VeriSign Services is not necessarily complete and may be supplied by VeriSign's commericial licensors, advertisers or others."

There's something immoral about *shoving it down our throats*, then, VeriSign.

Nice terms of service at http://sitefinder.verisign.com/terms.jsp : The VeriSign Services are provided only for your personal and non-commercial use. You are not authorized to modify, copy, display, transmit, license, create derivative works from, transfer, distribute or sell any information, software, products or services obtained from the services VeriSign provides through this web site. You may not "meta-search" the VeriSign Services. If you want to make commercial use of the VeriSign Services, you must enter into an agreement with us to do so in advance. so... umh... I can't display any information from their website. And can only use it for non-commercial use. So... if I make a DNS query for some "commercial" purpose (whatever that means), and get a response and then connect to that IP on port 80 and send a request, and get a redirect to this sitefinder.verisign.com site, and follow it... I'm violating their terms of use. Does the contract under which NSI is operating .com and .net require that people be able to use the results of their queries for non-personal and commercial use? It is a little fuzzy how directly you can relate the DNS response to the terms of use on the website you get redirected to on the legal level, but it seems that since Verisign is operating it with the intent that people entering unknown domains into a webbrowser get redirected there, then they are by implication stating that people doing things for non-personal or commercial purposes must never enter such names. Sure, it is a ridiculous terms of use that wouldn't be likely to hold up very well, but would the fact that they are making that claim have any implication on if they are meeting the stated or implied terms of their contract with ICANN?

At 04:18 PM 9/15/2003, Jeroen Massar 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...

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

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

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

Ever get tempted to have a 'wet ops' NANOG team?

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

On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker wrote:

...

$ 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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

On Mon, 15 Sep 2003, Chris Adams wrote:

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.

Just make up a number of fake domains and resolve them. If they return the same answer, thats the answer to change back into NXDOMAIN. //tlund

And then Verisign starts using multiple IP addresses and rotating through them. And then they stop giving any other clues that it is a wildcard record. Great. Just what we need... To be in an escalating war with the people running the root nameservers. Since it is clearly in Verisign's business interest to make it impossible for you to tell when you've been handed one of the wildcard replies, I don't see this stopping any time soon. Matthew Kaufman matthew@eeph.com

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Tomas Lund Sent: Monday, September 15, 2003 6:14 PM To: Chris Adams Cc: nanog@merit.edu Subject: Re: What *are* they smoking?

On Mon, 15 Sep 2003, Chris Adams wrote:

...

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.

Just make up a number of fake domains and resolve them. If they return the same answer, thats the answer to change back into NXDOMAIN.

//tlund

Bruce Campbell wrote:

On Tue, 16 Sep 2003, Matthew Kaufman wrote:

...

record. Great. Just what we need... To be in an escalating war with the people running the root nameservers.

Please note that the people running the root nameservsers are a different set from the people who run the .com and .net nameservers.

True, these days, at least in part. Since the latest zone for .net (and maybe .com according to the announcement) contains data that * indicates existance for domains that actually do not exist, and * incorrect addresses for domains that exist, but are not using the name service of netSOL cum verisign, it is arguably not a valid zone file. Therefore, any root server operators should refuse the improper zone file.

Please use the slightly more accurate term 'gTLD nameservers' instead of tarring the 'root' nameservers with the same brush.

We are about to empirically determine the independence of the root server operators. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

On Tue, 16 Sep 2003 13:31:19 EDT, Eric Gauthier said:

it. I'm a stupid network engineer that typically leaves the money stuff up to my finance geek friends, but even I know that (well most of the time):

Bad Press == Stock Go Down

I wish this explained SCO's stock price... ;)

On Tue, 16 Sep 2003 22:48:43 +0300 (IDT) Hank Nussbacher <hank@att.net.il> wrote:

...

Verisign is a business and its goal is to make money.More importantly, its a publically traded company whose goal is to make its stock value go up. So, if we're interested in having them listen, we should be targeting their stock value.Right now, I really can't think of a headline that the NY Times or CNN could run that would make ordinary people understand what's going on and encourage them to bring pressure on Verisign.Besides, Verisign would obviously counter with the junk in their release.

So far up 1.7% today: http://finance.yahoo.com/q/bc?s=VRSN&t=1d

Looks like they are winning.

Please take heart in the fact that the performance of IT stocks these days is not in any way a reflection of the company in question. That stock performance became meaningless during the dot-com bubble and to this day it remains impossible to draw any sort of substantive conclusion based on it.

http://www.iab.org/Documents/icann-vgrs-response.html

Can you also program something to do this for all root zones, i.e. something like 'zone ".*" { type deligation-only; };' And make it default configuration for new bind releases... On 17 Sep 2003, Paul Vixie wrote:

...

Anyone have a magic named.conf incantation to counter the verisign braindamage?

zone "com" { type delegation-only; }; zone "net" { type delegation-only; };

...

Or does this require a patch to bind?

yes, it does. to be released shortly.

Paul Vixie wrote:

no. not just because that's not how our internal hashing works, but because "hosted" tld's like .museum have had wildcards from day 1 and the registrants there are perfectly comfortable with them. there's no one-policy-fits-all when it comes to tld's, so we would not want to offer a knob that tried to follow a single policy for all tld's.

I agree Paul. This is a policy issue and not a technical issue. TLDs that are sponsored or setup with a specific design sometimes do and should be allowed to use the wildcard for the tld. The issue has become that net and com are public trusts and changes were made to them without authorization by the public and damage was caused as a result. Just as root server operators are subject to operating as IANA dictates, so should Verisign be subject to operating as IAB and ICANN dictate. The Internet as a whole depends on the predictability of TLDs. It is impossible to maintain a security policy based on unpredictable information. I would recommend that the TLDs which do utilize wildcards setup or restrict such use in a predictable manner. While historically it has not been an issue, such as nonexistant .museum domains being forged in email envelopes, such practices could be exploited at a later time. The ability to recognize that a domain is not registered and should not be used is paramount in basic forgery detection. One method that might be considered for recursive servers as well as resolvers, is the ability to specify if a wildcard entry will be accepted or not, perhaps at any level or just at the 2nd level. Cached records which are wildcards could be marked as such so that subsequent queries could specify desire of accepting or not accepting the wildcard entry. A web browser, for example, which supports its own redirections for NXDOMAIN, might wish to ignore the wildcard records, as would smtp servers. While I believe that net and com should never have wildcards, the ability to detect, cache, and override wildcards for tld's such as .museum when the application requires it is paramount. I realize that the client software can perform the queries and detection itself, but in many cases, there wouldn't be an effecient way to cache the information without the resolver and recursive cache being aware of the process and performing such detection would require two queries versus one. -Jack

Aaron Dewell wrote:

What if there was a requirement to add something that would work as a wildcard, but also be easily detected as a wildcard with one additional query? thisisawildcard.*.com IN A 127.0.0.1 or something. One additional query, and applications can decide whether they want a wildcard result or not. That could be added to spam filters to make them work again.

One additional query is the problem. For example, a mail server running sendmail with a bind recursor. If sendmail has to check for the wildcard, it will have to check for *.com as well as example.com and do a set comparison to see if example.com is a wildcard. For every new process, this has to be repeated, doubling the number of queries on the recusor. If, however, the recursor performed the processes, caching *.com for the TTL and recognizing that all domains resolving to its set is also a wildcard, and caching/marking them as such, then the resolver can request the record, without wildcards, on behalf of sendmail. This means one query to the recursor who has properly cached 1) the domain record, 2) if the domain record is a wildcard, and 3) the wildcard set. This is about the minimal number of queries that can be performed across the board. Applications that want to accept the wildcard would ask the record normally (accepting wildcard). -Jack

Aaron Dewell wrote:

The point is, this makes a reasonable backup plan. Far from ideal, but we're dealing with a state-supported monopoly who can do whatever they want. Get this in place, then think about how to throw the monopolies out. This works in the meantime. They will likely compromise this far, even if they won't back down.

I'm thinking security for the long term. Even if com and net are returned to their non-wildcard states, there are other tld's which will continue using wildcards. Subject to a wildcard bit being implemented to DNS, my suggested method allows for optimum performance and functionality when DNS is being used as part of a security model.

The TTL is 15 minutes, so your hypothetical server would be throwing away it's cache every 15 minutes. Then re-querying everything. You'd have to have a _lot_ of outgoing email to justify that.

I don't know about you, but I don't want to cache bogus information for longer than 15 minutes. If someone sends random-string domains as the envelope from to my mail server, I want the cache to purge itself quickly. Yet, if they are sending the same bad address to my mail server repetitively, I want my cache to hold the record briefly; say 15 minutes. I'd hate to see a spammer issuing jlkfsjklfsj.com 5,000 times to my mail server in rapid succession and my recursor have to ask for it every time. On the other side, I would hate to cache 100,000 bogus domains for 1 day, wasting cache.

This solution still requires increased overhead, and more modifications to BIND. Which has more impact on your server, this BIND overhead, or one additional query from your MTA? My guess is the query is cheaper overall. And you have to convince ISC to implement these changes, or write them yourself, then you have the potential cost of an unstable nameserver. Overall, I'd take the one addition query based on the compromise solution.

My mail server doesn't use a bind recursor, so I'll end up making the change myself for that particular system. However, a solution needs to be devised for the long term. The best solution is a wildcard bit. Second to that, smart recursors and resolvers that can detect the wildcard. -Jack

SD> Date: Wed, 17 Sep 2003 00:48:09 -0400 (EDT) SD> From: Sean Donelan SD> So, Verisign just returns a NS pointer to another name server SD> Verisign controls which then answers the queries with SD> Verisign's "helpful" web site. Queries for random zones make a nice starting point. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.

On Wed, Sep 17, 2003 at 09:27:13AM -0400, Todd Vierling wrote:

On Wed, 17 Sep 2003, Paul Vixie wrote:

: > Anyone have a magic named.conf incantation to counter the verisign : > braindamage? : : zone "com" { type delegation-only; }; : zone "net" { type delegation-only; };

My first reaction to this was: 'yuck'. I'm not sure of the side-effects this will introduce. Anyone? Stefan -- Stefan Baltus <stefan.baltus@xbn.nl> XB Networks B.V. Manager Engineering Televisieweg 2 telefoon: +31 36 5462400 1322 AC Almere fax: +31 36 5462424 The Netherlands

Thus spake Eric Gauthier (eric@roxanne.org) [16/09/03 13:49]:

I'm sure that 5, 10, or 50 phone calls from Nanog-ers to the FTC, Congress, Dept of Commerce, ICANN, the US Post Office, or any other large organization will be completely ignored in the likely wash of everyday phone calls. We can talk about violations of RFCs and ask them to cease this stupidity, but I doubt that will work because there doesn't appear to be any consequences.

I think this goes for /anything/. If five, ten, or fifty of any of us do any one thing, it's not going to have an impact. So a handful of ISP's null route the IP address. And a few others hack their recursor code to return NXDOMAIN if a response returns with a given IP address, or even if it matches a wildcard gTLD lookup. And maybe a few more of us call ICANN, and some more call the FTC. It may solve it for you, but it doesn't necessarily fix the source of the problem. (And these hacks really should make it back into the CVS tree if they're going to be effective.)

On the other hand, a headline of "Internet Providers Worldwide block access to Verisign in Effort to Protect the Public" is very easily understood.

How about, 'Internet Operators Across North America Struggle to Deal with Impact of Business Decision: Internet Functionality Worldwide Tampered With by Verisign'? There doesn't really appear to be a unified decision to do one thing, there's a lot of bandying ideas around, and 'wouldn't-it-be-cool-if's being thrown out. At this point, there isn't a concerted enough effort to warrant a title like the one you suggest. But any journalists snooping around sure could help out a bit, at least by indicating that there /is/ a problem with this decision, and that Operators are still trying to figure out a) *why* it happened, and b) the best way to 'fix' it. My $0.02.

Damian, You wrote: Damian> But any journalists snooping around sure could help out Damian> a bit, at least by indicating that there /is/ a Damian> problem with this decision, Damian> and that Operators are still trying to figure out a) *why* it happened, and Damian> b) the best way to 'fix' it. How about writing up a simple explanation and sending it to some folks over at lightreading. That'll get some coverage. Ben.

Thus spake Christopher X. Candreva (chris@westnet.com) [16/09/03 17:24]:

...

On the other hand, a headline of "Internet Providers Worldwide block access to Verisign in Effort to Protect the Public" is very easily understood.

I was contacted a little while ago by a reporter from the Wall Street Journal, based on my Nanog posts. We'll see what the headline reads.

Declan (of news.com) has indicated that he's working on something, and I'm waiting to hear back from the editors at lightreading.com. I have full faith that Declan will not only put out a technically accurate piece, but one that is easily digestible by the public at large.

At 05:26 PM 16-09-03 -0400, Damian Gerow wrote:

Declan (of news.com) has indicated that he's working on something, and I'm waiting to hear back from the editors at lightreading.com. I have full faith that Declan will not only put out a technically accurate piece, but one that is easily digestible by the public at large.

http://news.com.com/2100-1032_3-5077530.html -Hank

There is an article on it here: http://online.wsj.com/article/0,,SB106375269188678100,00.html?mod=technology... but I think it requires a paid subscription "Christopher X. Candreva" To: nanog@merit.edu <chris@westnet.co cc: m> Subject: Re: Root Server Operators (Re: What *are* they smoking?) Sent by: owner-nanog@merit .edu 09/16/2003 05:21 PM On Tue, 16 Sep 2003, Eric Gauthier wrote:

On the other hand, a headline of "Internet Providers Worldwide block access to Verisign in Effort to Protect the Public" is very easily understood.

I was contacted a little while ago by a reporter from the Wall Street Journal, based on my Nanog posts. We'll see what the headline reads. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/

DL> Date: Tue, 16 Sep 2003 21:20:08 -0400 (EDT) DL> From: David Lesher DL> Verisign Move to Mean More Spam DL> DL> Will that do for a hook? s,to,could, and I'll bite. Gotta keep it factual. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.

[dot-net, dot-com] is arguably not a valid zone file. Therefore, any root server operators should refuse the improper zone file.

that's nonsequitur. root server operators do not carry the dot-com or dot-net zone files. therefore there will never be an opportunity to refuse (or accept) it. root server operators (see www.root-servers.org for details) include verisign as one of 11 organzations worldwide. the dot-com and dot-net zones, by comparison, are only served by verisign's own servers, and i do not think that verisign will refuse to accept them. -- Paul Vixie

On Tue, 16 Sep 2003 14:31:53 +1000, Matthew Sullivan said:

Worse than that - it's a fixed sequence of responses...

$ telnet akdjflasdf.com 25 Trying 64.94.110.11... Connected to akdjflasdf.com. Escape character is '^]'. 220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready sdfg 250 OK

Well.. at least now we know how they *intended* to only affect HTTP traffic.

I abandoned them a long time ago, but the big question is, how can we get rid of them as root servers operators? Sounds like time to push for more independent servers, and a truly separate company to handle the root server portion of .com/.net. They could still exist as a registrar, but with these kind of business practices, how long? Probably not very, so I'd expect them to fight it tooth and nail. Or abandon .com/.net entirely, but that would take a long time and a massive public-education campaign. See what happens to them when everyone refuses to use either .com or .net. I still use them, by way of OpenSRS, but that could be solved with some new registrations with a non-hostile TLD operator. Aaron On Mon, 15 Sep 2003, Alex Lambert wrote:

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

Give 'em hell.

apl

Just noticed this: verisign is redirecting queries for dorkslayers.com's old RBL, even though dorkslayers.com is a registered and active domain. It just has no name servers.

I must ask the subject again. What in the name of < censored > *are* they smoking? Who exclusively gave them the right to own the 'net and decide which domain points to where? Completely unacceptable. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu@towardex.com Cell: (978) 394-2867 On Tue, Sep 16, 2003 at 10:37:35AM -0500, Marius Strom wrote:

So it seems they're doing this to billing-active domains as well.

On Tue, 16 Sep 2003, Sabri Berisha wrote:

...

On Tue, Sep 16, 2003 at 12:56:57AM +0200, Niels Bakker 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

Simply inject a route for 64.94.110.11/32 in your favorite IGP, route it to a box and alias it on eth0. Put up a 404 not found and let Verisign rot in hell until such time as they regain their consiousness.

-- Sabri Berisha "I route, therefore you are"

"Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.

-- /-------------------------------------------------> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-------------| Alan Frame |---------------------->

Here is one solution - replace all of your root.cache files with: (root) nameserver = C.ROOT-SERVERS.ORSC (root) nameserver = D.ROOT-SERVERS.ORSC (root) nameserver = E.ROOT-SERVERS.ORSC (root) nameserver = F.ROOT-SERVERS.ORSC (root) nameserver = H.ROOT-SERVERS.ORSC (root) nameserver = I.ROOT-SERVERS.ORSC (root) nameserver = K.ROOT-SERVERS.ORSC (root) nameserver = L.ROOT-SERVERS.ORSC (root) nameserver = M.ROOT-SERVERS.ORSC (root) nameserver = A.ROOT-SERVERS.ORSC C.ROOT-SERVERS.ORSC internet address = 199.166.28.10 D.ROOT-SERVERS.ORSC internet address = 204.80.125.130 E.ROOT-SERVERS.ORSC internet address = 195.117.6.25 F.ROOT-SERVERS.ORSC internet address = 199.166.31.3 H.ROOT-SERVERS.ORSC internet address = 199.5.157.128 I.ROOT-SERVERS.ORSC internet address = 204.57.55.100 K.ROOT-SERVERS.ORSC internet address = 199.166.27.4 L.ROOT-SERVERS.ORSC internet address = 199.166.29.2 M.ROOT-SERVERS.ORSC internet address = 195.206.104.13 A.ROOT-SERVERS.ORSC internet address = 199.166.24.12 ----- Original Message ----- From: "Greg Maxwell" <gmaxwell@martin.fl.us> To: "Haesu" <haesu@towardex.com> Cc: "Marius Strom" <marius@marius.org>; <nanog@merit.edu> Sent: Tuesday, September 16, 2003 11:23 Subject: Re: What *are* they smoking?

On Tue, 16 Sep 2003, Haesu wrote:

...

I must ask the subject again. What in the name of < censored > *are* they smoking? Who exclusively gave them the right to own

the 'net and decide which domain points to where?

...

Completely unacceptable.

It's very amusing to see people on *this* list asking *who* gave control to them. Who else configures your customers DNS settings?

Here is one solution - replace all of your root.cache files with:

1) it doesn't solve the problem of the .com and .net registry handing out addresses 2) It creates whole new sets of problems Please continue to go off and skulk in a corner <dangerous and broken settings snipped>

On Tue, 16 Sep 2003, Mark Jeftovic wrote:

...

It's very amusing to see people on *this* list asking *who* gave control to them. Who else configures your customers DNS settings?

My customers.

End users don't figure out DNS settings on their own, either a network operator picks what roots they use (by say accepting a default root cache in a resolver package) or they obtain configuration directives from an upstream network.

yes. you might want to view/review http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-01.txt DNSsec will work properly with wildcards, regardless of where they are in the DNS.

Has anyone thought through the DNSsec implications of this?

(spool up the black helicopters....)

Greg Maxwell wrote:

...

On Tue, 16 Sep 2003, Haesu wrote:

...

I must ask the subject again. What in the name of < censored > *are* they smoking? Who exclusively gave them the right to own the 'net and decide which domain points to where? Completely unacceptable.

It's very amusing to see people on *this* list asking *who* gave control to them. Who else configures your customers DNS settings?

On Tue, 16 Sep 2003 09:59:40 PDT, bmanning@karoshi.com said:

DNSsec will work properly with wildcards, regardless of where they are in the DNS.

Which means that a rogue DNS can lead you down the garden path and DNSsec won't give you a clue that you're being lied to. It's the same question as the "what happens to SSL to a phantom site?" - Verisign can provide an A record for the server and an SSL cert that will work.

On Tue, 16 Sep 2003 11:08:11 PDT, bmanning@karoshi.com said:

...

On Tue, 16 Sep 2003 09:59:40 PDT, bmanning@karoshi.com said:

thats one aspect yes. the valdiation chain should tell you who signed the delegations. It won't lie. you will know that V'sign put that data there.

How frikking many hacks will we need to BIND9 to work around this braindamage? One to stuff back in the NXDomain if the A record points there, another to do something with make-believe DNSsec from them..... What's next?

On Tue, 16 Sep 2003 11:27:08 PDT, bmanning@karoshi.com said:

if vt.edu wants to place a:

* in a 198.82.247.53

in the vt.edu zone, why should anyone complain that now vt.edu doesn't return NXDOMAIN for all un-delegated entries? You want that everyone should hack the DNS to force NXDOMAINS for your wildcard? Feh.

So you're saying it's OK when Verisign does the same exact thing one level up? Or are you surprised that people are coding it for the Verisign case? The difference is when we urinate in our zone of the DNS, it's OUR zone. When Verisign does it, they're not urinating in *THEIR* .COM, they're urinating in a .COM they were holding in the public trust. If in fact .COM is now Verisign's playground rather than a public trust, then that's a different matter.

DNSSEC will tell a validating resolver the signature of each party that signed part of the chain. If Verisign wishes to sign bits of data that might exist under the delegation point they have responsibility for, I'm in favor. Its not "make-believe" ... or perhaps I don't understand your angst.

The point is they're not signing data that might exist, they're signing data that doesn't exist. If a query comes in for www.never-existed.com comes in, what exactly is getting signed? (Yes, if it's a synthesized reply based on a wildcard, you can count the NXT's and stuff to determine that - but I quite frankly don't trust the Verisign people to not intentionally obfuscate the replies to make this impossible.....)

On Tue, 16 Sep 2003 Valdis.Kletnieks@vt.edu wrote:

How frikking many hacks will we need to BIND9 to work around this braindamage? One to stuff back in the NXDomain if the A record points there, another to do something with make-believe DNSsec from them..... What's next?

Well, you can always vote... http://www.forbes.com/2003/05/01/cx_ceointernetpoll.html Link courtesy of inet-access. -- Jay Hennigan - CCIE #7880 - Network Administration - jay@west.net WestNet: Connecting you to the planet. 805 884-6323 WB6RDV NetLojix Communications, Inc. - http://www.netlojix.com/

Eric Germann wrote:

And whats to say they don't get around our methods of blacklisting it by changing the IP around every zone update?

result=query domain.tld wild=query *.tld if result=wild & dontwantwild then result=NXDOMAIN -Jack