If the A record is useless to a v6-only client, the client can drop it upon receipt without requiring new signalling between the stub and the resolver.
For multi-qtype to be the correct solution, I feel all the following need to be true: * The client would prefer to save 200 bytes in transit rather than get a partial answer 20 ms sooner. * Resolver support for multi-qtypes is mandatory in this context, so the client can rely on it. * The client requires direct access to the full flexibility of DNS. (A limited-purpose gateway will not suffice.) There may be situations that meet all of these criteria. If so, it would be nice to hear a bit about them. --Ben ________________________________ From: Petr Menšík <pemen...@redhat.com> Sent: Friday, September 13, 2024 6:25 AM To: dnsop@ietf.org <dnsop@ietf.org> Subject: [DNSOP] Re: HTTPS and SVCB queries with draft-bellis-dnsext-multi-qtypes-08 extension Yes, I am aware the code has to support parallel queries anyway, in case resolver does support optimizations. But my idea is not about how to reduce queries. What I though more about is how to reduce unnecessary records put into answer. Which goes into some cache usually. And putting unnecessary records into cache means less space remains for actually useful records. I made a post into dnssd about it just now, but let's also make example here. - example.com HTTPS query, with additional AAAA query in EDNS. What we should put into answer is described at RFC 9460, paragraph 4.2 [1]. ; ANSWER example.com 600 HTTPS 1 svc.example.net ; ADDITIONAL svc.example.net 1200 A 192.0.2.53 ; <-- this RR should be avoided svc.example.net 1200 AAAA 2001:DB8::53 Is there any way with single HTTPS query, how to indicate to add only AAAA records into additional section? Contrary to what RFC 9460 say? What would ipv6 only connected client do with A record? Ignore it? But why it were sent then? multi-qtypes can provide indication for that, as well as improved efficiency in ideal cases. If there is other good way, can you point me to it? ; ANSWER example.com 600 HTTPS 1 . ; ADDITIONAL example.com 1200 A 192.0.2.53 ; <-- this RR should be avoided also example.com 1200 AAAA 2001:DB8::53 This is proposed the most common scenario. But has the same problem. Why both A and AAAA are sent, when client can use only one of them? Should they waste space in cache for no reason? How should resolver sending them know? Regards, Petr 1. https://datatracker.ietf.org/doc/html/rfc9460#name-recursive-resolvers On 13/09/2024 11:29, Philip Homburg wrote: History shows that if you introduce a new thing DNS, lots of implementations will do something wrong. So it is unlikely that the system will actually get more simple. There may be good reasons to introduce more complexity. But on its own, any new feature is not going to reduce complexity. I carefully chosen my words. It will be easier to debug in common case, when all answers are delivered in single response. Yes, the complexity of code responsible will not be reduced, unfortunately. But to implement Happy Eyeballs algorithm in common applications, we need some added complexity anyway. We just need way to potentially reduce resources used in the future, where it makes sense. Yes, somebody will likely made it wrong. I think it is up to DNS community to make specs clear enough and then tell those individuals to fix their implementation. If somebody is still not processing EDNS0 correctly, then the time to fix that has passed 10 years ago. -- 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
