Hmm, yes, that is correct observation.
Although requesting also A and AAAA makes sense with HTTPS request, not so much for other requests. For example SVCB or SRV uses different qname, where addresses probably won't be. There could be practically identical protocol to multi-qtypes, except different code and meaning. Specification that would just specify even for NS delegations, that only specified records in additional section are desired. I would call it addr-qtypes, meaning types of desired addresses.
It would make it possible to use multi-qtypes with addr-qtypes in the same message, after all. Except signalling negative response would not be necessary, but the protocol used might be very similar. And used in whatever request, where addresses are common in additional section. If the target server would not understand it, it would just provide full response, like for any unsupported EDNS.
Although just one bit for request/response check, one bit for A and another for AAAA would be sufficient. Not sure if there are other common types except A and AAAA, where similar approach would make sense. One byte EDNS extension would be enough for A/AAAA "filtering".
On 13/09/2024 17:30, Ben Schwartz wrote:
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= <https://dns.google/query?name=www.cloudflare.com&rr_type=HTTPS&ecs=>
-- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
