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
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
