<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
On 26-Aug-14 12:52, Doug Barton wrote:<br>
<blockquote type="cite">On 8/26/14 5:50 AM, Tomas Hozza wrote:<br>
| On 08/26/2014 02:27 PM, Mark Andrews wrote:<br>
|>> Why would you expect them to succeed?<br>
|<br>
| Because validation using root servers and authoritative servers<br>
| proved that the domain is intentionally unsecure.<br>
<br>
Tomas,<br>
<br>
It seems that Mark straightened you out a bit. :) I think it's<br>
worthwhile to discuss a little more of the theory for those
watching<br>
the thread, and for the archives.<br>
<br>
The point of DLV initially was to provide a mechanism for sharing<br>
trust anchors for those that did not have a path through the root<br>
(which in the early days of course was everyone). Thus Mark's
point<br>
that the lack of a path through the root not being conclusive is
quite<br>
important.<br>
<br>
The other thing worth pointing out is that while it's certainly
fine<br>
to test the DLV, and understand how it works, at this point in the<br>
evolution of DNSSEC the commonly accepted wisdom is that it should
not<br>
be used routinely; and in fact should only be used when the admin<br>
knows that there is a TA in it that she needs, and that is not<br>
available with a path through the root.<br>
<br>
FWIW,<br>
<br>
Doug<br>
<br>
</blockquote>
<span style="white-space: pre;">></span><br>
I think this is misleading, or at least poorly worded and subject to
misinterpretation.<br>
<br>
"Commonly accepted wisdom" -- by whom and when depends on on exactly
what you mean.<br>
<br>
I will be as thrilled as anyone when (and if) the need for the DLV
disappears. That time isn't now, and<br>
as far as I can tell, isn't in sight. If you mean to discourage
validating resolvers from consulting the DLV,<br>
I disagree with that advice.<br>
<br>
There are still many domains that are only secure thru DLV - the
case I keep screaming about<br>
is in-addr.arpa, which most ISPs refuse to sign their pieces of
and/or refuse to provide secure<br>
delegations to. So, while the root is signed, and in-addr.arpa is
signed, the ISPs don't sign their<br>
blocks and/or don't accept DS records from their customers to whom
they delegate static IP<br>
addresses. For many of us, there is no way to sign reverse
IPv4/IPv6 addresses...other than<br>
via DLV. If you look at the dnssec-deployment mailing list, you'll
see this come up over and over again.<br>
(Well, that list archive is temporarily inaccessible due to a server
migration divot...)<br>
<br>
There are still registrars that don't accept DNSSEC records, and a
non-trivial number of domain holders<br>
can't easily switch registrars. This is getting better, but we're
not there yet.<br>
<br>
I agree that an administrator should only enter data into the DLV
when there is no path from the root.<br>
And that data in the DLV should be removed by the administrator when
a path from the root becomes available.<br>
<br>
Yes, it's possible that one can trip over stale data in the DLV -
this hasn't been common in my experience, and has been easily fixed.<br>
Yes, consulting the DLV takes a few extra compute cycles. Better
that than false failures.<br>
<br>
So, until the DLV is empty, all my validating resolvers will
continue to use it - and I encourage others to use it as well.<br>
<br>
It is not possible for the administrator of a validating resolver
with a non-trivial user community to know<br>
what domains it will be asked to resolve. DNSSEC false failures
discourage implementation - no one likes<br>
more helpdesk calls. Thus, the safe thing to do is to look in the
DLV. <br>
<br>
I do agree that in an ideal world, retiring the DLV would be worth
celebrating. We're not there, and until we are, my advice is that
resolvers consult the DLV. It's not perfect, but it's what we have.<br>
<br>
See dnssec-deployment for other discussions of this (sometimes
controversial) topic.<br>
<br>
<pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
<br>
<br>
<br>
</body>
</html>