3 ms·

Personally I don't know why people aren't just using a local recursive DNS resolver rather than external services like this. I wonder when the root servers etc

by pabs3 3y ago

Personally I don't know why people aren't just using a local recursive DNS resolver rather than external services like this. I wonder when the root servers etc will start supporting DoH/DoT.

josephcsible 3y ago
Because your ISP will hijack the queries it makes.
- pabs3 3y ago
  Don't they only hijack the queries that you send to the ISPs DNS servers? Or do they MITM all DNS requests no matter the destination DNS server and hijack them? A local recursive resolver will generally not forward requests to the ISPs DNS servers.
  - josephcsible 3y ago
    They MITM all DNS requests no matter the destination DNS server and hijack them. (Clarification: every ISP can. Some, but not all, actually do so.)
    - guraf 3y ago
      > Some, but not all, actually do so Can you name one that does?
  - acdha 3y ago
    It’s on the honor system: if you’re worried about the problems encrypted DNS prevents, your ISP is the most likely threat. With traditional DNS, your ISP can monitor everything you query passively. They also see every host name you connect to using TLS with SNI. Since that’s passive, you don’t know who they share that with except to the extent that you trust your government’s privacy law’s & enforcement. They can also spoof DNS replies if they want to send you to a different server. This used to be common for Wi-Fi login systems when most of the web ran on HTTPS but TLS breaks it now. This is an active attack which is usually pretty blatant so you won’t see it commonly on residential ISPs. DNS over TLS/HTTPS breaks all of the passive DNS monitoring & active spoofing. It does not help with TLS SNI monitoring but there’s an Encrypted Client Hello extension being tested now for that.
    - guraf 3y ago
      I'm convinced that (American) ISPs do passively log unencrypted DNS requests, so replacing their DNS with things like quad9 and not using dot/doh is mostly pointless, but the question was: will the isp hijack the response? I've never heard of one doing that, you?
      - acdha 3y ago
        When in doubt, rely on Comcast for an example of bad behavior: https://arstechnica.com/tech-policy/2009/08/comcasts-dns-redirect-service-goes-nationwide/ https://arstechnica.com/tech-policy/2009/08/comcasts-dns-red...
    - briHass 3y ago
      At the ISP level, does it really matter that they can sniff my queries/SNI? They're just as capable of seeing the IP4/6 I'm connecting to and rDNSing that to know the hostname. SNI gets them past the multiple sites on a single IP, but even encrypted Hello might only hide your activities in the vanishingly rare instances where IPs are actually shared. The obvious analogy is sending postal mail to an address without the recipient's name: it's still pretty obvious who you're communicating with. Maybe I'm just bitter because I've found DoH (and even DoT) to be slow and occasionally unreliable. Even using Cloudflare, which is my fastest DNS, I see my local caches hitting strange resolve errors or in the minimum, durations 4-10x slower than good old UDP.
      - acdha 3y ago
        > At the ISP level, does it really matter that they can sniff my queries/SNI? They're just as capable of seeing the IP4/6 I'm connecting to and rDNSing that to know the hostname. Shared hosting breaks that. If I connect to an IP used by AWS, Akamai, Fastly, etc. there are literally millions of things I could be using but the SNI header will tell them which one. As a practical example, if a school administrator in Texas sees a connection to 104.16.12.208 they only know that someone is connecting to one of the millions of sites behind Cloudflare. SNI tells them it’s Planned Parenthood and they can call the police to report an offense against the church.
- topranks 3y ago
  That really depends. While that could very well be the case, I find it funny people tend to assume their ISP does this, and also assume that trusting large corporates (often outside the jurisdiction they are in and subject to foreign law enforcement requests) with their data is automatically preferable to their ISP. In the absence of widely-deployed ECH the ISP can potentially still see all hostnames visited from SNI field. Some fears you commonly hear about from US users, like ISPs selling user browsing data, is illegal in other territories like the EU. So this calculation is different in various contexts. Where ISPs are not able to monetize it you would wonder what the business case for the (very expensive) snooping of queries is.
