recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'

[Timothe Litt]

On 26-Aug-14 12:52, Doug Barton wrote:
> On 8/26/14 5:50 AM, Tomas Hozza wrote:
> | On 08/26/2014 02:27 PM, Mark Andrews wrote:
> |>> Why would you expect them to succeed?
> |
> | Because validation using root servers and authoritative servers
> | proved that the domain is intentionally unsecure.
>
> Tomas,
>
> It seems that Mark straightened you out a bit. :) I think it's
> worthwhile to discuss a little more of the theory for those watching
> the thread, and for the archives.
>
> The point of DLV initially was to provide a mechanism for sharing
> trust anchors for those that did not have a path through the root
> (which in the early days of course was everyone). Thus Mark's point
> that the lack of a path through the root not being conclusive is quite
> important.
>
> The other thing worth pointing out is that while it's certainly fine
> to test the DLV, and understand how it works, at this point in the
> evolution of DNSSEC the commonly accepted wisdom is that it should not
> be used routinely; and in fact should only be used when the admin
> knows that there is a TA in it that she needs, and that is not
> available with a path through the root.
>
> FWIW,
>
> Doug
>
>
I think this is misleading, or at least poorly worded and subject to
misinterpretation.

"Commonly accepted wisdom" -- by whom and when depends on on exactly
what you mean.

I will be as thrilled as anyone when (and if) the need for the DLV
disappears.  That time isn't now, and
as far as I can tell, isn't in sight.  If you mean to discourage
validating resolvers from consulting the DLV,
I disagree with that advice.

There are still many domains that are only secure thru DLV - the case I
keep screaming about
is in-addr.arpa, which most ISPs refuse to sign their pieces of and/or
refuse to provide secure
delegations to.  So, while the root is signed, and in-addr.arpa is
signed, the ISPs don't sign their
blocks and/or don't accept DS records from their customers to whom they
delegate static IP
addresses.  For many of us, there is no way to sign reverse IPv4/IPv6
addresses...other than
via DLV.  If you look at the dnssec-deployment mailing list, you'll see
this come up over and over again.
(Well, that list archive is temporarily inaccessible due to a server
migration divot...)

There are still registrars that don't accept DNSSEC records, and a
non-trivial number of domain holders
can't easily switch registrars.  This is getting better, but we're not
there yet.

I agree that an administrator should only enter data into the DLV when
there is no path from the root.
And that data in the DLV should be removed by the administrator when a
path from the root becomes available.

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.
Yes, consulting the DLV takes a few extra compute cycles.  Better that
than false failures.

So, until the DLV is empty, all my validating resolvers will continue to
use it - and I encourage others to use it as well.

It is not possible for the administrator of a validating resolver with a
non-trivial user community to know
what domains it will be asked to resolve.  DNSSEC false failures
discourage implementation - no one likes
more helpdesk calls.  Thus, the safe thing to do is to look in the DLV. 

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.

See dnssec-deployment for other discussions of this (sometimes
controversial) topic.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140826/5077297b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140826/5077297b/attachment.bin>