Hello everyone, Speking as the author of RFC 7830 – there was some discussion whether the document should say “SHOULD NOT” or “MUST NOT” when padding DNS packets over unencrypted packets. We couldn’t come up with any other use case (maybe except testing of the feature over unencrypted transport), so the consensus of the group was that we should be strict, especially as padding might be an easy way to bloat packets. I do agree that this connects DNS answer behaviour with transport choice – hence creates a dependency that’s probably not very wise in a protocol that has already pretty complex dependencies.
If the community believes that this requirement should be relaxed (and it’s worth the effort), I’m up for creating a revision of RFC 7830. This might also be a chance to step up EDNS Padding to Internet Standard – I think it’s widely deployed on billions of devices (Android..). Thoughts? Best, Alex Von: dns-privacy <dns-privacy-boun...@ietf.org> Im Auftrag von Vladimír Cunát Gesendet: Freitag, 9. September 2022 18:11 An: Ben Schwartz <bem...@google.com> Cc: c...@ietf.org; DNS Privacy Working Group <dns-priv...@ietf.org>; dnsop <dnsop@ietf.org>; Jaime Jiménez <ja...@iki.fi> Betreff: Re: [dns-privacy] [DNSOP] [core] WGA call for draft-lenders-dns-over-coap On 06/09/2022 17.06, Ben Schwartz wrote: The choice of transport is independent of the DNS server's answering behavior, which must not be modified by the transport. Nit: there's a very specific counter-example of EDNS padding which is meant to be added depending on transport encryption. https://www.rfc-editor.org/rfc/rfc7830#section-6 There might be some others (in future, too), as encryption does change some considerations, but yes - not basic stuff like following CNAMEs. --Vladimir | knot-resolver.cz
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
