News for hackers. Stuff that matters.

A comment on Comcast Is Lobbying Against DNS Encryption. Parent comment

Re:Comcast Is Lobbying Against DNS Encryption by nybble41 on Wednesday October 23, 2019 @03:29PM (#21337982)
DoH as implemented in Chrome still queries the servers configured in /etc/resolv.conf. It just uses the DoH protocol rather than plain DNS if it recognizes the server as supporting DoH (according to its built-in whitelist). Firefox is the one forcing all DNS resolution through Cloudflare's DoH servers by default.

Personally I'm mostly OK with the Chrome approach for public domains but I still worry about applications bypassing the host resolution plugins configured in /etc/nsswitch.conf. In my case that means: files (/etc/hosts), mymachines (automatic local VM name resolution), mdns (*.local), and myhostname. If an app only looks at /etc/resolv.conf and doesn't use the system resolver then it won't be able to see any of these local names. In the end, domain resolution is a system function and not something applications should be implementing on their own.

[ Parent | on HN ]
Re:Comcast Is Lobbying Against DNS Encryption by wahern on Wednesday October 23, 2019 @07:39PM (#21340190)
> In the end, domain resolution is a system function

Then just put 127.0.0.1 in /etc/resolv.conf. nsswitch, particularly for hostname resolution, is fundamentally broken as it doesn't work well with asynchronous software architecture; nor does it work well in languages that don't depend on libc.

Systemd already supports being a local resolver, but see OpenBSD's unwind (https://man.openbsd.org/unwind) for an attempt to seamlessly handle DNSSEC, DoT (and eventually DoH), local Wi-Fi portals, and other issues.

[ Parent | on HN ]
Re:Comcast Is Lobbying Against DNS Encryption by sliken on Wednesday October 23, 2019 @09:40PM (#21340880)
Unbound supports DoT as well.
[ Parent | on HN ]