[dnssec-deployment] meeting announcement: 18 June 2008

[Paul Vixie]

> I'm not against DLV, even though I see it as a "hack".

i am not for DLV, i know it's a hack, i just want dnssec to be deployed.

> I've suggested a DLV for TLD's, but that DLV should be run in contract with
> the TLD's and by a body that could not be questioned. RIPE or IANA could be
> the operator of such a DLV.

if such an operator steps forward, they will have ISC's full support, so long
as they are a nonprofit public benefit entity like ISC itself, or RIPE or
IANA.  (note that i'm unclear as to how RIPE's credentials and qualifications
differ from ISC's in regards to operating a DLV registry, but no matter.)

> A DLV for .COM domain names must be run by the .COM Registry, or we would
> never trust it. If Verisign sets a DLV up for .COM, we will take a look at
> it and asked them if they will be RFC 5011 compliant. If someone else runs a
> DLV for .COM they will never be able to keep the holder of the DNSsec key
> synchronized with the holder of the domain name. And we will never add that
> to our resolvers.

i understand your position.  roy arends of nominet has a proposed design for
DLV that would work the way you want.  you should offer him beer in exchange
for writing it up.  DLV as currently implemented in BIND9 does not make it
possible for every TLD to run their own DLV, and while the specification
allows this, it would be an extremely high-maintainance operation for all
validator operators.  as for synchronizing the keyholder and domainholder,
ISC has a mechanism for this and i am confident enough that i trust our DLV.

> When .COM is signed, when root is signed, we will still need some means
> of keeping the trust anchors synchronized with the KSK's, and that is
> where RFC 5011 comes in. We will need RFC 5011 for ever, DLV could help
> us for a short while.

DLV is only meant to help us for a short while.