I recall that the key objection there was related to displaying HTML controlled by the DNS server. Limiting the responses to plain text, as proposed here, makes it significantly less scary.
--Ben ________________________________ From: Ralf Weber <d...@fl1ger.de> Sent: Monday, November 11, 2024 9:25 PM To: Ben Schwartz <bem...@meta.com> Cc: Ben Schwartz <bemasc=40meta....@dmarc.ietf.org>; Stephane Bortzmeyer <bortzmeyer=40nic...@dmarc.ietf.org>; Mark Nottingham <mnot=40mnot....@dmarc.ietf.org>; dnsop@ietf.org <dnsop@ietf.org> Subject: Re: [DNSOP] New Version Notification for draft-nottingham-public-resolver-errors-00.txt Moin! On 8 Nov 2024, at 6:07, Ben Schwartz wrote: > 1. Prevent DDoS attacks. A malicious DNS server could cause a large number > of clients to fetch incident reports from an arbitrary victim server. (c.f. > Great Cannon [A]) As the initial structured error draft requires encrypted DNS this is not possible, or I am failing to see how that would work. > 2. Block reports that transited a naive forwarder. These reports could be > inauthentic, if the forwarder's upstream transport is unencrypted. EDNS0 is hop by hop so the forwarder would per default not copy it anyway. > We could probably develop some technical mechanism that prevents both of > these attacks without the same-domain requirement. However, that may not be > necessary. As Emily points out, clients (i.e. browsers) might have their own > reputation systems for determining which reports can safely be displayed to > the user. > > When the client applies its own reputation system, the same-domain > requirement and central registry are both unnecessary. I’m having a deja vu here. Earlier versions had an URL as notification target in there and clients could have done their own reputation systems with this, but we were told that there was no way clients would be getting data from a URL in a DNS packet. This draft puts an intermediate layer on it with the registry, which IMHO fixes this and removes the same domain requirement. So long -Ralf ——- Ralf Weber
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
