Subject: [dnsext] Re: DNSCurve

From: Matthew Dempsky <[email-masked]>
Date: Mon, 18 May 2009 14:58:51 -0700

On Mon, May 18, 2009 at 9:51 AM, Matthew Dempsky <[email-masked]> wrote:
> On Mon, May 18, 2009 at 1:10 AM, Stephane Bortzmeyer <[email-masked]> wrote:
>> Integrity despite         Protects against         Does not protect against
>> rogue secondary name      it                       it
>> servers of resolvers
>
> Somewhat agree.  I don't have much more time to reply to emails right
> now, so I'll just offer an IOU to expand upon this later.

For now, I'll go ahead and change my response to "Agree," but I'd like
to point out at least one thing on this topic.

Right now there are 13 root servers and 8 .fr servers.  However, there
are about another 120 name servers that could poison the entire .fr
domain if they were "rogue".  E.g., ns.via.net is a name server for
zocalo.net, ns.zocalo.net is a name server for ucsc.edu, ns1.ucsc.edu
is a name server for princeton.edu, dns.princeton.edu is a name server
for inria.fr, dns.inria.fr is a name server for nic.fr, and all of the
.fr name servers are within nic.fr.  I don't mean to imply any malice
on the part of ViaNet (I picked them as a somewhat arbitrary example
among the 120 possible candidates), but as it is, their name servers
could poison any public DNS cache with bogus .fr data without much
difficulty.

This is a risk that every domain in .fr faces today, and one that can
be fixed by purely administrative means (e.g., see how .se, .jp, and
.biz are setup).  Deploying DNSSEC everywhere could fix this too, but
why wait?  If not protecting against rogue secondary name servers is
considered a mark against DNSCurve, shouldn't more TLDs be organized
to avoid these kinds of frivolous third party dependencies?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 May 2009 17:16:33 +0200

On Mon, May 18, 2009 at 02:58:51PM -0700,
 Matthew Dempsky <[email-masked]> wrote 
 a message of 30 lines which said:

> shouldn't more TLDs be organized to avoid these kinds of frivolous
> third party dependencies?

We are drifting far away from DNScurve but do note it is NOT
"frivolous third party dependencies" but a deliberate design
decision. There have been MANY debates in the TLD community between
the single-engined (all the name servers in one domain, and no
dependency) and the multi-engined approach and there is no consensus
yet (check .DE or .ORG).

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 19 May 2009 11:52:05 -0700

On Tue, May 19, 2009 at 8:16 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> We are drifting far away from DNScurve

Yes, but I think the point you were arguing against DNSCurve was hypocritical.

> but do note it is NOT
> decision.

I'll gladly admit to not having any experience running a TLD.  Would
you mind elaborating on the design decisions that led the .fr
administrators to make itself dependent on these "not frivolous" third
parties then?  E.g., why was the current configuration chosen in
preference to one like .se:

    fr. NS a.ns.fr.
    fr. NS b.ns.fr.
    fr. NS c.ns.fr.
    fr. NS d.ns.fr.
    fr. NS e.ns.fr.
    fr. NS f.ns.fr.
    fr. NS g.ns.fr
    fr. NS h.ns.fr.
    a.ns.fr. A 192.93.0.129
    a.ns.fr. AAAA 2001:660:3005:3::1:1
    b.ns.fr. A 192.228.90.21
    c.ns.fr. A 192.134.0.129
    c.ns.fr. AAAA 2001:660:3006:4::1:1
    d.ns.fr. A 204.152.184.85
    d.ns.fr. AAAA 2001:4f8:0:2::8
    e.ns.fr. A 193.176.144.6
    f.ns.fr. A 194.57.253.1
    g.ns.fr. A 194.146.106.46
    h.ns.fr. A 204.61.216.39
    h.ns.fr. AAAA 2001:500:14:6039:ad::1

There's no need to make ns.fr a separate zone; just serve these
records directly from the .fr zone.  There's currently no ns.fr zone,
so you could even transition to this today and leave nic.fr untouched.
 The equivalent *.nic.fr records are already present in both the .fr
zone and the root zone, so there's no additional work to maintain the
new records' correctness.

What detail am I missing about why you decided to place the .fr name
servers within a zone under the control of untrusted third parties?

> There have been MANY debates in the TLD community between

Here are the list of name server names that these two TLDs are
transitively dependent upon:

    de: a.gtld-servers.net, a.nic.de, a2.nstld.com,
b.gtld-servers.net, c.de.net, c.gtld-servers.net, c2.nstld.com,
d.gtld-servers.net, d2.nstld.com, e.gtld-servers.net, e2.nstld.com,
f.gtld-servers.net, f.nic.de, f2.nstld.com, g.gtld-servers.net,
g2.nstld.com, h.gtld-servers.net, h2.nstld.com, i.gtld-servers.net,
j.gtld-servers.net, k.gtld-servers.net, l.de.net, l.gtld-servers.net,
l2.nstld.com, m.gtld-servers.net, ns1.denic.de, ns2.denic.de,
ns3.denic.de, ns4.denic.net, ns5.denic.net, s.de.net, z.nic.de

    org: a0.info.afilias-nst.info, a0.org.afilias-nst.info,
