[dns-operations] HTTPS record support

[Mark Andrews]

Well the structure was designed to be extensible. Those are the minimum elements the structure has to contain.  If you are looking for ABI compliance you would add new stuff at the end.  I would also add flags to signal that  SRV, HTTPS, etc. should be looked up.  That change has to be requested by the application.

This should go through the IETF and then POSIX.  I believe that was the original path getaddrinfo took.

Getting stuff from IETF to POSIX has been problematic. Only half of the IPV6 has made that transition. The advance half hasn’t need adopted by POSIX. 
-- 
Mark Andrews

> On 15 Oct 2025, at 03:13, Petr Menšík <pemensik at redhat.com> wrote:
> 
> 
>> 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
>