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] New on RIPE Labs: Making the DNS More Private with QNAME Minimisation
- Previous message (by thread): [dns-wg] New on RIPE Labs: Making the DNS More Private with QNAME Minimisation
- Next message (by thread): [dns-wg] New on RIPE Labs: Making the DNS More Private with QNAME Minimisation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wouter de Vries
w.b.devries at utwente.nl
Mon Apr 29 09:10:46 CEST 2019
On Sat, Apr 27, 2019 at 10:25:02PM +0200, Erwin Hoffmann wrote: > Hi Niall & Randy, > > I'm using my version of DJB's dnscache [https://www.fehcom.de/ipnet/djbdnscurve6.html]: > > The test claims false results given a 'warm' cache. > > ./dnstext a.b.qnamemin-test.internet.nl > NO - QNAME minimisation is NOT enabled on your resolver :( > > I just used the 100k DNS data sets provided here recently to feed my cache ;-) > > Query/response path: > > myip -> 185.49.140.60 TXT a.b.qnamemin-test.internet.nl > 185.49.140.60 -> myip TXT a.b.qnamemin-test.internet.nl NS ns.qnamemin.test.internet.nl (glue) A 185.49.141.12 AAA 2a04:b900:0:100::8:28 > myip -> 185.49.141.12 TXT a.b.qnamemin-test.internet.nl > 185.49.141.12 -> myip TXT a.b.qnamemin-test.internet.nl (text ...) In the case your resolver was doing qmin, the third line should have read something like: myip -> 185.49.141.12 TXT b.qnamemin-test.internet.nl (omitting the last label: a). This would have triggered a second delegation: 185.49.141.12 -> myip NS ns.b.qnamemin-test.internet.nl (glue) A 185.49.141.13 AAAA 2a04:b900:0:100::9:28 Where the proper response is waiting: myip -> 185.49.141.12 TXT a.b.qnamemin-test.internet.nl 185.49.141.12 -> myip TXT a.b.qnamemin-test.internet.nl (hooray qnamemin is enabled etc) Does that makes sense to you? > > BTW: It is not 'privacy' RFC 7816 is claiming; it is query obfuscation at the NS, not more. I'm not sure what you mean by this. Obfuscation, to me, implies that the actual query name can somehow still be recovered at the authoritative (e.g. the root or the tld NS), this is not the case. RFC7816 explicitly claims to improve privacy, the title of the RFC reads: "DNS Query Name Minimisation to Improve Privacy". > > Remark: QnameMin only helps in case many labels are encountered; this is not common in today's internet any more. Just to get rid for the first label ist not worth to include more complexity in the code; IMHO. Even in the most basic case, e.g. google.com, we can already omit the "google" label when sending the query to the root. Sure, looking up google.com is not that privacy sensitive, but I see no reason why there could not be privacy sensitive information on that level. Wouter
- Previous message (by thread): [dns-wg] New on RIPE Labs: Making the DNS More Private with QNAME Minimisation
- Next message (by thread): [dns-wg] New on RIPE Labs: Making the DNS More Private with QNAME Minimisation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]