4 ms·

Although querying the root servers directly is always unencrypted right? So your ISP can see and might manipulate all queries at will?

CaliforniaKarl 5y ago
In addition to the root hints, you should also download the DNSSEC anchor key (available on the same site as the root hints). That will let you detect manipulations of records that are DNSSEC-signed. Otherwise, you could spin up your recursive resolver on your cloud, VPS, or other hosting provider of choice, and then use that.
- Arnavion 5y ago
  Right, DNSSEC will solve the "manipulate" problem, but it won't solve the "see" problem. But whether that's a concern is up to you. You could run your resolver on a VPS and speak DoT / DoH to that, which shifts the leak from your ISP to your VPS provider.
  - tptacek 5y ago
    It doesn't solve the "manipulate" problem we're talking about here, either: nothing about DNSSEC prevents a DNS server (or middlebox) from denying results to a disfavored domain; it only (situationally) prevents them from redirecting it somewhere else. (And, of course, it only works if you're running your own recursive server; it does nothing whatsoever in the 8.8.8.8-type use case).
    - Arnavion 5y ago
      Yes, that's true.
    - progval 5y ago
      > nothing about DNSSEC prevents a DNS server (or middlebox) from denying results to a disfavored domain But at least it is detectable thanks to NSEC and NSEC3 records.
      - cyounkins 5y ago
        Kind of. An intermediary can drop packets and the client will never get the response.
      - tptacek 5y ago
        It's detectable when the site that the DNS provider is censoring falls off the Internet!
- teejmya 5y ago
  And make sure it only resolves records for you. Don't leave it wide open or it will be used as an attack vector. https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/ https://www.cloudflare.com/learning/ddos/dns-amplification-d...
0xbadcafebee 5y ago
In theory if you got a resolver which could disable UDP queries, it would then default to TCP, and the ISP couldn't manipulate those. Don't know if any resolver supports disabling UDP though.
- justsomehnguy 5y ago
  Unbound
- cyounkins 5y ago
  Unbound as a client will fall back to TCP automatically if the UDP response is too big. I'm uncertain if there is widespread support for TCP servers though.
- viraptor 5y ago
  > would then default to TCP, and the ISP couldn't manipulate those They can easily manipulate TCP as well. Unless you establish an authenticated session like TLS, TCP can be mitm-ed easily.
chrissnell 5y ago
The way I handle this is to run unbound on a server in the public cloud and then tunnel over TLS from my local unbound to the cloud instance. My local clients query a PiHole, which forwards to unbound on localhost:15353, which forwards everything over TLS to the fully recursive instance of unbound in the cloud, which uses root.hints.
- mekster 5y ago
  Still, your cloud vendor can see the requests. But someone can see it, but you can rotate upstream resolvers to split requests if you have to.
- AnonHP 5y ago
  How is the latency for such a setup? And how is the general browsing experience with said latency (I realize it also depends on which sites you frequently access)? I see some cloud providers/CDNs using a caching TTL as low as five minutes.
  - justsomehnguy 5y ago
    You spend most of the time waiting for the actual resolve to complete, not for the "transfer" time between you and VPS. Source: I'm running Unbound on my notebook, I'm actually queried the stats for some heated discussion on reddit. For example my current stats_noreset: histogram.000000.000512.to.000000.001024=17 histogram.000000.001024.to.000000.002048=33 histogram.000000.002048.to.000000.004096=251 histogram.000000.004096.to.000000.008192=509 histogram.000000.008192.to.000000.016384=1161 histogram.000000.016384.to.000000.032768=1891 histogram.000000.032768.to.000000.065536=2611 histogram.000000.065536.to.000000.131072=3197 histogram.000000.131072.to.000000.262144=2502 histogram.000000.262144.to.000000.524288=1547 histogram.000000.524288.to.000001.000000=857 histogram.000001.000000.to.000002.000000=121 histogram.000002.000000.to.000004.000000=70 histogram.000004.000000.to.000008.000000=22 histogram.000008.000000.to.000016.000000=441 histogram.000016.000000.to.000032.000000=80 As you can see most of queries are completed in a way below 500ms. Adding another 20-40ms on top that doesn't change anything, because caching is a thing and with Unbound you can even ask to actually refresh the expiring records, so you would be served a fresh one from the cache every time, though I never bothered with it, it works fine even without it.

CaliforniaKarl 5y ago

In addition to the root hints, you should also download the DNSSEC anchor key (available on the same site as the root hints). That will let you detect manipulations of records that are DNSSEC-signed. Otherwise, you could spin up your recursive resolver on your cloud, VPS, or other hosting provider of choice, and then use that.

Arnavion 5y ago
Right, DNSSEC will solve the "manipulate" problem, but it won't solve the "see" problem. But whether that's a concern is up to you. You could run your resolver on a VPS and speak DoT / DoH to that, which shifts the leak from your ISP to your VPS provider.
- tptacek 5y ago
  It doesn't solve the "manipulate" problem we're talking about here, either: nothing about DNSSEC prevents a DNS server (or middlebox) from denying results to a disfavored domain; it only (situationally) prevents them from redirecting it somewhere else. (And, of course, it only works if you're running your own recursive server; it does nothing whatsoever in the 8.8.8.8-type use case).
  - Arnavion 5y ago
    Yes, that's true.
  - progval 5y ago
    > nothing about DNSSEC prevents a DNS server (or middlebox) from denying results to a disfavored domain But at least it is detectable thanks to NSEC and NSEC3 records.
    - cyounkins 5y ago
      Kind of. An intermediary can drop packets and the client will never get the response.
    - tptacek 5y ago
      It's detectable when the site that the DNS provider is censoring falls off the Internet!
teejmya 5y ago
And make sure it only resolves records for you. Don't leave it wide open or it will be used as an attack vector. https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/ https://www.cloudflare.com/learning/ddos/dns-amplification-d...

0xbadcafebee 5y ago

In theory if you got a resolver which could disable UDP queries, it would then default to TCP, and the ISP couldn't manipulate those. Don't know if any resolver supports disabling UDP though.

justsomehnguy 5y ago
Unbound
cyounkins 5y ago
Unbound as a client will fall back to TCP automatically if the UDP response is too big. I'm uncertain if there is widespread support for TCP servers though.
viraptor 5y ago
> would then default to TCP, and the ISP couldn't manipulate those They can easily manipulate TCP as well. Unless you establish an authenticated session like TLS, TCP can be mitm-ed easily.

chrissnell 5y ago

The way I handle this is to run unbound on a server in the public cloud and then tunnel over TLS from my local unbound to the cloud instance. My local clients query a PiHole, which forwards to unbound on localhost:15353, which forwards everything over TLS to the fully recursive instance of unbound in the cloud, which uses root.hints.

mekster 5y ago
Still, your cloud vendor can see the requests. But someone can see it, but you can rotate upstream resolvers to split requests if you have to.
AnonHP 5y ago
How is the latency for such a setup? And how is the general browsing experience with said latency (I realize it also depends on which sites you frequently access)? I see some cloud providers/CDNs using a caching TTL as low as five minutes.
- justsomehnguy 5y ago
  You spend most of the time waiting for the actual resolve to complete, not for the "transfer" time between you and VPS. Source: I'm running Unbound on my notebook, I'm actually queried the stats for some heated discussion on reddit. For example my current stats_noreset: histogram.000000.000512.to.000000.001024=17 histogram.000000.001024.to.000000.002048=33 histogram.000000.002048.to.000000.004096=251 histogram.000000.004096.to.000000.008192=509 histogram.000000.008192.to.000000.016384=1161 histogram.000000.016384.to.000000.032768=1891 histogram.000000.032768.to.000000.065536=2611 histogram.000000.065536.to.000000.131072=3197 histogram.000000.131072.to.000000.262144=2502 histogram.000000.262144.to.000000.524288=1547 histogram.000000.524288.to.000001.000000=857 histogram.000001.000000.to.000002.000000=121 histogram.000002.000000.to.000004.000000=70 histogram.000004.000000.to.000008.000000=22 histogram.000008.000000.to.000016.000000=441 histogram.000016.000000.to.000032.000000=80 As you can see most of queries are completed in a way below 500ms. Adding another 20-40ms on top that doesn't change anything, because caching is a thing and with Unbound you can even ask to actually refresh the expiring records, so you would be served a fresh one from the cache every time, though I never bothered with it, it works fine even without it.