To DLV or not to DLV [was Re: recursive lookups for UNSECURE names ...]

[Chris Thompson]

On Aug 28 2014, Doug Barton wrote:

>On 8/27/14 3:03 PM, Timothe Litt wrote:
>> So you really meant that validating resolvers should only consult DLV if
>> their administrator knows that users are looking-up names that are in
>> the DLV?  That's how I read your advice.
>
>You're correct.
>
>> I don't see how that can work; hence we'll disagree.  I think the only
>> viable strategy for*resolvers*  is to consult the DLV - as long as it
>> exists.
>
>So that leads to a Catch-22, as ISC has stated that they will continue 
>to provide the DLV as long as it is used. You're saying that people 
>should continue to consult it as long as it exists.

I agree with that. The line I have been taking is that we will continue
to use validation via dlv.isc.org (as well as via the root, of course)
on our recursive nameservers as long as we have to register signed zones
there ourselves.

It is quite disappointing that we haven't reached that stage yet ...

>Now that the root is signed the traditional argument against continued 
>indiscriminate use of the DLV is that it makes it easier for registries, 
>service providers, etc. to give DNSSEC a low priority. "You don't need 
>me to provide DNSSEC for you, you can use the DLV." Based on my 
>experience I think there is a lot of validity to that argument, although 
>I personally don't think it's persuasive on its own.

Jim Reid used to make that point a lot (and probably still does) when
arguing against the mere existence of DLV. However, the organisation
blocking progress for us has never made an excuse as cogent as that.
We just can't get any communication going with them on the subject
at all. 

To come clean: as part of the UK higher education community, we really
are stuck with using JANET. The political problems of disassociating
ourselves from them (and it has been muttered about in the past, in
the context of their network charges) are sufficiently horrific that
we could never justify it simply on the basis of their absence of
DNSSEC support in the reverse zone context.

Which is where we are stuck. JANET did sign the primary forward zone
ac.uk in early 2011, and provided methods for getting DS records for
delegations into it. This was actually fairly good compared to many
similar organisations. But having achieved this, and despite verbal
assurances at the time that the other zones (including reverse ones)
they were responsible would get signed as well, they seem to have
taken their eye entirely off the DNSSEC ball now.

What makes this even more frustrating is that, as early users of
the Internet much of our IPv4 space is in "legacy" (ERX) allocations
and the reverse zones for it are directly delegated from the reverse
zones manged by the RIRs. Those got signed in early 2011 as well,
and the mechanisms to maintain DS records in them (which involve
the communication mechanisms between the RIRs) work well. (A lot
of thanks are due to members of the RIPE DNS working group in that
context.) So for these reverse zones we have had a chain of trust
from the root for over 3 years now.

But a significant chunk of IPv4 space, acquired later, and all of
our IPv6 space, have reverse zones delegated from ones maintained
by JANET, themselves delegated from the RIPE NCC ones. As the
intermediate parent zones are unsigned, these are the ones we
still have to register in dlv.isc.org.

It is sometimes argued that validating reverse zone contents is
unimportant, and that theyhave only the nature of hints in any case.
I have always taken the converse line that if something is in the
public DNS at all, it ought to be signed. But our tribulations
summarised above (and believe me, I could go on about it at *much*
greater length! you should be grateful) have occasionally made me
regret that.

-- 
Chris Thompson
Email: cet1 at cam.ac.uk