Hello!Is there any good place, where do you think possible improvements in resolution API provided to applications should happen? Should it be glibc mailing list?
We have touched it at my question about draft allowing multiple records in single DNS query [1]. In current best practice, applications should use getaddrinfo() call and friends. Problem with that is it does not keep any reusable state between resolutions. Another problem is it does not allow asynchronous usage, which is against the best practices of good frameworks used nowadays.
I think some more modern and capable API should be created in addition. Because majority of internet traffic is very likely some kind of HTTP traffic in various services, I think web improvement is the most important.
Today web applications use getaddrinfo() with AF_UNSPEC, which enables such application to work both with ipv6 and ipv4 address. What nss_dns module does is sending two queries in parallel. One for A record, another for AAAA record. I think it would be good to make web applications, like wget, curl or more complex applications, to send also HTTPS RR query [2].
Because I am at the same time Avahi maintainer, I think it should be possible to do it with protocol independent API. While the most common would be of course queries to old classic unicast DNS, also multicast DNS [3] and LLMNR protocols use the same header with possible same records types. And at least SRV record type [4] is very often used on mDNS, but with almost the same meaning in unicast DNS. SVCB RR is kind of extended variant of SRV, which allows specification of priorities, multiple supported protocols (ALPN) and name of secure service. HTTPS RR is a special case of SVCB RR.
I think tools like curl should send a triple of queries. A, AAAA and HTTPS record. But sending them separate is inefficient. draft-ietf-dnssd-multi-qtypes-04 [5] would make it efficient, but it requires discovering of capability of used resolvers. But current glibc stub is not flexible enough, if it frees all state information after every single name resolution. I think some context should be kept in single thread and reused among more resolutions. That would allow autodetection.
Is UAPI Group Specification [6] place to discuss this? I tried to make it compact, but it is already quite long description. But it would be quite long term improvement, if it should happen. While I would like to see that in glibc at some moment, it does not necessary need to start there.
I think struct addrinfo used by getaddrinfo() is basically good output even for HTTPS record. But it needs in addition also key=value metadata with additional parameters. Similar for SRV. The end result is still ordered list of addresses. But we need a way to extract ALPN, ECH and other parameters.
Do you have good recommendation, where to discuss this? Best Regards, Petr 1. https://mailarchive.ietf.org/arch/msg/dnsop/sF9UjTlMQWmjOmr_zx_Xoj-Ia1Q/ 2. https://www.rfc-editor.org/rfc/rfc9460.html 3. https://www.rfc-editor.org/rfc/rfc6762 4. https://www.rfc-editor.org/rfc/rfc2782 5. https://datatracker.ietf.org/doc/draft-ietf-dnssd-multi-qtypes/ 6. https://github.com/uapi-group/specifications -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