0cf8612b2e1e 3y ago
I wanted to, but the classic villain, systemd, fights its damndest to retain control of local DNS resolution. If there was a bulletproof, straightforward way to run it, I am there (not Nix). I probably gave up too early, but my initial attempts with Unbound broke all internet access until I was able to reverse my configuration.
- pabs3 3y ago
  You can make /etc/resolv.conf immutable using chattr +i and then nothing can mess with your DNS. Of course if your apps aren't using /etc/resolv.conf and going direct to systemd-resolved then you'll have to deal with that instead of unbound/kresd/etc.
  - 0cf8612b2e1e 3y ago
    See, that feels like bandaging over the problem. A solution that is probably fine, until it is not.
- aesh2Xa1 3y ago
  Why not permit systemd-resolved to act as the local resolver along with resolved.conf? You can use Unbound listening on whatever is free on (ipv4)127.0.0.0/8 and (ipv6)[:1]:9953 (or any other free port), and configure resolved.conf to use that local address as the "upstream" DNS= option. You're probably going to still need Unbound to talk to an encrypted DNS server on the Internet (DoH or DoT), or else your ISP will be capable of intercepting and manipulating your queries. https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html https://www.freedesktop.org/software/systemd/man/systemd-res... https://www.freedesktop.org/software/systemd/man/resolved.conf.html https://www.freedesktop.org/software/systemd/man/resolved.co...
  - 0cf8612b2e1e 3y ago
    That feels like a brilliant strategy. Theoretically only ever requiring a one line configuration change if I ever need to reverse it. It would be a lot better if systemd would play nicely, but this is pretty minimal jank. Edit: and immediately ran into some trouble while trying to configure this. Definitely a situation where the documentation assumes you already know how DNS works
topranks 3y ago
Auth dns is a different beast. There are efforts in the IETF to work on it: https://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/ https://datatracker.ietf.org/doc/draft-ietf-dprive-unilatera...
topranks 3y ago
The average user is not capable of running that themselves. Your ISP can potentially see queries if you do this also, so if you don't trust your ISP, or worry about what they may be forced to do by your government, it may not suit. Further, DNS really benefits from caching as it scales up. As someone who runs my own resolver locally myself, I can attest to the sometimes long delay to resolve a hostname (requiring multiple external requests as the tree from root server is recursively queried). I still run my own recursive resolver, I find it the best option overall, so ultimately I agree with your statement. But like anything there are trade-offs.

by pabs3 3y ago

Personally I don't know why people aren't just using a local recursive DNS resolver rather than external services like this. I wonder when the root servers etc will start supporting DoH/DoT.

josephcsible 3y ago

Because your ISP will hijack the queries it makes.

pabs3 3y ago
Don't they only hijack the queries that you send to the ISPs DNS servers? Or do they MITM all DNS requests no matter the destination DNS server and hijack them? A local recursive resolver will generally not forward requests to the ISPs DNS servers.
- josephcsible 3y ago
  They MITM all DNS requests no matter the destination DNS server and hijack them. (Clarification: every ISP can. Some, but not all, actually do so.)
  - guraf 3y ago
    > Some, but not all, actually do so Can you name one that does?
- acdha 3y ago
  It’s on the honor system: if you’re worried about the problems encrypted DNS prevents, your ISP is the most likely threat. With traditional DNS, your ISP can monitor everything you query passively. They also see every host name you connect to using TLS with SNI. Since that’s passive, you don’t know who they share that with except to the extent that you trust your government’s privacy law’s & enforcement. They can also spoof DNS replies if they want to send you to a different server. This used to be common for Wi-Fi login systems when most of the web ran on HTTPS but TLS breaks it now. This is an active attack which is usually pretty blatant so you won’t see it commonly on residential ISPs. DNS over TLS/HTTPS breaks all of the passive DNS monitoring & active spoofing. It does not help with TLS SNI monitoring but there’s an Encrypted Client Hello extension being tested now for that.
  - guraf 3y ago
    I'm convinced that (American) ISPs do passively log unencrypted DNS requests, so replacing their DNS with things like quad9 and not using dot/doh is mostly pointless, but the question was: will the isp hijack the response? I've never heard of one doing that, you?
    - acdha 3y ago
      When in doubt, rely on Comcast for an example of bad behavior: https://arstechnica.com/tech-policy/2009/08/comcasts-dns-redirect-service-goes-nationwide/ https://arstechnica.com/tech-policy/2009/08/comcasts-dns-red...
  - briHass 3y ago
    At the ISP level, does it really matter that they can sniff my queries/SNI? They're just as capable of seeing the IP4/6 I'm connecting to and rDNSing that to know the hostname. SNI gets them past the multiple sites on a single IP, but even encrypted Hello might only hide your activities in the vanishingly rare instances where IPs are actually shared. The obvious analogy is sending postal mail to an address without the recipient's name: it's still pretty obvious who you're communicating with. Maybe I'm just bitter because I've found DoH (and even DoT) to be slow and occasionally unreliable. Even using Cloudflare, which is my fastest DNS, I see my local caches hitting strange resolve errors or in the minimum, durations 4-10x slower than good old UDP.
    - acdha 3y ago
      > At the ISP level, does it really matter that they can sniff my queries/SNI? They're just as capable of seeing the IP4/6 I'm connecting to and rDNSing that to know the hostname. Shared hosting breaks that. If I connect to an IP used by AWS, Akamai, Fastly, etc. there are literally millions of things I could be using but the SNI header will tell them which one. As a practical example, if a school administrator in Texas sees a connection to 104.16.12.208 they only know that someone is connecting to one of the millions of sites behind Cloudflare. SNI tells them it’s Planned Parenthood and they can call the police to report an offense against the church.
