discuss AT lists.opennicproject.org
Subject: Discuss mailing list
List archive
- From: Bersl <bersl2 AT bersl2.info>
- To: discuss AT lists.opennicproject.org
- Subject: Re: [opennic-discuss] FW: New gTLD Customer Service Case
- Date: Mon, 16 Jul 2012 08:54:52 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
They aren't going to reverse course, and I'm not even sure that this
is so big a deal. (What are they gonna do? Vow extra hard never to
accept our TLDs? Create stub zones that redirect to shock sites?) I
would characterize a non-reaction as the best and most likely possible
outcome in the short term.
As for the longer-term issue: If ICANN's version of the TLD gets
barely any traffic, then the collision isn't a problem. If a few sites
in the ICANN TLD become popular, those can be added by the operator of
the OpenNIC TLD (not sure about procedure, though).
If many important names within the ICANN TLD become popular... then it
might be time to consider whether there is (or should be) a way to
have BIND or some other nameserver first check its authoritative zones
for a result and, if the answer would otherwise be NXDOMAIN, attempt
to recursively resolve from an ICANN-rooted server? (Is such a thing
even compatible with DNSSEC?)
Alternatively (or additionally?), we could have a .icann TLD in our
root, which could proxy ICANN's versions of the TLDs. This breaks some
CMSes, but what's that saying about needing to break a few eggs?
(Note that the above is not exactly like the NXDOMAIN hijacking we
(all?) hate. If it's not present in our root, and it's not present in
their root, we would return NXDOMAIN: the domain is not here or there,
so end of story.)
I'm sure someone has better ideas, though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJQBB0kAAoJEGZIAx6yDQgG49wH/2fiT5b1vnjCPAushjvBvYwD
A3LzFj7XjTu3tGKqFXoe0fJn5dGNHijKogRjziqdGPqyH4DaUzyf2/HUBKsAyCce
lQaSMTqeURhn+nlxVr2Tpv9wusfJih7IMMHfXf2+9UIY2ofodk9fy8jOi5hvSxhy
XP9QwOBr3zfwLcoI0H8Qeuaj9Lz1CNhOPxkttY9yViwMLBjIUseSZdKsL104Tud7
dHYh/Clwy0ocvfXSRmotOssDBx/Mj1ywOIOkovX5/xmposzDWJKY98qXD+kwNc4c
SL3UeBnCk5+0XAIgK6m+UXPcBAlAiv3lVC/E0uSZF5mj1MsMu7CzdoW/Szmvq2U=
=qhxa
-----END PGP SIGNATURE-----
- [opennic-discuss] FW: New gTLD Customer Service Case, Alexander Nordlund, 07/16/2012
- Re: [opennic-discuss] FW: New gTLD Customer Service Case, Filip Lamparski, 07/16/2012
- Re: [opennic-discuss] FW: New gTLD Customer Service Case, Bersl, 07/16/2012
- Re: [opennic-discuss] FW: New gTLD Customer Service Case, Brian Koontz, 07/17/2012
- <Possible follow-up(s)>
- RE: [opennic-discuss] FW: New gTLD Customer Service Case, David Norman, 07/16/2012
- Re: [opennic-discuss] FW: New gTLD Customer Service Case, sjeap, 07/17/2012
- [opennic-discuss] FW: New gTLD Customer Service Case, Alexander Nordlund, 07/25/2012
Archive powered by MHonArc 2.6.19.