Hi Christina,
Thanks for the review and the suggestions. Please see my comments inline.
Yours,
Daniel
On Wed, Jun 14, 2023 at 11:56 AM Christian Huitema
wrote:
> I know that the feedback was due last Sunday, but here comes mine
> anyhow, after looking at the latest iteration of the draft.
>
>
Hi Florian,
Thanks for the feed back. One motivation for this document was to provide
guidance to deploy a DNSSEC resolver and implicitly encourage those not
doing it already. I think that your comment was very helpful as it clearly
indicated that we were achieving the opposite of what we were
Hi Andrew,
Thanks for the comment, the current document is much shorter than the
initial document. Regarding grammar, and linguistic issues - I am adding
explanations hard to follow - have been removed and largely rewritten from
scratch. I believe the current version addresses your concerns.
Hi Peter,
Thanks for the feedbacks. I agree that the idea of shortening the TTL based
on all TTLs of the chains may be too intrusive and not respect the
willingness of the authoritative server - which also needs to be taken into
account. One other reason we removed such recommendation was also
On 6/15/23 15:32, Viktor Dukhovni wrote:
I agree that client-side validation would be ideal. One important
aspect here is to save on the latency caused by extra queries; my
impression is that this extra cost is generally considered
prohibitive.
Not sure what you mean by "generally" (is that
On Wed, Jun 14, 2023 at 12:09:23PM -0400, Peter Thomassen wrote:
> > But the focus changes. For example, if we consider that "spoofing by
> > recursive server" is a threat, then having the recursive set bits to
> > affirm that the response is verified is not much of a protection --
> > the
same here, I'm late, but I support this draft and will review and contribute.
CLASSIFICATION:CONFIDENTIAL
From: DNSOP on behalf of Christian Huitema
Sent: Wednesday, June 14, 2023 11:55 AM
To: Florian Obser ; Tim Wicinski
Cc: dnsop ; dnsop-chairs
Subject:
