[142108] in North American Network Operators' Group
Re: ICANN to allow commercial gTLDs
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Jun 17 23:10:57 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <29272713.660.1308364822544.JavaMail.root@benjamin.baylink.com>
Date: Fri, 17 Jun 2011 20:02:41 -0700
To: Jay Ashworth <jra@baylink.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 17, 2011, at 7:40 PM, Jay Ashworth wrote:
> ---- Original Message -----
>> From: "Owen DeLong" <owen@delong.com>
>=20
>> That won't stop them from building zone files that look like this:
>>=20
>>=20
>> @ IN SOA ...
>> NS ...
>> ...
>> A ...
>> AAAA ...
>> www A ...
>> AAAA ...
>>=20
>> Sure, they'll advertise www.apple, but, you better believe that
>> they'll take whatever lands at http://apple and you can certainly
>> count on the fact that any mal-actors that get control of one of
>> these TLDs (whether they paid the $185k or not) will take full
>> advantage of the situation and its security risks.
>=20
> Not necessarily, Owen. Remember: Since we're *in the TLD space* now,=20=
> you can't capture the unmodified domain *without adding records to the=20=
> root*:
>=20
You can, actually...
It is perfectly valid for example, in COM to have:
delong.com. IN NS ns.delong.org.
IN NS =
ns2.delong.org.
and have ns/ns2 .delong.org. return the following:
delong.com. IN SOA .......
IN NS =
ns.delong.org.
=
ns2.delong.org.
A =
192.159.10.2
AAAA =
2620:0:930::200:2
www IN A 192.159.10.7
AAAA =
2620:0:930::400:7
Why would this not work equally well for APPLE where the
root zone would have:
apple. IN NS ......
IN NS ......
Where you would then have the detail (as above in the delong.com
zone file) contained in the apple. zone file on the specified
authoritative nameservers?
> apple.com and www.apple.com are in the same zone file
apple and www.apple are in the same zone file to that extent
as well.
apple.com is a delegation from .com just as apple is a delegation from .
> apple. and www.apple. are *not* -- and the root operators may throw
> their hands up in the air if anyone asks them to have anything in =
their
> zone except glue -- rightly, I think; it's not a degree of complexity
> that's compatible with the required stability of the root zone.
>=20
Sir, either you are very confused, or, I am. I am saying that TLDs
behave with the same delegation rules as SLDs, which I believe
to be correct. You are claiming that TLDs are in some way magical
and that the ability to delegate begins at SLDs. I think the fact that
there is data in the COM zone separate from the root indicates that
I am correct.
> Especially since the root zone actually lives in 14 different places.
>=20
But the root zone would still only contain delegation and possibly glue.
Everything else would still be in the zone file, just like a =
subdelegation
of COM for apple.com, but, this would be a subdelegation of . for =
apple.
> No, anything that requires the root zone to be fluid[1] is going to =
cause even
> more fundamental engineering problems than I've been positing so far =
tonight.
>=20
I agree, but, this doesn't require that to happen. It might cause it to =
happen
without root zone operator intervention (which may be worse), but, it =
doesn't
require the root zone operators to cooperate beyond delegating the TLDs
which seems pretty much assured by the current announcement.
Owen
