4 ms·

If you were to run your own recursive DNS resolver, you'd probably do 3-10x more DNS traffic than you did before, due to the number of requests increasing from

If you were to run your own recursive DNS resolver, you'd probably do 3-10x more DNS traffic than you did before, due to the number of requests increasing from 1 to multiple. That said, each DNS request & response is usually under 1KB, so the background traffic doesn't really stop being negligible. Don't run your resolver open to the wider internet, however. Only accept recursive requests from your local network segment, or you'll unwittingly become part of DNS amplification attacks.

DoctorOetker 8y ago
oh, I thought a DNS server meant I would be storing my own copy of table of URL's to IP adresses? So the privacy enhancement is tracking by the DNS server? but if my local DNS server forwards these requests, how exactly does it improve my privacy if it does not store a bulk "DNS table" in my amateur speak?
- antonvs 8y ago
  DNS servers deal with domain names, not URLs. For an HTTPS request, the rest of the URL (path etc.) is only ever sent to the target site, over an encrypted connection. From an information privacy perspective, DNS is a weak link in this mechanism. The reason running your own DNS improves your privacy has to do with how centralized or decentralized your DNS traffic is, and who gets to see it as a result. If you use a DNS controlled by someone else, the DNS operator can see, and therefore (in principle) track, all of the domain name lookups you make that aren't served by your local machine or router's cache. In contrast, if you run your own DNS server that's not just a slave to e.g. an ISP's server, then external domain lookups are made directly against the authoritative DNS servers for the domain you're looking up. There's no longer a single central server, other than your own, that's seeing all your lookups. So if you look up news.ycombinator.com, and the name isn't already in your cache, the request goes direct from your DNS server to an AWS DNS server, because that's who hosts the ycombinator.com DNS. Your non-cached DNS requests are thus spread out across all the DNS servers for all the different domains you're accessing, and the only DNS servers that see your requests are the servers for the domain you're accessing. There are some caveats to this. First, if your ISP is unscrupulous, it can examine your DNS traffic anyway, since most DNS traffic is currently unencrypted (this is changing, but slowly.) To get around that you'd need an encrypted DNS proxy hosted outside your provider's network. Second, large DNS providers like Verisign, GoDaddy, AWS etc. will tend to get a large subset of your requests anyway. However, most of those big companies are publicly focused on information security, and it would be big news if it turned out they were tracking your DNS lookups. Some of them provide audited guarantees that they don't do this.
- 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 ago
    That'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 ago
      Actually, 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.

DoctorOetker 8y ago

oh, I thought a DNS server meant I would be storing my own copy of table of URL's to IP adresses? So the privacy enhancement is tracking by the DNS server? but if my local DNS server forwards these requests, how exactly does it improve my privacy if it does not store a bulk "DNS table" in my amateur speak?

antonvs 8y ago
DNS servers deal with domain names, not URLs. For an HTTPS request, the rest of the URL (path etc.) is only ever sent to the target site, over an encrypted connection. From an information privacy perspective, DNS is a weak link in this mechanism. The reason running your own DNS improves your privacy has to do with how centralized or decentralized your DNS traffic is, and who gets to see it as a result. If you use a DNS controlled by someone else, the DNS operator can see, and therefore (in principle) track, all of the domain name lookups you make that aren't served by your local machine or router's cache. In contrast, if you run your own DNS server that's not just a slave to e.g. an ISP's server, then external domain lookups are made directly against the authoritative DNS servers for the domain you're looking up. There's no longer a single central server, other than your own, that's seeing all your lookups. So if you look up news.ycombinator.com, and the name isn't already in your cache, the request goes direct from your DNS server to an AWS DNS server, because that's who hosts the ycombinator.com DNS. Your non-cached DNS requests are thus spread out across all the DNS servers for all the different domains you're accessing, and the only DNS servers that see your requests are the servers for the domain you're accessing. There are some caveats to this. First, if your ISP is unscrupulous, it can examine your DNS traffic anyway, since most DNS traffic is currently unencrypted (this is changing, but slowly.) To get around that you'd need an encrypted DNS proxy hosted outside your provider's network. Second, large DNS providers like Verisign, GoDaddy, AWS etc. will tend to get a large subset of your requests anyway. However, most of those big companies are publicly focused on information security, and it would be big news if it turned out they were tracking your DNS lookups. Some of them provide audited guarantees that they don't do this.
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 ago
  That'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 ago
    Actually, 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.