Live data from Hacker News

Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

obdev.at

61–70 of 215 posts

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#62
post #47

Earlier quoted context omitted.

Those ideas are not isomorphic. One malicious overrides universal network communication while the other just conducts DNS queries limited to a single application domain.

>just conducts DNS queries Queries that will ignore configurations you set. If I see something ignoring/evading my configured DNS server, that shit is fucking malware.

At some point in my copious spare time, I plan on writing software to allowlist in my firewall outbound connections only to IPs resolved using my DNS servers.

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#63
I use routedns [0] as my local stub resolver so that I can pick and choose which requests go to where and also what transport they use. It can also blocklist, re-write, cache, load balance, and/or handle fall back requests; so it give you lots of control.

I use a stub listener on localhost:53 for local requests and then forward them via UDP QUIC (TLS 0-RTT) requests to Cloudflare (1.1.1.1) with caching for most requests. Fast and reasonably secure.

[0] https://github.com/folbricht/routedns

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#65
post #47

Earlier quoted context omitted.

Those ideas are not isomorphic. One malicious overrides universal network communication while the other just conducts DNS queries limited to a single application domain.

>just conducts DNS queries Queries that will ignore configurations you set. If I see something ignoring/evading my configured DNS server, that shit is fucking malware.

Have fun troubleshooting Java apps w/their own cert stores...

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#66
post #21

Earlier quoted context omitted.

Yep, I wish they would go the full way and block socket access entirely so your own outgoing traffic is always introspectable even with cert pinning. It would make it blatantly obvious when apps try shady shit.

Shady shit? Not every network request is a call to an HTTP REST API. Blocking socket APIs would break every app that supports other protocols. Goodbye file transfer apps, VPN apps, file sync apps, database tools, SSH clients, remote desktop clients, audio and video conferencing apps, etc.

Shady shit meaning really obvious when you're making http calls with encrypted opaque blobs.

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#67

Sequoia also breaks an application's ability to use DNS (or presumably anything UDP-based) if the macOS firewall is enabled, and an app is listed as "Block incoming connections". https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...

I can't reproduce this. Some people say it has to do with ESET: https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#68
post #23

Earlier quoted context omitted.

Honestly, I'm fine with that. Applications themselves should not be resolving DNS outside of what I set in settings. The reasons applications do this is to prevent users from blocking telemetry etc. It's my computer, I should have final say on what goes out.

There is no such thing as a remotely cross-platform DNS resolution API that has the system do the lookup and does not utterly suck for asynchronous use.

I suspect "cross-platform" is doing a lot of heavy lifting for your claim. Browser engines and application frameworks built on top of them have no trouble using platform-specific APIs under the hood.

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#69
post #50

Earlier quoted context omitted.

Yes, this! I even wonder how else you would do this. By the way I worked with many IoT devices that do not use your dhcp dns but just hardcode quad 8 or similar

We recently had a developer join our team and he got stuck setting up his dev environment. We use a .dev domain as a localhost alias, and turns out his ISP’s DNS wouldn’t resolve 127.0.0.1 (or whatever it is) for the .dev domain. Changing his resolver at the network level to 1.1.1.1 fixed it. I imagine there are lots of difficult support tickets for app devs, and at a certain point they just hardcode the DNS to remov…

Not resolving 127.0.0.1 or RFC1918 addresses or even ULA for IPv6 is done to avoid DNS rebinding attacks. For most end users that is probably the correct move.
Post reply on HN