a2.info.afilias-nst.info, a2.org.afilias-nst.info,
b0.info.afilias-nst.org, b0.org.afilias-nst.org,
b2.info.afilias-nst.org, b2.org.afilias-nst.org,
c0.info.afilias-nst.info, c0.org.afilias-nst.info,
d0.info.afilias-nst.org, d0.org.afilias-nst.org,
ns1.ams1.afilias-nst.info, ns1.hkg1.afilias-nst.info,
ns1.mia1.afilias-nst.info, ns1.sea1.afilias-nst.info,
ns1.yyz1.afilias-nst.info

Here's the list of names that .fr is transitively dependent upon:

    fr: a.gtld-servers.net, a.nic.fr, a.ns.kth.se, a.ns.se,
a0.info.afilias-nst.info, a0.org.afilias-nst.info,
a2.info.afilias-nst.info, a2.nstld.com, a2.org.afilias-nst.info,
ams.sns-pb.isc.org, arizona.edu, b.ext.nic.fr, b.gtld-servers.net,
b.ns.kth.se, b.ns.se, b0.info.afilias-nst.org, b0.org.afilias-nst.org,
b2.info.afilias-nst.org, b2.org.afilias-nst.org,
backup-server.nordu.net, benoni.uit.no, biff.uninett.no,
c.gtld-servers.net, c.nic.fr, c.ns.se, c0.info.afilias-nst.info,
c0.org.afilias-nst.info, c2.nstld.com, cheltenham.cs.arizona.edu,
cs.wisc.edu, d.ext.nic.fr, d.gtld-servers.net, d.ns.se,
d0.info.afilias-nst.org, d0.org.afilias-nst.org, d2.nstld.com,
dikahble.princeton.edu, dns.cs.wisc.edu, dns.inria.fr,
dns.itcs.umich.edu, dns.itd.umich.edu, dns.princeton.edu, dns.uu.se,
dns1.uslec.net, dns1.uu.se, dns2.cs.wisc.edu, dns2.itcs.umich.edu,
dns2.itd.umich.edu, dns2.uslec.net, dns2.uu.se, dns3.uslec.net,
dns4.uslec.net, dns5.uslec.net, e.ext.nic.fr, e.gtld-servers.net,
e.nic.fr, e.ns.se, e2.nstld.com, f.ext.nic.fr, f.gtld-servers.net,
f.ns.se, f2.nstld.com, g.ext.nic.fr, g.gtld-servers.net, g.ns.se,
g2.nstld.com, h.gtld-servers.net, h.ns.se, h2.nstld.com,
harbor.ecn.purdue.edu, i.gtld-servers.net, i.nic.no, i.ns.se,
imag.imag.fr, isis.imag.fr, j.gtld-servers.net, j.ns.se,
k.gtld-servers.net, l.gtld-servers.net, l2.nstld.com, lozen.uit.no,
m.gtld-servers.net, moe.rice.edu, nac.no, nez-perce.inria.fr,
nic.lth.se, nic2.lth.se, njet.norid.no, nn.uninett.no, not.norid.no,
ns-ext.isc.org, ns-ext.lga1.isc.org, ns-ext.nrt1.isc.org,
ns-ext.sth1.isc.org, ns-pri.ripe.net, ns-remote.arizona.edu,
ns-sec.ripe.net, ns.purdue.edu, ns.via.net, ns.zocalo.net,
ns0.oleane.net, ns1.ams1.afilias-nst.info, ns1.chalmers.se,
ns1.fast.net, ns1.hkg1.afilias-nst.info, ns1.mia1.afilias-nst.info,
ns1.nic.fr, ns1.oleane.net, ns1.rice.edu, ns1.sea1.afilias-nst.info,
ns1.ucsc.edu, ns1.yyz1.afilias-nst.info, ns2.chalmers.se,
ns2.fast.net, ns2.nic.fr, ns2.purdue.edu, ns2.rice.edu, ns2.sunet.se,
ns2.ucsc.edu, ns2.via.net, ns2.zocalo.net, ns3.chalmers.se,
ns3.nic.fr, ns3.via.net, ns3.zocalo.net, ns4.zocalo.net,
optima.cs.arizona.edu, ord.sns-pb.isc.org, pendragon.cs.purdue.edu,
server.nordu.net, sfba.sns-pb.isc.org, sns-pb.isc.org, sunic.sunet.se,
x.nic.no, y.nic.no, z.nic.no

The .de and .org TLDs still have some somewhat silly dependencies, but
looking at it from an organizational level instead, .org is only
dependent upon Afilias, and .de is only dependent upon Verisign and
DENIC.  On the other hand, .fr is also dependent upon a bunch of
school, private companies, and other organizations.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 20 May 2009 01:00:14 -0700

> transitively dependent upon:

To help visualize this, I've put together graphs showing the
transitive dependencies for every TLD at
http://shinobi.dempsky.org/~matthew/dnstrust/graphs/.  Particularly
relevant ones:

http://shinobi.dempsky.org/~matthew/dnstrust/graphs/fr.pdf
http://shinobi.dempsky.org/~matthew/dnstrust/graphs/de.pdf
http://shinobi.dempsky.org/~matthew/dnstrust/graphs/org.pdf
http://shinobi.dempsky.org/~matthew/dnstrust/graphs/se.pdf
http://shinobi.dempsky.org/~matthew/dnstrust/graphs/jp.pdf
http://shinobi.dempsky.org/~matthew/dnstrust/graphs/biz.pdf