La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Navigateurs web => Discussion démarrée par: vivien le 03 mars 2015 à 16:56:21
-
Pourquoi Firefox 36 fait une requête DNS de type "ANY" ?
J'ai fait un simple téléchargement après avoir vidé mon cache : https://lafibre.info/images/logo/lafibre.png
J'observe qu’après la requête DNS de type "A" pour récupérer l'IPv4, Firefox 36 démarre la connexion avec le serveur [SYN]" puis fait une requête DNS de type "ANY" pour récupérer toutes les informations DNS.
Je ne comprends pas l'objectif de cette requête.
Si elle est nécessaire, pourquoi ne pas faire uniquement une requête "ANY", vu
que cela permet d'avoir également l'IPv4 ?
La capture qui s'ouvre directement avec un Wireshark récent : 201503_win7_firefox36_https_download.pcapng.gz (https://lafibre.info/testdebit/windows7/201503_win7_firefox36_https_download.pcapng.gz)
(https://lafibre.info/testdebit/windows7/201503_win7_firefox36_https_download.png)
Environnement :
- Hardware : Dell Inspiron 660, 8Go DDR3 et Core i3-2120 @3,3 Ghz
- OS : Windows 7 Édition Familiale Premium SP1 64bits pré-installé par Dell
- Réseau : Bbox ADSL Sagem F@st 3965b débit ATM de 5119/797 Kb/s IPv4 uniquement
- Anti-virus : Microsoft Security Essentiales
- Navigateur : Firefox 36.0 32bits avec plug-in Flash 16
-
SRV?
-
c'est expliqué sur BugZilla :
Hi all - thanks for all the comments! I appreciate that seeing something new on your networks can be alarming; hopefully the following can explain our approach and mitigate your concerns.
Here’s some background: The goal was to get accurate TTLs for DNS records to improve accuracy for hostname-to-IP resolution. This was added in Bug 820391, and enabled in Bug 1084645. It is only enabled for Windows currently.
We had to use this approach of requesting A/AAAA then ANY because of the particular nuances of hostname resolution APIs:
— getaddrinfo, the POSIX cross-platform API doesn’t give access to TTL by itself. Previously on Windows, and currently on other platforms, we provided a fixed expiration time for the record because we can’t get the accurate TTL from the record itself.
— DnsQuery on Windows does provide access to the TTL, but it doesn’t provide an easy way to do an UNSPEC request - this means that not only could we not get A and AAAA at the same time, but we would miss out on NetBT resolutions. And the ordering of the addresses in the response would be different - this can be configured differently on different networks and machines and Windows takes care of that complexity in getaddrinfo. — Basically, DnsQuery on it’s own could have caused a ton of compatibility issues.
So, our solution was to call getaddrinfo first to get correct hostname resolutions, then perform an async-but-after call to DnsQuery using ANY to get the TTL information. Because it’s async, we’re not waiting on the client side for the response - if it doesn’t come, Firefox will use the fixed TTL we use on other platforms and it will run fine. We also apply a higher priority to the getaddrinfo requests; since they’re purpose is to get the list of resolved addresses, connections from Firefox should not be blocked by the secondary DnsQuery which is just about getting TTL for A and AAAA records.
In addition, in order to mitigate some of the issues brought up in this bug, we used several flags with our DnsQuery call:
DNS_QUERY_NO_NETBT — although we want NetBT results in the first call to getaddrinfo, we’re not as concerned about getting TTL for those, so we don’t want those requests on the wire.
DNS_QUERY_NO_MULTICAST — don’t do a multicast request on the network; we only want to query the servers.
DNS_QUERY_ACCEPT_TRUNCATED_RESPONSE — truncated responses are ok - this should avoid retries over TCP if we get a truncated response.
Hopefully that answers most of your concerns.
Of course, if anyone is seeing a real connection issue to do with this, the details of that would be most appreciated. Our goal has been to improve the connection accuracy of Firefox, not degrade it.
(Also, check out the pref “network.dns.get-ttl” in about:config - you can disable the TTL/ANY request by setting that to false).
en bref: ca ne concerne que Windows. c'est pour avoir le TTL des valeurs du DNS.
Quand on utilise les API génériques et qu'on demande A et AAAA on n'obtient pas leur TTL
Si on veut le TTL il faut utiliser une API spécifique a Windows mais celle ci donne des résultats différents suivant les cas pour des raisons de compatibilités.
La solution est donc de faire les 2 a suivre, la requête pour le TTL est faite en asynchrone via une ANY et ne ralenti pas la navigation. Une valeur par défaut de TTL est utilisé si on ne reçoit pas de réponse de l'ANY.
Dans ton cas:
1 ere requete : A pour lafibre.info, le navigateur n'a que l'IP et pas de TTL (il met donc la valeur par défaut)
il lance en asyncrhone une 2eme requete : ANY sur lafibre.info
Quand la réponse revient il en ignore l'IP (qu'il a deja avec la 1ere requete) et ne prend en compte que le TTL (18848 dans ton cas).
-
Quel est l'intérêt du TTL pour ce type de programme ?
-
L'objectif de Firefox, indiqué dans le lien bugzilla de kgersen est "d'améliorer la précision de la connexion de Firefox"
Si j'ai bien compris, c'est une nouveauté de Firefox 36 qui n'est présente que sous Windows pour l'instant mais qui devrait être déployé sur les autres plateformes plus tard.
En cas de non réponse (certains serveurs DNS bloque les requêtes "ANY" pour éviter les attaque Dénie de service par amplification), Firefox utilise un le TTL fixe utilisé sur les autres plateformes aujourd'hui.
Firefox utilise le flag "DNS_QUERY_ACCEPT_TRUNCATED_RESPONSE" pour demander au serveur DNS de répondre en UDP, ce qui donne une réponse partielle si la réponse fait plus de 1500 octets (il n'est pas possible de faire une réponse DNS sur plusieurs paquets, la solution est de passer en TCP, ce qui alourdi sensiblement la manœuvre avec une ouverture de connexion, une requête et une fermeture de connexion TCP + acquittement de tous les paquets.
A noter que Chrome 40 ne fait pas de requêtes ANY.
-
A la réflexion, c'est les FAI qui vont râler, cela doit avoir un impact important sur le nombre de serveur DNS à mettre en place.
Non seulement on double le nombre de requête DNS, mais j'imagine que les requêtes DNS de type "ANY" sont bien plus gourmandes en ressources pour les serveurs.
-
pas sur , si le navigateur respecte le TTL, pour beaucoup de domaines, il demandera moins souvent de résolutions DNS.
Par défaut Firefox est a 60 secondes de TTL ce qui est très court.
Lafibre.info a un TTL de 24 heures par exemple (donc en moyenne 12 heures via un serveur DNS cache).
A l'arrivé, le respect des TTL va générer moins de charge sur les serveurs DNS et plus de précision sur les IP utilisés.
De plus en plus de sites et services web utilisent des systèmes changeant souvent d'IP (load balancing (AWS RBL), frontal web (Cloudfront), IaaS et PaaS (AWS, Google Cloud,etc), etc). Certains sont a moins de 60 secondes.
-
Réaction de Stéphane Bortzmeyer (http://www.bortzmeyer.org/ et architecte système et réseau à l'Afnic) :
@lafibreinfo @mozilla @AFNIC Bon, à tout lire, c'est clair que l'idée de Mozilla est très mauvaise. https://bugzilla.mozilla.org/show_bug.cgi?id=1093983
Source : Twitter (https://x.com/bortzmeyer/status/573113182425890816)
(https://lafibre.info/testdebit/windows7/201503_win7_firefox36_https_download_3.png)
-
ce que je comprends pas c'est que c'est l'OS qui gere les DNS.... FX incluerait un cache DNS ?!
!
-
Oui, bien sûr, un navigateur doit bien conserver les résultats du DNS.
-
Si le navigateur ne conservait pas les résultats des requêtes DNS, il ferait une requête DNS à chaque page, voir même pour chaque élèment de la page !
-
?????
il y a bien un cache DNS on peut purger le biniou avec
https://documentation.cpanel.net/display/CKB/How+To+Clear+Your+DNS+Cache#HowToClearYourDNSCache-Windows7
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ipconfig.mspx?mfr=true
billou dit:
/flushdns : Flushes and resets the contents of the DNS client resolver cache. During DNS troubleshooting, you can use this procedure to discard negative cache entries from the cache, as well as any other entries that have been added dynamically.
-
Ipconfig /flushdns ne vide que le cache de Windows
Pas du tout celui de Firefox.
C'est d'ailleurs relativement chiant.
Par contre je n'arrive pas trop a voir quel est le but de la requête ANY
Quelqu'un pour ré-expliquer rapidement?
-
> Pas du tout celui de Firefox.
Justement, je vois pas pourquoi il gere des trucs OS natifs ^^
-
L'OS aussi gère les certificats SSL, mais Firefox les gère lui même pour des raison de sécurité.
Du coté de Chrome c'est pire, car il va gère lui même sa pile TCP/IP (avec les services Google par exemple) et au niveau de l'OS, il ne voit plus passer que du trafic UDP (le "TCP" maison de Google Chrome est au-dessus de UDP)
Le but est de pouvoir améliorer les perf : le navigateur est renouvelé tous les 2mois, alors que le système d’exploitation est supporté pendant 10ans.
-
FF gère un cache DNS parce que le code est multi-plateforme. Sur certains OS, l'OS ne gère pas de cache et sur d'autres le cache géré par l'OS est souvent trop petit (les navigateurs font du pre-fetch et les pages web dépendent souvent d'autres pages sur d'autres domaines)
La résolution de nom utilisée par les navigateurs est plus que de la résolution DNS sur IP (aka le protocol DNS) cela couvre aussi la résolution locale (fichier hosts) , la résolution de nom Windows (netbios) ou autre et prend en compte des réglages de priorité propre a la machine. Donc l'utilisation d'un code générique purement DNS (aka le protocol DNS) ne suffit pas et casserai le fonctionnement actuel des navigateurs (en entreprise notamment ainsi que chez les particuliers qui ont plusieurs machines sur leur LAN, un NAS notamment).
Je ne suis pas sur que tout les commentateurs aient pris en compte tout ces aspects.
C'est pas simple et c'est un compromis a trouver.
Le probleme principal vient que l'implèmentation de 'ANY' n'est pas la même partout. Certains resolver traitent cela en renvoyant tout ce qu'ils ont en cache, d'autres propagent systématiquement ce genre de demande a l'autorité du domaine ... en pratique donc ce n'est pas exploitable en usage régulier, ANY est plus réservé pour faire du diagnostique par exemple.
Ayant acté de ce fait, les devs de Firefox ont donc, pour le moment, décider de changer le flag (network.dns.get-ttl) et d'inverser le comportement. Il n'y aura plus de requêtes ANY par défaut il faudra l'activer dans about:config.
Pour l'avenir ils vont essayer d'obtenir le TTL sans utiliser de requête ANY.
-
Les requètes Netbios sont un héritage de NT4 : avec le renouvellement en Win7 et Win2008/2012, ça va disparaitre. Donc il n'y aura plus que DNS :)
-
il ne voit plus passer que du trafic UDP (le "TCP" maison de Google Chrome est au-dessus de UDP)
Ne veux-tu pas plutôt dire que Chrome utilise des sockets en mode "Raw" (= au dessus d'IP), plutôt que des sockets en mode "Stream" (= au dessus de TCP).
Je doute que Chrome encapsule du TCP dans de l'UDP.
-
Les requètes Netbios sont un héritage de NT4 : avec le renouvellement en Win7 et Win2008/2012, ça va disparaitre. Donc il n'y aura plus que DNS :)
D'ou tu sort ca ?
Met 2 PC sous Windows 7, 8.x ou meme 10 preview en réseau sur le meme LAN et fait ping entre eux en utilisant leur nom Windows je te parie que tu verra aucun trafic DNS...(d'ailleurs on peut les mettre en réseau sans serveur DNS).
-
Ne veux-tu pas plutôt dire que Chrome utilise des sockets en mode "Raw" (= au dessus d'IP), plutôt que des sockets en mode "Stream" (= au dessus de TCP).
Je doute que Chrome encapsule du TCP dans de l'UDP.
Tu doutes, mais Vivien a raison :)
-
Ne veux-tu pas plutôt dire que Chrome utilise des sockets en mode "Raw" (= au dessus d'IP), plutôt que des sockets en mode "Stream" (= au dessus de TCP).
Je doute que Chrome encapsule du TCP dans de l'UDP.
oui sont pas fous a ce point ;) ca n'est effectivement pas du TCP encapsulé dans de l'UDP. C'est du HTTP (du SDPY v3 en fait) au dessus d'UDP avec un contrôle de congestion et de retransmission inspiré de TCP (cubic notamment).
-
Je n'avais pas compris que vous faisiez référence à SDPY ;)
Je pensais à une implèmentation particulière du traditionnel "HTTP/1.1 over TCP over IP" dans Chrome, ne reposant pas sur la pile TCP/IP de Windows.
-
D'ou tu sort ca ?
Met 2 PC sous Windows 7, 8.x ou meme 10 preview en réseau sur le meme LAN et fait ping entre eux en utilisant leur nom Windows je te parie que tu verra aucun trafic DNS...(d'ailleurs on peut les mettre en réseau sans serveur DNS).
Un Active Directory en mode natif ne gère plus Netbios, il ne fonctionne plus qu'en DNS. Le mode mixte permet de faire les deux mais n'est supporté que jusqu'en 2003, plus en 2008. Donc en entreprise, Netbios ne pourra plus être utilisé au fur et à mesure des migrations.
Le support Netbios de Windows 7 et 8 a commencé à être de plus en plus restreint : dans Win 7, on peut encore le connecter à un domaine Samba 3/NT4 (basé entièrement sur Netbios) en re-activant certains clés de registre. Dans Win8, il sait encore voir les machines via broadcast mais ne sait plus les utiliser par exemple avec un montagne UNC type \\Nom-machine. Via clé de registre ça doit pouvoir néanmoins se re-activer.
Windows 8 ne sait plus utiliser le service WINS par exemple pour adresser une machine en Netbios dans un autre réseau.
Comme Microsoft n'a pas d'autre protocole pour une utilisation domestique, il reste actif.
-
Ne veux-tu pas plutôt dire que Chrome utilise des sockets en mode "Raw" (= au dessus d'IP),
Non.
Ce sont des opérations privilégiées.
-
Je me suis mal fait comprendre, je répondais a:
Les requètes Netbios sont un héritage de NT4 : avec le renouvellement en Win7 et Win2008/2012, ça va disparaitre. Donc il n'y aura plus que DNS
et pas au fait que Netbios allais disparaître. Ca j'en doute pas.
C'est disjoint. Il y n'y a pas que Netbios et DNS.
Par exemple Microsoft a LLMNR , Apple a mDNS, (cf zeroconf & co).
Le probleme est qu'on a pas toujours a disposition un serveur DNS sachant résoudre les noms locaux.
Certains routeurs/box qui font serveur DNS ne font pas forcement de résolution local au LAN.
-
Et pourtant il n'y aurait rien de plus facile pour toutes ces box basées sur du Linux :
- créer un domaine local ".home" avec une directive "allow-update locahost"
- activer ddns dans dhcpd pour la mise à jour de cette zone
Et DHCP la mettra à jour pour chaque machine fournissant un hostname.
-
La plupart font cela maintenant du moins pour les grands FAI il me semble non ? la NB6 le fait et la BBox aussi me semble. Je ne sais pas pour les autres. Apres c'est qu'en IPv4 cela.
Souvent en IPv6 on n'a plus DHCP mais SLACC donc le routeur/box ne peut plus faire du DDNS toute seule, du moins directement mais il y a des solutions (voir https://tools.ietf.org/html/rfc4472 et http://all-knowing-dns.zekjur.net/ par exemple). Reste a voir ce que les FAI ont prévu pour IPv6 a ce sujet ...
Apres Windows est prévu pour toute sorte d'environnements réseaux très variés et pas seulement les accès Internet grand public ou les réseaux d'entreprise avec Active Directory.
-
DDNS?
-
DynamicDNS
-
http://www.ghacks.net/2015/03/05/firefox-36-0-1-fixes-a-number-of-critical-issues/
l'ANY valse....
-
Firefox a désactivé dans Firefox 36.0.1 les requêtes de type "ANY" dans Firefox 36.
(https://lafibre.info/testdebit/windows8/201503_firefox_36_windows_81.png)