On 05/03/2020 21:54, Philippe Bourcier wrote:
Ca n'aurait pratiquement aucun intérêt... puisque c'est déjà ce que ferait un
OS/browser.
Je ferais plutôt :
1. le client JS fait sa requête DoH
2. il voit N CNAMEs : srv[1,2,3...].frnog.org
3. il lance 2 threads de connexion (get d'une page de status) vers 2 des N
serveurs
4. il choisit celui qui répond "tout va bien" (ce qui permet de désactiver un
node (ie: lors d'une mise en prod)) et qui a la meilleure latence... Le tout est contenu
avec un timeout de 150ms... si aucun des 2 n'est OK, on passe au(x) node(s) suivant(s)...
5. il lance la/les requêtes API vers cet élu... si failure, re-bascule sur un
des autres (avec un sleep++ plus on retry, passé les N serveurs du pool)...
Oui c'est ce que je pensais.
3. _caches DNS_ : on en revient au cas DNS classique et au problème du
TTL mini effectif de 20 minutes. En DoH on a le contrôle sur le
serveur qu'on interroge et on peut remonter directement à l'origine
(SOA) et court-circuiter les caches (ce qui revient à ignorer le TTL)
On ignore pas le TTL on aura le vrai TTL. On pallie des comportements de
certains ISP peu scrupuleux. Btw DoH sera bientôt utilisé par défaut
dans pas mal de browser ce qui nous facilitera la tache. Je pense même
que les gros vont finir pas imposer des serveurs DoH par défaut
overridant ceux du système.
4. _latence DNS_ : à benchmarker (DoH en JS à l'origine vs. DNS
classique via des resolvers qui cachent)
Oui c'est un des gros points à vérifier. La latence initiale risque de
ne pas être fameuse.
A voir si c'est acceptable. Pour une grosse SPA je pense que ça passe.
Faudrait clairement faire un PoC...
I'm in.
--
Raphael Mazelier
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
