3 ms·
I recently added HTTPS records to all of my domains, along with HTTP/3. From query statistics, I see that around 15% of the queries are for HTTPS records, 30-3
by Ayesh 3y ago
I recently added HTTPS records to all of my domains, along with HTTP/3.
From query statistics, I see that around 15% of the queries are for HTTPS records, 30-35% for A and AAAA records, and the rest for RR types like NS, TXT, etc.
Browsers make HTTPS requests in addition to the A/AAAA, so this makes sense.
In an ideal world, the ipv4/ipv6hints do the job if A and AAAA records, so a browser will only need to make an HTTPS request.
- chrismorgan 3y agoNote that ipv4hint and ipv6hint are not supposed to replace A/AAAA <https://www.rfc-editor.org/rfc/rfc9460#name-ipv4hint-and-ipv6hint https://www.rfc-editor.org/rfc/rfc9460#name-ipv4hint-and-ipv...>: > The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to reach the service. If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints. Otherwise, clients SHOULD perform A and/or AAAA queries for TargetName per Section 3, and clients SHOULD use the IP address in those responses for future connections. Clients MAY opt to terminate any connections using the addresses in hints and instead switch to the addresses in response to the TargetName query. Failure to use A and/or AAAA response addresses could negatively impact load balancing or other geo-aware features and thereby degrade client performance. That is: you’re allowed to use the ipv4hint on this connection, but you should still fetch A/AAAA and use that subsequently.