Re: [DNSOP] Possible greater value for draft-ietf-dnsop-ns-revalidation

On Tue, Aug 10, 2021 at 3:48 PM Shumon Huque <shuque@gmail.com> wrote:

> On Tue, Aug 10, 2021 at 1:55 PM Paul Hoffman <paul.hoffman@icann.org>
> wrote:
>
>> Greetings again. In the DPRIVE WG, we are discussing a proposal that
>> would make encrypting transport on a first lookup more likely using a DS
>> hack. Whether or not that becomes a WG item in DPRIVE, it reminded me that
>> DNSOP had not finished with draft-ietf-dnsop-ns-revalidation, and that this
>> draft could be expanded beyond revalidating just NS RRsets to revalidating
>> all glue.
>>
>
> Paul,
>
> I think that's a reasonable thing to consider (and I suspect some
> resolvers may already revalidate glue), as long as it's done lazily (or in
> parallel) and doesn't interpose additional delay in following a referral.
> I'll await other comments ..
>
> But I'm trying to better understand the connection to the DS hack draft
> (I've not followed it very closely, I'll admit). Does it require or benefit
> from glue revalidation? Isn't the child zone owner explicitly putting its
> NS name and addresses into the hacked DS record at the parent?
>
>
Technically, Paul is referring to _a_ DS proposal, where there are going to
be at least _two_ such proposals (mine being the other one).
I plan on bringing mine to the DNSOP WG rather than DPRIVE, as I believe it
will have more utility than strictly DPRIVE use cases.

Having said that, both proposals share one feature, which is the child
including the NS set in a new DS record (new algorithm consisting only of a
hash of data including NS) on the parental side of the delegation.

As such, it definitely will be the case that glue revalidation has benefits.

FYI: My proposal, which uses different methods compared to the one Paul
references, does not place anything other than NS references in any DS
records for the child zone. Rather, it places glue data in additional DS
record(s) (different new algorithm(s)), at the corresponding owner names
(name server zone, in name server zone's appropriate TLD(s)). In cases
where the name server zone itself is glue-less (served by a separate zone),
the glue data would be placed in records at that zone's owner name.

Brian

> Given the results of the survey and the possible cross-WG interest, I'd
>> like to see draft-ietf-dnsop-ns-revalidation moved forward in DNSOP sooner
>> rather than later.
>>
>
> I'm working on the remaining loose ends and plan to push another update
> soon.
>
> Shumon.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>