Subject: [DNSOP] Obsoleting DLV

From: Matthijs Mekking <[email-masked]>
Date: Tue, 2 Jul 2019 20:12:51 +0200

Hi,

A while back I was asked why BIND 9 still had code to do DLV. Good
question, and we asked our users if they would mind if we remove the
code. Almost everyone was okay with that.

So ISC plans to deprecate the feature in BIND 9.  But also I think it is
time to move the protocol to Historic status as a clear signal to
everyone that it should no longer be implemented or deployed.

Dan Mahoney cleared the only well-known DLV registry almost two years
ago. Here's a draft with discussion why also the protocol should go
away. We would like to hear what you think about it.

Best regards,

Matthijs

-------- Forwarded Message --------
A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt
has been successfully submitted by Matthijs Mekking and posted to the
IETF repository.

Name:	  draft-mekking-dnsop-obsolete-dlv
Revision: 00
Title:	  Moving DNSSEC Lookaside Validation (DLV) to Historic Status
Pages:	  5
Status:

  https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/

Abstract:
   This document obsoletes DNSSEC lookaside validation (DLV) and
   reclassifies RFCs 4431 and 5074 as Historic.

---

From: David Conrad <[email-masked]>
Date: Tue, 2 Jul 2019 11:14:51 -0700

I strongly support moving it to Historic.

Regards,
-drc

> On Jul 2, 2019, at 11:12 AM, Matthijs Mekking <[email-masked]> wrote:
> 
> Hi,
> 
> 
>  https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/ <https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/>
> 
> Abstract:
> _______________________________________________
> DNSOP mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Jul 2019 14:41:48 -0400 (EDT)

> everyone that it should no longer be implemented or deployed.

I agree with moving DLV to historic. It is no longer needed at large,
and while it can serve a few corner cases, the only public DLV registry
has been deactivated years ago, and DLV is not universally implemented
to begin with, so one could not depend on a new to be launched DLV registry
anyways.

The draft seems to explain it well.

>  https://datatracker.ietf.org/doc/draft-mekking-dnsop-obsolete-dlv/

 	"As of May 2019, the root zone is signed"

While it is correct that in May 2019, the root zone is signed, I don't
think that's the information you are trying to relay :) :) :)

3.1.1.2.  I-D.lhotka-dnsop-iana-class-type-yang

    The draft "YANG Types for DNS Classes and Resource Record Types"
    [I-D.lhotka-dnsop-iana-class-type-yang] refers to RFC 4431 to
    describe the DLV entry in the YANG module iana-dns-class-rr-type.
    This reference should be removed.

I think this does not need to be in this document, but the authors
should be requested to remove it in an update to their document.
In general, yang documents should not populate IANA registries, which
is something I raised afew months ago and the yang community is looking
at that. (and reference IANA registries instead)

And I think Ond&#345;ej  should fix up his name :)

Paul

---

From: Warren Kumari <[email-masked]>
Date: Tue, 2 Jul 2019 12:23:25 -0700

> away. We would like to hear what you think about it.

Yes please; DLV was a useful tool to get DNSSEC off the ground, but had
long outlived its usefulness, and is now just extra code to fail.

Rip it out,
W

> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Joe Abley <[email-masked]>
Date: Tue, 2 Jul 2019 15:28:05 -0400

+1 to all of that which follows!

> On 2 Jul 2019, at 14:41, Paul Wouters <[email-masked]> wrote:
>

---

From: Jim Reid <[email-masked]>
Date: Tue, 2 Jul 2019 20:31:23 +0100

> On 2 Jul 2019, at 19:12, Matthijs Mekking <[email-masked]> wrote:
> 
> I think it is time to move the protocol to Historic status as a clear signal to

Agreed. Kill it with fire!

---

From: Erwin Lansing <[email-masked]>
Date: Tue, 2 Jul 2019 21:39:12 +0200

> On 2 Jul 2019, at 21.31, Jim Reid <[email-masked]> wrote:
> 
> 
> 

Should have know last week, we had a nice big bonfire just for the occasion :-)

Yes, please put it out of its misery.

Erwin

---

From: Dan York <[email-masked]>
Date: Tue, 2 Jul 2019 20:11:36 +0000

> On Jul 2, 2019, at 3:31 PM, Jim Reid <[email-masked]> wrote:
> 
> 
> 

Yes, please!  We can celebrate all it did to help get DNSSEC going, but that time is now long gone.

Dan

---

From: Paul Vixie <[email-masked]>
Date: Tue, 02 Jul 2019 17:02:13 -0700

fine by me.

⁣Get BlueMail for Android ​

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 3 Jul 2019 18:30:32 +0400

On Tue, Jul 2, 2019 at 10:13 PM Matthijs Mekking <[email-masked]>
wrote:

> I think that it's worth going forward.

ISC BIND commit:
https://github.com/isc-projects/bind9/commit/f29359299aaab519f39b090cd83de85cd2fc3820

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 7 Jul 2019 02:58:20 -0400

The chairs discussed this and the "process" moving documents to Historic is
varied based on the documentation.
(https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/).
We've assigned our IESG Overlord to do what
IESG Overlords do in these situations.  From reading the available options,
this chair prefers option #2, which
involves a small amount of work on the working group, and then hands it
over to our AD.

Once the chairs are given a sign, we'll let all know.

tim

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 8 Jul 2019 21:13:53 -0400 (EDT)

On Tue, 2 Jul 2019, Matthijs Mekking wrote:

> Here's a draft with discussion why also the protocol should go

No objection.  I'm not aware of any active private use of DLV.

Thank you for doing the detailed work of looking up the citations and 
figuring out the dependencies.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 24 Jul 2019 19:22:01 -0400 (EDT)

> away. We would like to hear what you think about it.

The discussion of the private network use case in section 2 has two 
minor errors plus one bit that is unclear.

When we designed DLV, we certainly considered a private network use 
case.  RFC5074 does not strictly have public trust anchors take 
precedence over ("mask") DLV records [1].

I suggest replacing the text in section 2 starting with "One other..." 
with:

    One other possible reason to keep DLV is to distribute trust anchors
    for private enterprises.  The authors are not aware of any such use
    of DLV.

That does not include the argument in the below bullet, which I find 
unclear.  What does "name redirection" mean in this context?

    o  Since the zones are related to private networks, it would make
       more sense to make the internal network more secure to avoid name
       redirection, rather than complicate the DNS protocol.

-- Sam

[1] Specifically, 5074 says to use public trust anchors first.  If 
they give a validation result other than "Secure", then do DLV 
processing.  I'm not 100% sure of how BIND's logic works here.

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Jul 2019 12:10:44 +0100

Samuel Weiler <[email-masked]> wrote:
>
> That does not include the argument in the below bullet, which I find unclear.
> What does "name redirection" mean in this context?
>

I guess it's referring to active DNS modification attacks?

Another reason not mentioned in the draft is resilience against loss of
connectivity. If you have a local trust anchor you can validate local
zones even when you can't reach the outside world. With normal DNSSEC
validation everything is screwed if you can't obtain the chain of trust.

Of course, the network should be secure and reliable in its lower layers,
but I tend to think the DNS should be secure and reliable itself, even if
the lower layers are a bit dodgy.

Having thought about this a bit, I now prefer something like catalog zones
as a way to distribute trust anchors.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: Variable 2 to 4 in east Lundy, otherwise southerly veering
southwesterly 4 to 6. Slight or moderate in east Lundy, but elsewhere moderate
or rough. Thundery showers. Moderate or good.

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 25 Jul 2019 14:59:39 +0200

Sam,

> precedence over ("mask") DLV records [1].

I read text from RFC 6840 (Section C.3):

   When the trust anchors have come from different sources (e.g.,
   automated updates ([RFC5011]), one or more DNSSEC Lookaside
   Validation (DLV) registries ([RFC5074]), and manual configuration), a
   validator may wish to choose between them based on the perceived
   reliability of those sources.  The order of precedence might be
   exposed as a configuration option.

>       redirection, rather than complicate the DNS protocol.

Thanks, I made the change in the GitHub repository (BTW I also resolved
Paul Wouters nit comments from earlier).

Best regards,

Matthijs

> -- Sam
> 
> 
> [1] Specifically, 5074 says to use public trust anchors first.  If they
> give a validation result other than "Secure", then do DLV processing. 
> I'm not 100% sure of how BIND's logic works here.
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Jul 2019 23:05:05 +1000

> On 25 Jul 2019, at 9:10 pm, Tony Finch <[email-masked]> wrote:
> 

You just slave the private DLV registry and load the trust anchors from that
after validating each DLV RRset.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]