[174503] in North American Network Operators' Group
Re: Bare TLD resolutions
daemon@ATHENA.MIT.EDU (David Conrad)
Wed Sep 17 12:46:23 2014
X-Original-To: nanog@nanog.org
From: David Conrad <drc@virtualized.org>
In-Reply-To: <18573980.1992.1410970155561.JavaMail.root@benjamin.baylink.com>
Date: Wed, 17 Sep 2014 09:46:12 -0700
To: Jay Ashworth <jra@baylink.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--Apple-Mail=_B89184DD-037E-44D3-BA56-64B71AAB644F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Jay,
On Sep 17, 2014, at 9:09 AM, Jay Ashworth <jra@baylink.com> wrote:
> it seems there are two major potential points of possible collision:
>=20
> 1) User network uses "fake" TLD which is no longer fake, and local=20
> resolver server blows it
>=20
> 2) User network blows it worse, and tries to resolve a monocomponent =
name
> off non-local servers.
A common case of name collision is driven by the =93DNS search path=94, =
e.g., if you have a =93search path=94 of =93bar.com;foo.bar.com=94 and =
you type =93telnet baz=94, _some_ resolver libraries will try to resolve =
=93baz.bar.com=94, if that fails then =93baz.foo.bar.com=94, if that =
fails then =93baz.=94, if that fails return an error to the user.
However, the "search path=94 algorithm was never fully standardized and =
there are implementations that try =93baz.=94 first (there are even some =
implementations that will split up the path elements, e.g., if =
=91baz.bar.com=92 fails, the resolver library will try =91baz.com=92).
In my view, given the lack of standardization and the potential security =
implications, search paths shouldn=92t be used at all.
> The latter would seem to be avoidable by making sure that *DNS =
resolution
> of bare TLDs always returns NXDOMAIN*.
It is quite rare that a TLD is queried for directly. Resolver libraries =
generally do not parse the name being queried and send the minimum to =
the authoritative servers. That is, if a resolver is asked for =
=93foo.bar.com=94, it sends the entire string to the root server and =
gets back a referral to the COM servers =97 it generally does not parse =
=93foo.bar.com=94 to get the TLD and send =93COM=94 to the root servers =
to get the referral. This latter behavior is called =93QNAME =
minimization=94 and is a good idea for performance and privacy (and =
other reasons), but not yet generally implemented because it is a bit =
tricky in the general case.=20
> If it isn't, does anyone know of any domains dumb enough to actual=20
> return something for a lookup on the bare TLD?
There are a few ccTLDs that provide apex wildcards: they=92ll return an =
=93A=94 record for any random goop (.WS is an example), however this =
behavior is banned from gTLDs (an outcome of the SiteFinder debacle).
> Is there actually *any* good reason why a lookup on a bare TLD =
("com.")
> might return a valid record?
Some of the folks in ICANN=92s new gTLD program, typically the folks =
who=92ve gone for =93brand=94 TLDs (e.g., .bmw), have argued for what=92s =
called =93dotless=94 domains: they want people to be able to do stuff =
like point their browsers at =93http://bmw=94 and have the web page for =
BMW show up. Unfortunately for them, several oceans have already gone =
under that particular bridge (see =
https://www.icann.org/en/system/files/files/sac-053-en.pdf) and ICANN =
has (to date) resisted those requests. (I actually don=92t know if the =
folks behind .BMW wanted dotless domains =97 just using BMW as an =
example)
> And what about Naomi?
Never was a big fan of the chair.
Regards,
-drc
--Apple-Mail=_B89184DD-037E-44D3-BA56-64B71AAB644F
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
iQEcBAEBCgAGBQJUGbrUAAoJENV6ebf0/4rXbjUH+QHU8B40ClHanN6keNaZZbYC
0obKxQmZyLCGTJvt9IHuCmHDErXSDSaKVwtAsR+/0sY5gjFuFsGqdVHO+JdRUZ6C
Etof6MYJzy0QANdOpQynyQt9Tve9LSKKpgYQo6mjsmG1v72cFaWDv+Kh3XuQlD3S
DN2btnHzrnMiU80/UYd7JlKLmLVNmHlrvza3J8Bhc6RkiZPVG4WCOKfmYk03zTAy
4gDerFwKPviTZzgCeAVV2z+GUHE84VvcSsDzaH7LUzfK1ON8ucHRdoz2z0+olga8
fuxo8Rf5+7tVF79B4zGwp2MrS27SLkMAafnfyCsSHP1+E9nD9SgG1I+nMvkWzYI=
=BBje
-----END PGP SIGNATURE-----
--Apple-Mail=_B89184DD-037E-44D3-BA56-64B71AAB644F--
