[dns-operations] HTTPS record support

[Petr Menšík]

On 09/09/2025 18:12, Viktor Dukhovni wrote:
> On Tue, Sep 09, 2025 at 05:52:18PM +0200, Florian Weimer via dns-operations wrote:
>
>>>> I've got an RFE to add HTTPS/SVCB support to glibc's getaddrinfo
>>>> implementation.
>>> Why?  It seems an unnatural layer violation.  The IP addressses of a DNS
>>> name are NOT provided by its HTTPS or SVCB records.  IP address lookups
>>> make sense only *after* a higher layer application API that understands
>>> whether or not and which of either SVCB or HTTPS records may be
>>> relevant, processes those records and determines which target IP
>>> addresses and ports it wants to connect to, and over what transports.

This is not what browsers do today, AFAIK. I think they resolve A, AAAA 
and HTTPS at the same time, in parallel.

Main intention of that request is that we lack good API for applications 
to request HTTPS record. Depending on hostname, it might be google.com 
or example.local. I see no reason to avoid HTTPS records querying on 
Multicast DNS. That is why I requested API, which is not DNS protocol 
specific.

Meaning if I use c-ares library, which contacts DNS server on url 
http://example.local/, I think it is leaking data to DNS server. There 
are few protocols used today: DNS (unicast, port 53), multicast DNS 
(multicast, link-local, port 5353) and LLMNR (multicast, link-local, 
port 5355). Responses from all of them are in DNS format and relatively 
compatible. But obtaining those responses differs a lot. I think that 
part should be hidden in protocol independent API, which are implemented 
by system plugins.

>> The getaddrinfo specification and its refinements that make it clear
>> that this interface is not just there to get the raw address information
>> out of DNS, but also to perform address sorting based on various
>> factors, including network topology information.  It's not much of a
>> stretch to include address priority information from DNS as well.
> The result of a call to getaddinfo(3) is a list of:
>
>             struct addrinfo {
>                 int              ai_flags;
>                 int              ai_family;
>                 int              ai_socktype;
>                 int              ai_protocol;
>                 socklen_t        ai_addrlen;
>                 struct sockaddr *ai_addr;
>                 char            *ai_canonname;
>                 struct addrinfo *ai_next;
>             };
>
> Which cannot even approximately express the content of an HTTPS or SVCB
> RRset.  Nor is the (node, service) lookup key able to clearly express
> whether such RRsets are relevant to resolving the node and service to a
> list of "addrinfo"
HTTPS in the end results in list of addresses and ports. HTTPS could 
result in alternative port, that can be recorded in sockaddr_in. But 
weight and priority, alpn and various other HTTPS information would be 
lost. There is no way to place them in existing structure.
>> I'm not saying that we should go down this path, I'm just trying to
>> explain why I didn't want to close the RFE immediately.
> The RFE should be closed.  The the meaning of HTTPS/SVCB records is not
> aligned with the getaddrinfo(3) API for (node, service) even if the
> service happens to be "https".
>
> The getaddrinfo() API has never resolved MX records when handling (node,
> "smtp"), or nSRV records when handling ("node", "xmpp-server"), and I
> see no reson why it has any business attempting anything of the sort
> with HTTPS or SVCB.  That logic belongs in "libcurl", ... not
> getaddrinfo().

I never requested exporting HTTPS and SVCB records via getaddrinfo() 
struct addrinfo structures. struct addrinfo is good, but it is missing 
place to store per-socket key+value addiitonal data.

But yes. I think we miss protocol independent API for requesting MX 
record or SRV record. Because SRV record has the same meaning on port 53 
and 5353, but the query required to obtain it is different and the 
protocol obtaining them differs a lot. How should they be used by the 
application is not so different.

I requested something else. I want protocol independent API, which could 
be implemented by (something like) nss plugins. Something, which would 
allow fetching TXT or SRV records not only from DNS resolver, but also 
from mDNS or LLMNR protocols. Just in the same way, same API. I think 
applications itself should not implement them separately. They may be 
able to specify protocols used if default does not suit them. The same 
API could provide HTTPS RR response, which would be always served by the 
same nssswitch plugin as getaddrinfo used. That way, HTTPS RR request 
could be consistent, even if the system obtained the response from 
/etc/hosts, mdns or LLMNR.

I think applications should not do something like:

if (endswith(hostname, ".local")) {
   libmdns_query(state, hostname, C_IN, T_SRV, answer, len);
} else {
   res_nquery(state, hostname, C_IN, T_SRV, answer, len);
}
// instead have something:
   universal_nquery(state, hostname, C_IN, T_SRV, answer, len, "dns 
mdns"); // or NULL if application wants system defaults.

But use common API, which has details implemented by backends for their 
convenience.

-- 
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB