Firefox DNS-over-HTTPS

Re:Firefox DNS-over-HTTPS by contingencies on Friday April 08, 2022 @04:34AM (#30954686)

I live in China and (still) use Firefox in preference to Google. I agree they need to fire the management and focus on the code. The big pain with DNS is that it's one avenue of censorship but also a proxy for many wrong-headed network geographic assumptions through the lens of geoDNS. "Oh, you resolved from Europe, so you really want a European server! Let me help you out there..." The internet has far too many of these half-baked hacks layered now, it's getting to the point where to obtain a halfway trustworthy response you have to have a dynamic network of geographically distributed and temporally transient nodes seeking similar information and voting on the result. Geoscoping, echo-chamber personalization, household profiling, jurisdiction-second-guessing, ID verification as an outsourced service, political policy fandangling, globe splitting for artificial market segregation, walled-gardening, DRM...

[ Parent | on HN ]

Re:Firefox DNS-over-HTTPS by yrro on Friday April 08, 2022 @07:35AM (#30955700)

What is a practical alternative to multiple DNS views based on the client's geographical location, for the problems solved by them?

A way to 'opt out' of response customization based on my location would be nice while troubleshooting. But then which zone is that going to give me? Probably the US one. :P

[ Parent | on HN ]

Re:Firefox DNS-over-HTTPS by contingencies on Friday April 08, 2022 @08:18AM (#30955979)

What is a practical alternative to multiple DNS views based on the client's geographical location, for the problems solved by them?

DNS was originally intended to be a domain name resolution service with fixed records. Yet, IIRC even in the very early days (1983) it allowed multiple records. So providing a list of potential endpoints to the client to empower them was fully supported since approximately day 1.

Apparently, instead of developing smart clients that use this (very efficiently provided) information to make reasonable actor-centric decisions, we have developed dumb clients and instead of selecting the best possible endpoint from a set it will just select either a random response or the first response most of the time. GeoDNS further degrades this already bad situation to purposefully provide limited, expiring and non-cacheable responses to individual clients thus locking in the failure.

There are application-level peer selection implementations for various protocols, for example gentoo had a mirrorselect tool which is awesome and torrents will generally prefer fast peers. It would not be that hard to make a smart resolver that did AS-level resolution and cached previously observed bandwidth to make intelligent prioritization decisions without the need to actually actively probe the network. This could even be done at the OS level, transparent to applications.

[RFC882] https://www.rfc-editor.org/rfc/rfc882.txt [RFC883] https://www.rfc-editor.org/rfc/rfc883.txt

[ Parent | on HN ]