Re: [DNSOP] New draft on delegation revalidation

Having read through the draft, and twice through the emails, I think the
draft has the right balance in using the parent and child NS RRsets
properly.

I think the "extra" query for the child NS, sent once per parent TTL, is a
savings over the older method of sending the NS records as "additional
data" in every response.

-- 
Bob Harold

On Fri, Apr 10, 2020 at 11:53 AM Tim Wicinski <tjw.ietf@gmail.com> wrote:

> (as a chair)
>
> I enjoyed reading the thread on dns-operations, and as a chair,
> both Benno and we like where this is going.
>
> (consider this a gentle nudge working group this is relevant to
> our interests)
>
> thanks Shumon/Ralph/Paul
>
> tim
>
>
>
>
> On Fri, Apr 10, 2020 at 9:46 AM Shumon Huque <shuque@gmail.com> wrote:
>
>> Hi folks,
>>
>> Paul Vixie, Ralph Dolmans, and I have submitted this I-D for
>> consideration:
>>
>>    https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01
>>
>> I mentioned it on the dns-operations@dns-oarc.net mailing
>> list last week, where the topic came up in another thread,
>> and there has already been some lively discussion about it
>> there. So we recommend reading the thread there:
>>
>>
>> https://lists.dns-oarc.net/pipermail/dns-operations/2020-April/020041.html
>>
>> There is a range of different behaviors in resolver implementations
>> in this respect today, and it would be good if we could agree on
>> more commonality.
>>
>> The main recommendations in the draft are to: (1) deterministically
>> prefer the authoritative child NS set over the non-authoritative,
>> unsigned, delegating NS set in the parent, (2) revalidate the parent
>> delegation at the expiration of the parent NS set TTL, to promptly
>> detect when the parent has re-delegated the zone elsewhere (or
>> removed the delegation).
>>
>> These are not new ideas of course. They have been proposed in Vixie
>> et. al.'s resimprove draft from 2010, and Wouter Wijngaard's resolver
>> mitigations draft from 2009. The Unbound resolver already mostly
>> implements this with the 'harden-referral-path' configuration option.
>>
>> Comments/discussion welcome.
>>
>> Shumon, Paul, and Ralph.
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>