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:
-----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
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.
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