New on RIPE Labs: Making the DNS More Private with QNAME Minimisation
Dear colleagues, DNS queries can contain a lot of sensitive information about Internet users. Query name minimisation (qmin) limits the information revealed to what is actually necessary for a DNS name server to answer the query. Woute de Vries, Moritz Mueller and others did a study on qmin deployment and the associated challenges: https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-wi... Kind regards, Mirjam Kühne RIPE NCC
On 26 Apr 2019, at 10:02, Mirjam Kuehne wrote:
Woute de Vries, Moritz Mueller and others did a study on qmin deployment and the associated challenges:
https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-wi...
In which they mention:
You can test whether your resolver supports qmin by querying the domain below, using the command line tool dig, which relies on the same technique:
dig a.b.qnamemin-test.internet.nl TXT
I really appreciate it when people don't just do the study, but let others know how to confirm that their configuration looks "right" from the outside. Thanks to the authors! /Niall
dig a.b.qnamemin-test.internet.nl TXT
I really appreciate it when people don't just do the study, but let others know how to confirm that their configuration looks "right" from the outside.
very much agree. but i am confused. you can't put your foot in the same river twice. foo.you:/usr/home/randy> dig a.b.qnamemin-test.internet.nl TXT ; <<>> DiG 9.12.4 <<>> a.b.qnamemin-test.internet.nl TXT ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65229 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;a.b.qnamemin-test.internet.nl. IN TXT ;; ANSWER SECTION: a.b.qnamemin-test.internet.nl. 10 IN TXT "HOORAY - QNAME minimisation is enabled on your resolver :)!" ;; Query time: 606 msec ;; SERVER: 147.28.0.35#53(147.28.0.35) ;; WHEN: Sat Apr 27 16:58:51 UTC 2019 ;; MSG SIZE rcvd: 130 foo.you:/usr/home/randy> dig a.b.qnamemin-test.internet.nl TXT ; <<>> DiG 9.12.4 <<>> a.b.qnamemin-test.internet.nl TXT ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47763 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ba1915e9fa768885f59120285cc49437437b645f8ac77b10 (good) ;; QUESTION SECTION: ;a.b.qnamemin-test.internet.nl. IN TXT ;; ANSWER SECTION: a.b.qnamemin-test.internet.nl. 10 IN TXT "NO - QNAME minimisation is NOT enabled on your resolver :(" ;; Query time: 323 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Apr 27 17:41:11 UTC 2019 ;; MSG SIZE rcvd: 157 so, maybe if it is cached it is not working. local server is a bind 9.12.4 auth. recurses locally, but not globally. randy
On Sat, Apr 27, 2019 at 11:19:11AM -0700, Randy Bush wrote:
foo.you:/usr/home/randy> dig a.b.qnamemin-test.internet.nl TXT a.b.qnamemin-test.internet.nl. 10 IN TXT "HOORAY - QNAME minimisation is enabled on your resolver :)!" ;; SERVER: 147.28.0.35#53(147.28.0.35) ;; WHEN: Sat Apr 27 16:58:51 UTC 2019
foo.you:/usr/home/randy> dig a.b.qnamemin-test.internet.nl TXT a.b.qnamemin-test.internet.nl. 10 IN TXT "NO - QNAME minimisation is NOT enabled on your resolver :(" ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Apr 27 17:41:11 UTC 2019
so, maybe if it is cached it is not working.
local server is a bind 9.12.4 auth. recurses locally, but not globally.
Interesting, I'm not quite sure how this is happening, we've set the TTL very low (10) so there should be very little caching going on. How did the local server cache the answer from the first request if that went directly to the external recursor? (And why is the cached answer different?) Wouter
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 ...) Sorry, this test doesn't mean anything, since it can not distinguish the way the query comes in. BTW: It is not 'privacy' RFC 7816 is claiming; it is query obfuscation at the NS, not more. 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. Regards. --eh.
Am 27.04.2019 um 11:49 schrieb Niall O'Reilly <niall.oreilly@ucd.ie>:
On 26 Apr 2019, at 10:02, Mirjam Kuehne wrote:
Woute de Vries, Moritz Mueller and others did a study on qmin deployment and the associated challenges:
https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-wi...
In which they mention:
You can test whether your resolver supports qmin by querying the domain below, using the command line tool dig, which relies on the same technique:
dig a.b.qnamemin-test.internet.nl TXT
I really appreciate it when people don't just do the study, but let others know how to confirm that their configuration looks "right" from the outside.
Thanks to the authors!
/Niall
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE
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
participants (5)
-
Erwin Hoffmann -
Mirjam Kuehne -
Niall O'Reilly -
Randy Bush -
Wouter de Vries