Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs/HTTPSRR.md: initial HTTPS RR documentation #16052

Merged
merged 1 commit into from
Jan 25, 2025
Merged

Conversation

bagder
Copy link
Member

@bagder bagder commented Jan 19, 2025

No description provided.

@bagder
Copy link
Member Author

bagder commented Jan 19, 2025

Maybe @sftcd or @icing have feedback? This is just a first shot and is meant to describe the rough current status.

@sftcd
Copy link
Contributor

sftcd commented Jan 21, 2025

Good to see progress on this. Happy to try help as I can. A few thoughts:

  • @niallor has been looking at this a bit and likely also has ideas
  • we've published a range of good/bad/oddball HTTPS RRs for ECH testing - you can see details here; be happy to add more, but that list may also be useful when thinking what to do
  • have you thought about aliasMode and chasing those? (bit like CNAMEs)
  • similarly, handling IP hints vs. A/AAAA likely needs thought
  • there's an IETF activity just starting to consider some of this "happy eyeballs" stuff, so it may be an idea to consider what's going on there: https://datatracker.ietf.org/wg/happy/about/

@bagder
Copy link
Member Author

bagder commented Jan 21, 2025

This is still early days. I'm right now focusing on setting up the architecture so that we can get HTTPS records independently of chosen resolver backend (#16054). To make HTTPS RR support usable outside of DoH.

When that works decently, it will be easier to work on extending and improving the receiving and handling of the actual records that are received.

  • we've published a range of good/bad/oddball HTTPS RRs for ECH testing - you can see details here; be happy to add more, but that list may also be useful when thinking what to do

Yes thanks. We of course need a lot of live test servers to try it on. Especially before we have worked out how exactly we should go about and add "normal" tests for this.

  • have you thought about aliasMode and chasing those? (bit like CNAMEs)

I figure we ultimately need to chase them - if this feature is actually used in the real world. If the chasing is not done by the resolvers it feels like it might get a little ineffective and thus might not be what servers want to use.

  • similarly, handling IP hints vs. A/AAAA likely needs thought

I agree. For now we don't use the IP hints at all, but we should decide what the best use of them is. Maybe check how some of the already deployed HTTPS RR consumers (browsers?) do.

Yes, that is work to observe and potentially contribute to. It can be worth pondering that we do not support Happy Eyeballs v2 in libcurl (due to API limitations primarily).

We also need to consider and think about how HTTPS RR works in conjunction with alt-svc: headers, and possibly with HSTS.

@niallor
Copy link

niallor commented Jan 21, 2025 via email

bagder added a commit that referenced this pull request Jan 24, 2025
@bagder bagder marked this pull request as ready for review January 24, 2025 15:23
bagder added a commit that referenced this pull request Jan 25, 2025
@bagder bagder closed this in 7f4f192 Jan 25, 2025
@bagder bagder merged commit 7f4f192 into master Jan 25, 2025
219 of 220 checks passed
@bagder bagder deleted the bagder/HTTPSRR branch January 25, 2025 23:05
vszakats added a commit that referenced this pull request Jan 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants