Re: Should we remove the DLV code?

[@lbutlr]

On 22 May 2019, at 23:31, Evan Hunt  wrote:
> One possible reason is distribution of trust anchors for a private corporate 
> domain. 

Aren't there better days to do this?

Or at least other ways to do this?

Anything to make bind leaner and meaner and with fewer LOCs seems like a plus 
to me.

-- 
-=>



<=-


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Should we remove the DLV code?

[Evan Hunt]

On Wed, May 22, 2019 at 12:41:05PM +0100, Jim Reid wrote:
> ISC said DLV would go away once the root got signed. It's long outlived
> its usefulness (DLV that is, not ISC). The root first got signed ~10
> years ago. That's more than enough time to make other arrangements and
> have an orderly withdrawal from DLV.

The ISC DLV service *has* gone away; dlv.isc.org is an empty zone.

The lookaside validation code in BIND can still be used with a different
lookaside zone, though, if someone wanted to for some reason.  One
possible reason is distribution of trust anchors for a private corporate
domain.  AIUI, there are some people doing that; I don't know how many.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Should we remove the DLV code?

[Tony Finch]

Matthijs Mekking  wrote:
>
> The BIND 9 development team has been discussing whether we should remove
> the DLV code from the BIND 9 source.

DLV as it currently works is not useful and it's a lot of complexity to
carry around. However, with some tweaks it might be made useful. On the
gripping hand the cost/benefit tradeoff probably does not justify working
on it :-)

The scenario is trust anchor distribution inside an enterprise. There are
a few cases where you might want resolvers to be able to validate local
zones without talking to the internet:

* Business continuity in case of loss of external connectivity. Validation
requires chasing the chain of trust from the root; if we only have to
chanse down from the corporate domains then internal things still work
when the backhoes do their thing.

* RFC 1918 reverse DNS.

* Private views with distinct keying.

DLV is almost but not quite ideal for distributing trust anchors for
internal zones, because it insulates validators from the details of most
config changes. (A nice counterpart to catalog zones.) The DNS admin only
needs to do RFC 5011 for the DLV zone and almost everything else takes
care of itself.

DLV does not work for this purpose because it is a fallback, whereas what
I want is a source of trust anchors that takes higher priority than the
public DNS.

There are a few reasons why it probably is not worth the effort to adapt
DLV in the way I suggest:

* Shoudn't we work more on making your network more reliable instead of
making the DNS more complicated? (Yes, we have, so in practice this isn't
a big problem that needs solving.)

* Who cares about DNSSEC validation for RFC 1918 reverse DNS?

* There are other ways to allow for private views with different keys from
public views (more DS records!), so we don't need a second way to solve
this problem.

Also my point of view is warped by working for a university where central
IT acts a lot more like an ISP than corporate IT, so we don't have control
over most system configurations.

So that's my brain dump, take it or leave it, and I will still be happy if
you go ahead and delete DLV.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Cape Wrath to Rattray Head including Orkney: West or northwest 5 or 6. Slight
or moderate, becoming rough in northwest. Rain or showers. Moderate or good,
occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Should we remove the DLV code?

[Jim Reid]

> On 21 May 2019, at 16:00, Hugo Salgado-Hernández  wrote:
> 
> 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.

This is unfortunate. And mistaken. Making a critical dependency on what was 
designed as a short-term ugly kludge was a bad idea. More so when it was known 
from the outset (or should have been known) that this kludge would one day go 
away.

ISC said DLV would go away once the root got signed. It's long outlived its 
usefulness (DLV that is, not ISC). The root first got signed ~10 years ago. 
That's more than enough time to make other arrangements and have an orderly 
withdrawal from DLV.

DLV must die. Two shots to the head, just to be sure.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 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  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@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@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


signature.asc
Description: PGP signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Should we remove the DLV code?

[Warren Kumari]

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  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@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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Should we remove the DLV code?

[Matthijs Mekking]

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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Should we remove the DLV code?

[Grant Taylor via bind-users]

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?

How much easier will removing the DLV code make maintaining the rest of 
the code base?


Is the existing DLV code preventing doing something else that is desired?

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.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Should we remove the DLV code?

[Matthijs Mekking]

Dear BIND 9 users,

The BIND 9 development team has been discussing whether we should remove 
the DLV code from the BIND 9 source. Reasons for doing this:


* The zone dlv.isc.org has been decommissioned some time ago.
* 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.


Before rigorously start chopping, we would like to know if there are 
still users using it, and if so for what, or if you have other reasons 
to believe this code should stay, please speak up, on the list or 
personally to me.


Thank you,

Matthijs
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users