[174528] in North American Network Operators' Group
Re: Bare TLD resolutions
daemon@ATHENA.MIT.EDU (David Conrad)
Wed Sep 17 18:32:03 2014
X-Original-To: nanog@nanog.org
From: David Conrad <drc@virtualized.org>
In-Reply-To: <0EF9B30B-EFEB-40AD-A36A-E50CC9987539@cisco.com>
Date: Wed, 17 Sep 2014 15:31:50 -0700
To: "Fred Baker (fred)" <fred@cisco.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--Apple-Mail=_2302B19E-CC3B-45CE-9C27-A36298A5578F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Fred,
On Sep 17, 2014, at 3:04 PM, Fred Baker (fred) <fred@cisco.com> wrote:
> IMHO, since ICANN has created the situation,=20
ICANN has created ill-specified domain search path heuristics and truly =
fascinating implementations of those heuristics? ICANN has caused =
people to use non-allocated TLDs in environments where queries for those =
non-allocated TLDs hit the public Internet? ICANN had made applications =
dependent upon receiving NXDOMAINs in a way that implies the root of the =
DNS should never be expanded (even for country codes or =
internationalized domain names)?
> the ball is in ICANN=92s court to say how this works without =
disrupting name services.
Actually, name services aren=92t disrupted. They are behaving exactly as =
specified in the DNS and as intended. What is disrupted is (typically =
unknown) assumptions people have made regarding the composition of the =
top-level of the domain namespace. ICANN has been working to try to help =
mitigate the issue for some time now (initial discussions occurred in =
2010).
> Their ill-informed hipshot is not our emergency.
Hipshots are generally not a good idea, regardless of whether they are =
ill-informed.=20
Whose emergency it is probably depends on how the delegation of new =
top-level domains impacts the operation of your network. To date, in =
cases where there was impact, the affected parties have worked to =
address the issues and (AFAIK) no emergencies have been experienced.
Regards,
-drc
--Apple-Mail=_2302B19E-CC3B-45CE-9C27-A36298A5578F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJUGgvWAAoJENV6ebf0/4rXOmUH/A18L0T9qr+RZTxdroxu75JT
X6c0OBW1hQJs2SH/YIfX13zsCTyClIUGaRZBpaORKpFOMqUMYB2ukAeyan5dUdfP
hSc7DsDAZYzmITpR3DF8JAvzJKVDIADHpgOBBal0RVGVfoSq9h0lWgh2fxPosP1N
N39tHA9Hx5PSP5WXAIsjlkQj7qFqVQ4un+Oxs/BIIvZ/u/2+Vo/g3yhWMlUmLfDV
OkFO7B9sfIoj15p2e8w4ge1jWPdHI9iB03BroE2cKH/YQDCDfkxzgAOoY2vZSqxT
7+I25IOx+umUOfXE2LQZ4BD8RIepEGhYorrAXyhRqu1kqQJowW3X2bMlU+OLYmE=
=aEAZ
-----END PGP SIGNATURE-----
--Apple-Mail=_2302B19E-CC3B-45CE-9C27-A36298A5578F--
