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

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Aug 2021 17:55:18 +0000

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.

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.

--Paul Hoffman

---

From: Shumon Huque <[email-masked]>
Date: Tue, 10 Aug 2021 15:47:30 -0400

On Tue, Aug 10, 2021 at 1:55 PM Paul Hoffman <[email-masked]> 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?

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.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 11 Aug 2021 14:17:57 -0400

On Tue, Aug 10, 2021 at 3:48 PM Shumon Huque <[email-masked]> 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 ..
>
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

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Raffaele Sommese <[email-masked]>
Date: Wed, 11 Aug 2021 20:47:41 +0100

My 2 cents as co-author of [1,2]:
We find more or less similar percentages of parent-child glue
inconsistencies (5-12% of SLDs,  Table 12) compared to NS inconsistencies.
Therefore, I think that glue revalidation should be included in the process.
Best,
Raffaele

[1]
https://www.caida.org/catalog/papers/2020_unresolved_issues/unresolved_issues.pdf
[2]
https://www.caida.org/catalog/papers/2020_when_parents_children_disagree/when_parents_children_disagree.pdf