Murray Kucherawy has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-17: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
I’ve reviewed qdcount-is-one-02 and find it to be ready for publication as an
RFC.
DW
> On Mar 5, 2024, at 6:51 AM, Suzanne Woolf wrote:
>
> Hi,
>
> We're leaving this open a few more days to allow for any other comments. We'd
> like to submit it for publication before IETF 119.
>
>
>
Internet-Draft draft-ietf-dnsop-ns-revalidation-06.txt is now available. It is
a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: Delegation Revalidation by DNS Resolvers
Authors: Shumon Huque
Paul Vixie
Willem Toorop
Name:
Ray Bellis writes:
> I get the impression with DELEG on the horizon that there's a shift
> towards the parent side data being considered more "authoritative" even
> though in protocol terms it explicitly isn't.
Yes and no; there's a bit of nuance to ferret out here. This is part
of the
Willem Toorop writes:
> Should RFC 8767 stale data be ranked differently than fresh data?
> Should EDNS Client Subnet play into ranking?
>
> I like your thinking! Yes, fresh data should replace stale data in
> resolver caches
It's basically A- in your draft's hierarchy, I think, though
Shumon Huque writes:
> The draft allows (but does not proscribe) NXDOMAIN to be inserted
> into the Rcode for non DNSSEC enabled responses. I guess the main
> reason for not being proscriptive was what I mentioned - there were
> deployments in the field that didn't. But I'm amenable to tightening
On Sun, 17 Mar 2024, Shumon Huque wrote:
The draft allows (but does not proscribe) NXDOMAIN to be inserted into
the Rcode for non DNSSEC enabled responses. I guess the main reason
for not being proscriptive was what I mentioned - there were deployments
in the field that didn't. ...
You're
On Sun, Mar 17, 2024 at 9:08 AM John Levine wrote:
> It appears that Dave Lawrence said:
> >Stephane Bortzmeyer writes:
> >> > One current implementation does not differentiate DO=0 vs 1 and gives
> the
> >> > same NODATA answer for both cases.
> >>
> >> Yes. I see no practical problem with
It appears that Dave Lawrence said:
>Stephane Bortzmeyer writes:
>> > One current implementation does not differentiate DO=0 vs 1 and gives the
>> > same NODATA answer for both cases.
>>
>> Yes. I see no practical problem with that but, from a philosophical
>> point of view, it disturbs me.
