Should we remove the DLV code?

[Hugo Salgado-Hernández]

Last year I was involved in a project to allow the signing of
domains in the second level of a country, when the TLD has
signed yet. It's a reality in certain regions. I get it
that the idea is to put pressure on the TLD, but this
institution was the largest ISP in the country and considered
that it was better pressure to begin to sign and validate.
The best technology was DLV. We started doing some prototypes,
but finally (and perhaps because of these conversations) the
TLD began its DNSSEC deployment. The project is sleeping,
waiting for the TLD finally signing, or to be reactivate if
time passes.

One important thing is that the "islands of security" concept
may be necessary in different places (companies? communities?)
and the DLV technique is not limited to the root. For the same
reason I consider that Bind's support is vital.

On the other hand, could improve things if it were a module that
must be activated in compilation, for example? That would reduce
the risks in default Bind. And the participants of an eventual
DLV would have to consciously compile and activate it. Maybe
is it a good compromise?

Finally, if the plan is to deprecate DLV as a technique,
perhaps a better way is to move 4431 to historical, and then
remove it from the code.

Hugo

On 14:36 21/05, Warren Kumari wrote:
> At this point I think DLV is actively dangerous -- I'm not sure if it
> "easy" to remove the code without too much risk, but an initial start
> would be to make it impossible^whard to enable it (and initially log
> an error message for people who already have it configured...).
> 
> W
> 
> On Tue, May 21, 2019 at 2:34 PM Matthijs Mekking <matthijs at isc.org> wrote:
> >
> > Hi Grant,
> >
> > On 5/20/19 11:44 PM, Grant Taylor via bind-users wrote:
> > > On 5/20/19 4:34 AM, Matthijs Mekking wrote:
> > >> * It will make the code much easier to maintain, which is beneficial
> > >> for users too since that will mean in general less bugs, easier to
> > >> find bugs, and easier to extend it with new features.
> > >
> > > Drive by 2¢ comment:
> > >
> > > Is the existing DLV code causing a problem or otherwise breaking something?
> >
> > Not actively, but in general it adds more corner cases, which make it
> > harder to investigate potential bugs in validation behavior.
> >
> > > How much easier will removing the DLV code make maintaining the rest of
> > > the code base?
> >
> > Hard to say, but quoting my colleague "about 50%".
> >
> >
> > > Is the existing DLV code preventing doing something else that is desired?
> >
> > Not preventing, but it is something that we need to take into account
> > every time we touch the validation code, and so there is a maintenance cost.
> >
> >
> > > IMHO if the code is sitting there and not actively causing problems,
> > > despite being unsightly, then I'd be inclined to leave it.  If it's
> > > anything more than unsightly, I'd pontificate removing it.
> >
> > Thanks for your input.
> >
> > Best regards,
> >
> > Matthijs
> >
> >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> > >
> > > bind-users mailing list
> > > bind-users at lists.isc.org
> > > https://lists.isc.org/mailman/listinfo/bind-users
> > >
> > _______________________________________________
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> 
> -- 
> 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
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190521/f9baf4ae/attachment.bin>