SVCB/HTTPS vs. getaddrinfo: how to merge?

[Niall O'Reilly]

Please read on for comment in context below, both from
my experience as one of the team for the [DEfO][] Project,
and from personal reflection based on this experience.

On 25 Dec 2024, at 19:10, Jan Schaumann via bind-users wrote:

> Well, "support" here means different things, though.
> In my experimentation, I've found that some browsers
> only support some features of the HTTPS records.
>
> See e.g.:
>
> https://issues.chromium.org/issues/40937306
> https://bugzilla.mozilla.org/show_bug.cgi?id=1869075
>
> AFAIU, Chrome is primarily (only? at this time?)
> interested in using HTTPS records for ECH, which last
> I checked (about 6 months ago or so), Safari at least
> didn't support.

This doesn't surprise me. People working to develop an
ecosystem for ECH have seen a need for client-side support
for the HTTPS RR as indispensable, both in browsers and
in other clients, and have focused their efforts on what
would be most productive for them.

I'm not currently aware of the browser-developers' plans.
OTOH, Stephen Farrell and I have contributed ECH-only
HTTPS RR code to **curl** and **libcurl**.

> Honoring of alpn, port, and the behavior of handling
> chains in alias mode, or how to behave if an alias
> doesn't have A/AAAA records etc. all is also still
> very much hit or miss, I've found.

I've thought about how to extend what we've done in DEfO
in the "obvious" directions: to service-parameters other
than ECHConfigList, to DNS transports other than DOH,
to alias-chasing, and to resolution of target addresses.

I have prototype code for both alias-chasing and for making
use of the address hints in **libcurl**, but doing the job
properly is a bigger project than is possible with the
resources currently available.

Besides, I believe that alias-chasing and resolution of
target addresses both belong in the resolver, rather than
in application-library code.  This is why I have opened
issues, seeking to have this addressed, with both
[ISC][BIND9 issue] and [NLnet Labs][unbound issue].  I am sure
that these will receive attention as resources allow.

On 26 Dec 2024, at 21:56, Peter 'PMc' Much wrote:

> In practice, on my Berkeley/FreeBSD machines,
> getaddrinfo provides the results of that selection. getaddrinfo
> may or may not ask DNS in the process, depending on nsswitch.conf.
>
> Then, as far as I understand the HTTPS RR, it is designed to
> short-circuit this procedure and have the application client
> directly query the HTTPS RR, in order to benefit by faster startup,
> and probably ignoring any preference settings from ip6addrctl.
> I don't yet know how this will work out in practice,

> but it seems
> to me there is some potential for unexpected behaviour.

I think this last observation is an understatement. 8-)

However, as I read [RFC9460][], the section which specifies the
[address hints][] seems to recommend **NOT** short-circuiting
traditional address resolution, but rather using the address data
announced in A and/or AAAA RRs, if possible.

A discussion on how to limit (or prevent) the "potential for
unexpected behaviour" seems beyond the scope of this mailing
list, and will likely be informed by the [Happy Eyeballs v3][HEv3]
draft, and by RFCs including [RFC3493][] and [RFC6724][], as well
as [RFC9460][].

Happy New Year!
Niall O'Reilly

---
[HEv3]:
https://datatracker.ietf.org/doc/html/draft-pauly-v6ops-happy-eyeballs-v3-02
"Happy Eyeballs Version 3: Better Connectivity Using Concurrency"

[RFC3493]:
https://www.rfc-editor.org/rfc/rfc3493
"Basic Socket Interface Extensions for IPv6, Feb. 2003"

[RFC6724]:
https://www.rfc-editor.org/rfc/rfc6724
"Default Address Selection for Internet Protocol Version 6 (IPv6),
Sep. 2012, obsoletes RFC3484, has errata"

[RFC9460]:
https://www.rfc-editor.org/rfc/rfc9460
"Service Binding and Parameter Specification via the DNS (SVCB and HTTPS 
Resource Records),
Nov. 2023"

[address hints]:
https://www.rfc-editor.org/rfc/rfc9460#name-ipv4hint-and-ipv6hint
"RFC9460: specification of address hints"

[DEfO]:
https://defo.ie/
"Developing ECH for OpenSSL (DEfO)"

[BIND9 issue]:
https://gitlab.isc.org/isc-projects/bind9/-/issues/4810

[unbound issue]:
https://github.com/NLnetLabs/unbound/issues/1065
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250106/20657646/attachment.htm>