It sounds like your interest here is not actually in _increasing_ the number of
record types in the response ("multi qtypes"), but in _decreasing_ it (an "RR
type filter"). I would treat that as a separate standardization topic.
For now, the Additional Section processing recommended for HTTPS records is not
a major source of overhead. Most HTTPS RRsets don't specify an alternate
TargetName anyway, and some embed IPv4 and IPv6 addresses directly [1].
Another case where this comes up is in the glue address records for delegation.
A v4-only (or hypothetically v6-only) resolver has no use for half the glue,
but it gets it anyway. A dual-stack resolver theoretically could skip the IPv4
glue.
I don't think the complexity of skipping these records is worth the
hypothetical savings in bandwidth or cache (which I doubt would be
significant), but it would be easier to reason about.
--Ben
[1] https://dns.google/query?name=www.cloudflare.com&rr_type=HTTPS&ecs=
________________________________
From: Petr Menšík <pemen...@redhat.com>
Sent: Friday, September 13, 2024 11:01 AM
To: dnsop@ietf.org <dnsop@ietf.org>
Subject: [DNSOP] Re: HTTPS and SVCB queries with
draft-bellis-dnsext-multi-qtypes-08 extension
Okay. Then let's mention majority of enterprise networks and ISPs, which still
have not heard about IPv6. If they have no IPv6 connectivity, they won't use
that as fallback. All bytes with AAAA addresses delivered to them are wasted.
Both in
Okay. Then let's mention majority of enterprise networks and ISPs, which still
have not heard about IPv6. If they have no IPv6 connectivity, they won't use
that as fallback. All bytes with AAAA addresses delivered to them are wasted.
Both in memory of caches and on wire.
For IPv4AAS, sure. I expect most of clients will have 464XLAT or similar
mechanism available. If they do, sending A query and response is okay and
useful. Then they should indicate it by sending both AAAA and A additional
queries. They are dual stack in such case, from remote networks view at least.
My idea should help to very conservative networks (no IPv6) or very modern
networks (no IPv4). Unfortunately DNSSEC validation on client machines is much
less common than sending unnecessary queries and responses.
On 13/09/2024 16:38, Mark Andrews wrote:
Also just about every IPv6 only network will have IPv4AAS to reach the legacy
servers so the A records are need especially if you are also validating
answers. Also the provide a fallback if the IPv6 path is broken.
--
Mark Andrews
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
