This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[dns-wg] Draft of RIPE DNS Resolver Best Common Practices
- Next message (by thread): [dns-wg] Draft of RIPE DNS Resolver Best Common Practices
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Peter Thomassen
peter at desec.io
Fri Feb 2 17:20:54 CET 2024
Hi all, Thanks a lot for this draft. I know my response is kinda late, but I understand that this is still an active endeavor. In addition to the comments below, I'd like to raise the point of a "false-positive" rate for any kind of filtering. This is, in my view, a crucial aspect, and not currently considered sufficiently in the draft. The problem is that it's really difficult to come up with a good number for this, partly because it's not even clear what the denominator of the false positive rate should be! (Complaints? ... those may be orders of magnitude off the real number.) I have some more thoughts (but not solutions), but would first like to hear what others think / how other filter operators approach this. In any case, the policies published by a (filtering) resolver operator should say something on what is considered an acceptable rate of false positives. (FWIW, deSEC is a member of the DNS4EU consortium. We're trying to keep an eye on privacy and security matters.) On 11/26/23 18:01, Shane Kerr wrote: > In the future it will be possible to use ZONEMD to validate the copy > of the root zone obtained before using it. This is currently being > deployed for the root zone, but not yet available. > > [RFC8976](https://www.rfc-editor.org/rfc/rfc8976.html) describes ZONEMD. Small update: this is now in production, so this paragraph can be updated accordingly. https://lists.dns-oarc.net/pipermail/dns-operations/2023-December/022388.html > #### Logging considerations > > 1. Public privacy policy: DNS resolvers are recommended to publish > their privacy policies transparently on their website. It can be a > brief privacy commitment as well or be more elaborate on how the > privacy policy was made. (See for example > [Cloudflare's > statement](https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) > or [Quad9's privacy page](https://www.quad9.net/service/privacy/).) We should add here that such policies should explicitly mention the sampling rate of (anonymized) DNS queries/responses that are kept. Cloudflare does this (0.05%). I'm not sure about Quad9. > 5. Ad policy and encryption: explain the ad policy and how it can > potentially affect the users privacy. If data is encrypted, explain > how it has been encrypted (DoH, DoT, or so on). This is under "logging considerations". It's not clear to me at all why an "ad policy" appears here? Best, Peter -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525
- Next message (by thread): [dns-wg] Draft of RIPE DNS Resolver Best Common Practices
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]