From fweimer at redhat.com Tue Sep 9 10:26:44 2025 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 09 Sep 2025 12:26:44 +0200 Subject: HTTPS record support Message-ID: I've got an RFE to add HTTPS/SVCB support to glibc's getaddrinfo implementation. To get an idea whether this makes sense given the getaddrinfo API constraints, I need to know more about actual deployment. Is there any data about it? Are multiple alias names common? Are address hints common? Browsers seem to query it. I tend to get cache hits from larger resolvers for HTTPS records for popular domains. But there is no HTTPS additional section processing in most stub resolvers that I encounter. (Even if processing is present, it's impossible to tell if RRsets are treated atomically as expected.) Lack of trustworthy additional section data means that the number of DNS queries would go from two (A/AAAA) to 5 in case of two aliases (HTTPS, followed by A/AAAA for each alias). This isn't ideal for an API like getaddrinfo, which would have to perform all this work upfront, whether the application will use the data or not. If address hints are common, we could add a mode (enabled by applications for individual calls) where getaddrinfo returns with address data from the HTTPS record itself if it is available, without chasing for the additional data. But I don't have evidence that hints are widely available. Thanks, Florian From ietf-dane at dukhovni.org Tue Sep 9 14:33:27 2025 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 10 Sep 2025 00:33:27 +1000 Subject: [dns-operations] HTTPS record support In-Reply-To: References: Message-ID: On Tue, Sep 09, 2025 at 12:26:44PM +0200, Florian Weimer via dns-operations wrote: > From: Florian Weimer > Date: Tue, 09 Sep 2025 12:26:44 +0200 > Subject: HTTPS record support > To: dns-operations at dns-oarc.net > > 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. > To get an idea whether this makes sense given the getaddrinfo API > constraints, I need to know more about actual deployment. I don't see how it can possibly make sense. Where is the rationale for this "RFC"? -- Viktor. ?? ????? ???????! From fweimer at redhat.com Tue Sep 9 15:52:18 2025 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 09 Sep 2025 17:52:18 +0200 Subject: [dns-operations] HTTPS record support In-Reply-To: (Viktor Dukhovni's message of "Wed, 10 Sep 2025 00:33:27 +1000") References: Message-ID: * Viktor Dukhovni: > On Tue, Sep 09, 2025 at 12:26:44PM +0200, Florian Weimer via dns-operations wrote: > >> From: Florian Weimer >> Date: Tue, 09 Sep 2025 12:26:44 +0200 >> Subject: HTTPS record support >> To: dns-operations at dns-oarc.net >> >> 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. 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. 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. Thanks, Florian From lathama at gmail.com Tue Sep 9 16:03:17 2025 From: lathama at gmail.com (Andrew Latham) Date: Tue, 9 Sep 2025 10:03:17 -0600 Subject: [dns-operations] HTTPS record support In-Reply-To: References:

Message-ID: Florian Can you share a link to the ticket or RFE here? On Tue, Sep 9, 2025 at 9:57?AM Florian Weimer via dns-operations wrote: > > > > > ---------- Forwarded message ---------- > From: Florian Weimer > To: dns-operations at dns-oarc.net > Cc: > Bcc: > Date: Tue, 09 Sep 2025 17:52:18 +0200 > Subject: Re: [dns-operations] HTTPS record support > * Viktor Dukhovni: > > > On Tue, Sep 09, 2025 at 12:26:44PM +0200, Florian Weimer via dns-operations wrote: > > > >> From: Florian Weimer > >> Date: Tue, 09 Sep 2025 12:26:44 +0200 > >> Subject: HTTPS record support > >> To: dns-operations at dns-oarc.net > >> > >> 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. > > 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. > > 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. > > Thanks, > Florian > > > > > ---------- Forwarded message ---------- > From: Florian Weimer via dns-operations > To: dns-operations at dns-oarc.net > Cc: > Bcc: > Date: Tue, 09 Sep 2025 17:52:18 +0200 > Subject: Re: [dns-operations] HTTPS record support > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- - Andrew "lathama" Latham - From ietf-dane at dukhovni.org Tue Sep 9 16:12:02 2025 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 10 Sep 2025 02:12:02 +1000 Subject: [dns-operations] HTTPS record support In-Reply-To: References:

Message-ID: 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. > > 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" > 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(). -- Viktor. ?? ????? ???????! From jabley at strandkip.nl Tue Sep 9 16:44:16 2025 From: jabley at strandkip.nl (Joe Abley) Date: Tue, 9 Sep 2025 18:44:16 +0200 Subject: [dns-operations] HTTPS record support In-Reply-To: References: Message-ID: <36F72ED1-CB33-4B59-AD1B-AA25FF92705E@strandkip.nl> Hi, On 9 Sep 2025, at 16:33, Viktor Dukhovni wrote: > On Tue, Sep 09, 2025 at 12:26:44PM +0200, Florian Weimer via dns-operations wrote: > >> From: Florian Weimer >> Date: Tue, 09 Sep 2025 12:26:44 +0200 >> Subject: HTTPS record support >> To: dns-operations at dns-oarc.net >> >> 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. I assume you are saying that "The IP addresses" with a capital The are more general than anything that might be published in the bindings for a particular service, which seems fair. We have seen lots of HTTP clients connecting to the addresses provided in HTTPS records' ipv4hint and ipv6hint SvcParamKeys, even when they are different from the addresses that would be obtained using QNAME=A or AAAA. (Ordinarily these addresses would all be the same, but there was a situation a while back when they were different, so we noticed.) RFC9460 allows this, even if it advises otherwise with SHOULDs. Joe From fweimer at redhat.com Tue Sep 9 17:13:58 2025 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 09 Sep 2025 19:13:58 +0200 Subject: [dns-operations] HTTPS record support In-Reply-To: (Andrew Latham's message of "Tue, 9 Sep 2025 10:03:17 -0600") References:

Message-ID: * Andrew Latham: > Can you share a link to the ticket or RFE here? Here's one: SVCB and HTTPS RR should have protocol independent API It's worded as requesting a new API in addition to getaddrinfo, but that's really not where I want to go. There is an related upstream ticket for the older SRV record: Support for SRV records in getaddrinfo Thanks, Florian From nanog at immibis.com Tue Sep 9 20:24:39 2025 From: nanog at immibis.com (nanog at immibis.com) Date: Tue, 9 Sep 2025 22:24:39 +0200 Subject: [dns-operations] HTTPS record support In-Reply-To: References:

Message-ID: On 9/09/25 18:12, Viktor Dukhovni wrote: > 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(). Note that a domain name which has an MX record is *not* the name of an SMTP service, but one with an HTTPS record *is* the name of an HTTP service. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Tue Sep 9 22:48:21 2025 From: marka at isc.org (Mark Andrews) Date: Wed, 10 Sep 2025 08:48:21 +1000 Subject: [dns-operations] HTTPS record support In-Reply-To: References: Message-ID: <8D0919B9-B63B-47F2-ACD5-1EA457D0F00F@isc.org> Actually both MX and HTTPS are the name of a services. That service may or may not use addresses at the same name as the connection end point. Getaddrinfo(port=25) looking up MX makes some sense. HTTPS for 80 and 443. SRV for those that use SRV. But you also need to add flags to disable the lookup. You won?t know if an implementation supports the protocol you care about so you can?t write portable code. The structure needs to be extended to return the auxiliary data. We have APIs to lookup arbitrary types. They are REQUIRED by STD13 (DNS). They are not hard to use.I really don?t see the need to try to squish each new protocol inside of getaddrinfo. Mark -- Mark Andrews > El 10 sept 2025, a las 6:48, nanog at immibis.com escribi?: > > ? >> >> On 9/09/25 18:12, Viktor Dukhovni wrote: >> 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(). > Note that a domain name which has an MX record is *not* the name of an SMTP service, but one with an HTTPS record *is* the name of an HTTP service. > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations