On 13/09/2024 17:02, Petr Špaček wrote:
On 13. 09. 24 16:17, Ben Schwartz wrote: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.Curious question:Are there public data which show that A and AAAA arrive that far apart? I would expect that in most cases client will get either cache hit or miss on both, and there is no reason why one of them should be slower or faster. At least on DNS protocol level.
If we had API implementing Happy Eyeballs (RFC 8305), this might be somehow common scenario. Application would start connecting to whatever response it got first, not waiting for alternative query to finish.
I would know a reason, even not a good one. Dnsmasq can register A record for hostname from DHCP, but if the host does not use DHCPv6 too, AAAA query for the same host is forwarded further upstream, creating different path with different response time. Because it does not operate on normal DNS zones concept...
I think this is a problem for any current client using standard getaddrinfo() call. I have seen only glibc implementation on Linux, but it does not keep any context between two consecutive getaddrinfo() calls. Therefore it cannot keep state, what were supported on that resolver just 100ms ago. That limits any kinds of detection. No generic enough replacement is available.* 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.)I would not say mandatory. Client must do some form of detection before relying on it, and implement a fallback.
Yes, I think that needs to be significant, because typical HTTP request contains much more headers, as does the response. If you want to keep your DNS similar sizes to be not so recognizable, you will need padding on each request. Then yes, amount of traffic can differ significantly, even if number of queries does not.There may be situations that meet all of these criteria. If so, it would be nice to hear a bit about them.I vaguely remember that Lorenzo Colitti had a complaint in an IETF session that DoH overhead noticeably increases data consumption on mobile devices. I guess query coalescing might help with this as well.
Yes, I understand. I think at least for Linux and similar unix-like systems, glibc people would have to design some API, which operates with context keeping state. That should allow caching recently discovered features and using them. I am not aware if Microsoft or Apple systems have designed something better already. If they rely on some DNS service to be running on every machine, then it should be relatively easy to solve. Service could keep context, when applications do not have to. But it needs information from applications, what records it would need for this name, in single request. Keeping features of upstream resolver is already handled by such services.Having said that, my main worry is that complexity on server will be wasted by having zero clients to make use of it. See responses on this topic in dnssd WG. Beginning of the thread is here:https://mailarchive.ietf.org/arch/msg/dnssd/hO1QxNPPTPSx8S8vD6mqPKFUYMQ/ IIUC the only people who spoke up were from OpenThread project.
Classic old nsswitch dns plugin is not able to make auto-detections, as it is implemented now. Maybe "options edns0 multiq" could be specified in /etc/resolv.conf manually. That will indicate stub can rely on support of multi-qtypes on specified resolver, probably local service. When AF_UNSPEC is used in getaddrinfo(), it would request AAAA and A both. Current applications create two separate DNS queries, where information that it needed 2 different records on the same name is lost. An exception could be systemd-resolved, which has own nss-resolve plugin. It might be able to forward "get all addresses on name X" request into running service.
Problem is also glibc does not have even normal gitlab or github issues, where we could place some issue. They have old school mailing list only and rotting bugzilla. I doubt its maintainers watch or read any IETF mailing list, not dnsop or dnssd IMO. Redesigning such basic API would be a greater task. It is not clear who should pay for that...
But I think some change is needed to support at least HTTPS RR outside of browsers. I think client stub interfaces have significant technology debt already, but I do not see anyone willing to invest into it non-trivial effort.
I can try creating few issues on Fedora, but doubt it would get a priority anytime soon, if ever.
Regards, PetrPS: Sorry for too many lines and linux stub excursion. I hope they are related.
-- 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