topranks 3y ago
That really depends. While that could very well be the case, I find it funny people tend to assume their ISP does this, and also assume that trusting large corporates (often outside the jurisdiction they are in and subject to foreign law enforcement requests) with their data is automatically preferable to their ISP. In the absence of widely-deployed ECH the ISP can potentially still see all hostnames visited from SNI field. Some fears you commonly hear about from US users, like ISPs selling user browsing data, is illegal in other territories like the EU. So this calculation is different in various contexts. Where ISPs are not able to monetize it you would wonder what the business case for the (very expensive) snooping of queries is.

0cf8612b2e1e 3y ago

I wanted to, but the classic villain, systemd, fights its damndest to retain control of local DNS resolution. If there was a bulletproof, straightforward way to run it, I am there (not Nix). I probably gave up too early, but my initial attempts with Unbound broke all internet access until I was able to reverse my configuration.

pabs3 3y ago
You can make /etc/resolv.conf immutable using chattr +i and then nothing can mess with your DNS. Of course if your apps aren't using /etc/resolv.conf and going direct to systemd-resolved then you'll have to deal with that instead of unbound/kresd/etc.
- 0cf8612b2e1e 3y ago
  See, that feels like bandaging over the problem. A solution that is probably fine, until it is not.
aesh2Xa1 3y ago
Why not permit systemd-resolved to act as the local resolver along with resolved.conf? You can use Unbound listening on whatever is free on (ipv4)127.0.0.0/8 and (ipv6)[:1]:9953 (or any other free port), and configure resolved.conf to use that local address as the "upstream" DNS= option. You're probably going to still need Unbound to talk to an encrypted DNS server on the Internet (DoH or DoT), or else your ISP will be capable of intercepting and manipulating your queries. https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html https://www.freedesktop.org/software/systemd/man/systemd-res... https://www.freedesktop.org/software/systemd/man/resolved.conf.html https://www.freedesktop.org/software/systemd/man/resolved.co...
- 0cf8612b2e1e 3y ago
  That feels like a brilliant strategy. Theoretically only ever requiring a one line configuration change if I ever need to reverse it. It would be a lot better if systemd would play nicely, but this is pretty minimal jank. Edit: and immediately ran into some trouble while trying to configure this. Definitely a situation where the documentation assumes you already know how DNS works

topranks 3y ago

Auth dns is a different beast. There are efforts in the IETF to work on it: https://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/ https://datatracker.ietf.org/doc/draft-ietf-dprive-unilatera...

topranks 3y ago

The average user is not capable of running that themselves. Your ISP can potentially see queries if you do this also, so if you don't trust your ISP, or worry about what they may be forced to do by your government, it may not suit. Further, DNS really benefits from caching as it scales up. As someone who runs my own resolver locally myself, I can attest to the sometimes long delay to resolve a hostname (requiring multiple external requests as the tree from root server is recursively queried). I still run my own recursive resolver, I find it the best option overall, so ultimately I agree with your statement. But like anything there are trade-offs.