Re: I've just tried new.net's plugin. Don't.
So the plug-in does *not* change which dns server you query. if a query fails against your normal name server it just appends .newdotnet.net or, if that fails, makes stuff up. Of course if your regular resolver server was a UDNS server or Earthlink or an ISP that adopted the new.net TLD's you would have found an A record for pie.shop with or without the plug-in. This also means that if your reguler resolver server had your own private .shop zone (perhaps empty), that would take precedence for regular and plug-in queries for that TLD. KL Chris Davis wrote:
I removed the plug-in already, but pinging www.pie.shop went like this:
ping www.pie.shop
std query for www.pie.shop against my name server fails std query for www.pie.shop.computerjobs.com against my name server failes wins query for www.pie.shop fails netbios broadcast for www.pie.shop fails x1 netbios broadcast for www.pie.shop fails x2 netbios broadcast for www.pie.shop fails x3 std query for www.pie.shop against my name server fails std query for www.pie.shop.computerjobs.com against my name server failes wins query for www.pie.shop fails netbios broadcast for www.pie.shop fails x1 netbios broadcast for www.pie.shop fails x2 netbios broadcast for www.pie.shop fails x3 std query for www.pie.shop.newdotnet.net against my name server
newdotnet's NS replied with the IP for www.pie.shop.newdotnet.net & the echos came back.
I did mean to say in my last posting, everything *non-resolvable* outside the ICANN TLD's is resolved to 64.208.49.135
Existing new.net TLD domains resolve to whatever their IPs are.
The plug-in, however, sends ANY query outside the ICANN TLDs to 64.208.49.135. This usurps any and every other imaginable future TLD, ie www.bull.shit They're not advertising a 'shit' domain (um, literally), and yet requests for 'shit' go to their NS.
Their scheme, if successful, takes over service for EVERY TLD domain not already in operation by ICANN.
Who's the monopoly?
-----Original Message----- From: Kevin Loch [mailto:kloch@opnsys.com] Sent: Wednesday, March 14, 2001 5:57 PM To: Chris Davis; nanog@merit.edu Subject: Re: I've just tried new.net's plugin. Don't.
Chris Davis wrote:
I downloaded their plug-in and then:
What happens when you ping www.pie.shop which is in a new.net "private" TLD?
(snip)
Seems that everything in the world not ending with an ICANN TLD goes to 64.208.49.135. Have a look at http://64.208.49.135
That was probably meant to be somewhat meaningfull with names and not IP numbers. BTW, do you mean "everything not ending with an ICANN TLD or "everything not resolvable"? (see above)
KL
-----BEGIN PGP SIGNED MESSAGE-----
So the plug-in does *not* change which dns server you query. if a query fails against your normal name server it just appends .newdotnet.net or, if that fails, makes stuff up.
This is a decent description of how the client is currently working, except that it appends .new.net on to the end. When the resolver plugin can't resolve a domain, it offers up the IP of a web site that explains that the domain doesn't exist. This also contains framed Google results and was an experiment with improving the user experience. A wildcard was specifically not added to the root zone to attempt to avoid some issues. As has been pointed out on NANOG, this may cause more problems than its worth, specifically for non-browser applications. In the next update to the client, this feature will be removed. This should happen in a week or so. There will still be wildcards in the new.net TLDs. We did this for *.tv when we launched DotTV, and I'm not aware of significant problems with it. Even though this isn't in place for *.com, the typo-squatters catch the common mistakes anyway; DotTV and new.net at least also provide MX records that immediately bounce all mail. Should anyone be interested in offering more direct feedback about the specifics of the implementation of this project than to NANOG, please feel free to mail isp@new.net. There will also shortly be mailing lists available for announcements and discussion. Aaron Hopkins Systems Engineer, idealab! Acting VP of Engineering, new.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOrLsQUfJWHAEvsjBAQHh3wP/TUrhxC/TnhXdw9eCdh4s+8xhkyjBWNn7 Le+CoGyQ8ulnPoAEZa5pOjxg16SbxLnagSIzgS3b7YHRM6pA048lqfgzAckA+P4N mmpRe9BVUk1Kxvx51yVTUPE8OBJtgzEoV8x7xTNtrm/bgMPJVqm789w+jXLqg+OI SpsZ5AqOFbM= =WeGa -----END PGP SIGNATURE-----
Aaron Hopkins Systems Engineer, idealab! Acting VP of Engineering, new.net
have you really been here this long and not commented up until now. maybe you'd like to offer some other insight on the concerns raised in the longest nanog thread of all time. -ken harris.
On Fri, 16 Mar 2001 20:46:55 PST, Aaron Hopkins said:
Even though this isn't in place for *.com, the typo-squatters catch the common mistakes anyway; DotTV and new.net at least also provide MX records that immediately bounce all mail.
Two words: Scaling Issues. I saw recently that the root nameservers are currently running a flux of 10K-20K packets *per second*. *each*. Figure that there's 13 root servers, and they only see when a resolver needs to be reminded where .com, .org, .net are served from, so there's a lot more queries than THAT going on. Also, remember that bad queries probably make up an inordinate percentage of the lookups at the root and TLD levels - my local DNS already has cached the NS entries for the .COM tree and most of the foo.com's that I talk to. So it won't be recursing up for me unless I ask for broken.com or is-ok.comm or something like that. Now remember that a negative query reply will be on UDP in and one out. Buoncing the email immediately requires a minimum of 17 packets if you accept the mail (and 17 more later if you send a reply). You can get down to 13 packets if the host doing it blindly returns '550 User/host unknown' for each RCPT TO: But at that point, why bother having the MX? Leave it out, and let their resolver and their mail relay give the 'host unknown' error without any further load on YOUR resources above the 2 UDP packets. Valdis Kletnieks Operating Systems Analyst Virginia Tech
participants (4)
-
Aaron Hopkins -
ken harris. -
Kevin Loch -
Valdis.Kletnieks＠vt.edu