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).

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.

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.

ce que je comprends pas c'est que c'est l'OS qui gere les DNS.... FX incluerait un cache 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 !