Re, > 1. le client JS fait sa requête DoH > 2. il voit 3 CNAMEs : srv[1,2,3].frnog.org > 3. il fait son LB façon RR-DNS et chosit srv2.frnog.org
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)... > 1. _chicken & egg _: comment s'assurer qu'on puisse bien charger le JS > initial alors que les noms de domaine utilisés peuvent ne pas > répondre par un mapping DNS classique (c'est bien le problème qu'on > cherche à résoudre) Le static est sur N x CDNs avec un RR DNS... aucun soucis. > 2. _same origin_ : ... Pas un soucis. > 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) Oui. > 4. _latence DNS_ : à benchmarker (DoH en JS à l'origine vs. DNS > classique via des resolvers qui cachent) > > Intéressé(s) à poursuivre l'étude ? Faudrait clairement faire un PoC... Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
