Goal

• Provide protocol independent API similat to getaddrinfo(), which will make it possible to query HTTPS and SVCB records. RFC 9460 defines DNS resource format. It can be present on on unicast DNS (most likely), but can be used also on multicast DNS.

• • As a command line tool developer (for example curl), I want simple way to query addresses for HTTPS service. I do not want to implement separate backends for DNS and Multicast DNS protocols (avahi) in my application, but want single API work with both. Just providing correct name.
  • Because in the end my application wants to get ordered list of addresses, similar return format to getaddrinfo() call should be provided.
  • But additional key-value with parameters like priority, alpn and others, provided by resource records in generic manner, should be attached to each sockaddr structure. Possibly filled only when some flag indicates details are needed.
  • (Optional) SVC records also contain priority and may use similar API to be queried. They are heavily used in mDNS, but also in unicast DNS already.
  • Although we have res_query() calls, they are DNS protocol specific. mDNS is very similar to DNS and can use the same format of responses, but is a bit different. But processing SVC records is typically reimplemented in each end application, which is not necessary.
  • (Optional) Ideally new API should be also asynchronous

Acceptance criteria

A list of verification conditions, successful functional tests, or expected outcomes in order to declare this story/task successfully completed.

• Verify HTTPS record can be queried on DNS
• Verify HTTPS record can be queried on mDNS name ending with .local
• Verify SVCB record can be queried on DNS
• Verify SVCB record can be queried on mDNS name ending with .local

Because glibc provides getaddrinfo basic calls, I think similar new calls could provide ability to resolve also different records with additional metadata. They are in the end used for the same purpose.

Examples of tools using such API would be any tool doing HTTP requests. Primary candidates would be curl or wget. Then of course web browsers like firefox. But also external libraries doing json request, python or other languages bindings etc.

This would be a bigger feature, probably targetted to RHEL 11.