81–90 of 215 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> This library wraps around the dnssd framework and the c-ares C library with Swift-friendly APIs and data structures. https://github.com/apple/swift-async-dns-resolver
It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.
https://developer.apple.com/documentation/network/nwendpoint...
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...
Earlier quoted context omitted.
Were the autofilled DNS servers in RFC1918 private space (10.0.0.0/8, 192.168.0.0/16, etc.)? I had issues after the upgrade with Google Chrome being unable to access hosts in these ranges, and fixed it by going to System Settings -> Privacy & Security -> Local Network and toggling Google Chrome off and on again.
No, they weren't local. I have no idea where they came from. I couldn't even delete them, but when I added the Google servers, they autofilled ones were automatically deleted.
My read of this is that it shouldn't affect pi.hole given the system's default nameserver would still received by DDNS and thus be the pi.hole? Or do these requests go somewhere that's hard-coded?
Earlier quoted context omitted.
Yeah, if it was intentional, it would probably be a hard-coded, encrypted URL. Some devices are starting to do that to get around ad blocking.
Good thing you can still see the domain over the network if you control the network.
Earlier quoted context omitted.
It feels like Embrace, Extend, Extinguish to claim that a portable API is "legacy" and that its replacement is Apple-only.
Well but the portable API is too low-level and error prone. What is the last time you used getaddrinfo? How often do you actually need to use it? One can make a good technical argument based on the merit of the portable API without immediately resorting to the EEE argument.