4 ms·
Let's say you look up "porn.example.com" and "dissidents.github.io". . (the ICANN DNS root) sees "io" and "com". com sees "example.com" but not which subdomai
by a1369209993 8y ago
Let's say you look up "porn.example.com" and "dissidents.github.io".
. (the ICANN DNS root) sees "io" and "com".
com sees "example.com" but not which subdomain or anything to do with io.
io sees "github.io" but not which subdomain or anything to do with com.
example.com sees "porn.example.com" but doesn't know anything about "dissidents.github.io".
github.io sees "dissidents.github.io" but doesn't know anything about "porn.example.com".
You leak the same total information, but no single entity has a convenient list of every DNS request you make.
- louiz 8y agoThat's wrong though, the ICANN sees the whole domain, dissidents.github.io and replies with "I don't know, but ask the owner of .IO which is xx.xx.xx.xx" Well, unless the servers implement https://tools.ietf.org/html/rfc7816 https://tools.ietf.org/html/rfc7816, which is experimental and quite recent. Unbound seems to support it, which is great (and that makes you right, actually, if the user installs this software). I don't know for others.
- a1369209993 8y agoActually, this appears to be implementation-specific? The resolver I looked at a while ago[0] did something like: @. io NS -> ns1.io # (for example[1]) @. ns1.io A -> x.x.x.x @x.x.x.x github.io NS -> ns1.github.io @x.x.x.x ns1.github.io A -> y.y.y.y @y.y.y.y dissidents.github.io A -> z.z.z.z return z.z.z.z caching every step of the way. Admittedly, I don't know that it wasn't going out of it's way to avoid leaking, but this was circa 2012 or so, so it predates rfc7816 at least. 0: found by googling "dns recursive resolver example code" or something to that effect 1: There's actually several NS entries, with retrying/failover.