3 ms·

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 respo

by yrro 5y ago

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

contingencies 5y ago
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 https://www.rfc-editor.org/rfc/rfc882.txt [RFC883] https://www.rfc-editor.org/rfc/rfc883.txt https://www.rfc-editor.org/rfc/rfc883.txt

by yrro 5y ago

contingencies 5y ago

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 https://www.rfc-editor.org/rfc/rfc882.txt [RFC883] https://www.rfc-editor.org/rfc/rfc883.txt https://www.rfc-editor.org/rfc/rfc883.txt