[DNSOP] IETF 116 DNSOP WG agenda published

2023-03-16 Thread Benno Overeinder

All,

The DNSOP WG agenda for the IETF 116 was published yesterday, see 
https://datatracker.ietf.org/doc/agenda-116-dnsop/.


We have a full agenda of almost 2 hours:
- DNSOP WG chairs update and administrativia: 25 min
- Current DNSOP WG documents: 30 min
- drafts for consideration: 50 min
- time permitting: 10 min

We look forward to seeing you on site or remotely in the DNSOP WG!

Best regards,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Updated: Compact Denial of Existence

2023-03-16 Thread Peter Thomassen



On 3/15/23 13:48, Shumon Huque wrote:

So, if a resolver sends EDNS CompactAnswersOK signal to an authority server, 
which returns a NODATA+NXNAME proof + RCODE=3 response, then the resolver would 
have to intelligently manage that answer in its cache. To downstream DO=1 
queriers that also set CompactAnswersOK, it could return that answer as is. To 
those that don't, it would have to reset the RCODE to NOERROR.


If I understood that correctly, this is like option (a) from my earlier message 
(https://mailarchive.ietf.org/arch/msg/dnsop/PdK2ZTaTruQ-klI8ZH6C-ij0R6Y/), 
this time through an RCODE change done by the resolver.

Now this means that this draft would, I believe for the first time, specify 
that it's fine to withhold the NXDOMAIN signal from legacy clients that don't 
send the EDNS CompactAnswersOK signal.

If I didn't get something wrong and that is indeed the case, my view is that it 
should say so explicitly -- namely, (1) that it does not only introduce a way 
to return a smaller DoE to supporting clients, but it also introduces a change 
for legacy clients, (2) it requires resolver-side support.

(In my message linked above, I was talking about what the *auth* would send 
when receiving a query without the EDNS flag. Would it do the same as described 
above, like the resolver?)

Peter



This imposes more complexity on the resolver implementation of course, but I 
don't see any reason why it wouldn't work - and it would be optional anyway. 
Clients that want to see the NXDOMAIN signal in the RCODE might push their 
resolver service to implement it.

Shumon.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop