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::53Is 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::53This 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
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
