Discovery: Change to HTTPS DNS records #72
Conversation
oej
commented
Nov 18, 2024
oej
commented
- Remove the DNS URI records as a few large DNS providers does not support them (and the RFC is informational)
- Clarify TLS certificate requirements (according to RFC 9640)
- Fix some markdown formatting (make markdownlint happy)
oej
force-pushed
the
update-discovery
branch
from
8b12e00
to
5013726
Compare
Signed-off-by: Olle E. Johansson <[email protected]>
oej
force-pushed
the
update-discovery
branch
from
5013726
to
2715918
Compare
discovery/readme.md
Outdated
| _tei._tcp.tex.example.com. 3600 IN URI 20 1 “https://backup.example.com/transparency“ | ||
| _tei._tcp.tex.example.com. 3600 IN URI 30 1 “https://thirdparty.example.org/example.com/transparency“ | ||
|
|
||
| Results in `https://tea.example.com/.well-known/tea/<identifier>` while connecting to |
There was a problem hiding this comment.
I'm unclear why we'd connect to a host that is different from the URL - doesn't this just mean we'd connect to https://tea01.prod.example.com/.well-known/tea/<identifier> ?
There was a problem hiding this comment.
Also, I'd drop the <identifier> from this example as that is subject to the API Specification
There was a problem hiding this comment.
In the example we need something, but that is covered below I guess.
discovery/readme.md
Outdated
| - URL: `https://products.example.com/.well-known/tea/d4d9f54a-abcf-11ee-ac79-1a52914d44b1/` | ||
| - HTTP 302 redirect to "https://teapot02.consumer.example.com/tea/v2/product-index/d4d9f54a-abcf-11ee-ac79-1a52914d44b1' | ||
|
|
||
| The server at "teapot.prod.example.com" needs a TLS certificate including "products.example.com" |
There was a problem hiding this comment.
Why would we not just connect to teapot.prod.example.com? I don't understand the value provided by the TLS cert at teapot.prod.example.com also including a Subject Alt Name of products.example.com
There was a problem hiding this comment.
Because the "user" is connecting to "products.example.com" - all the other host names just show up in DNS resolution to find a proper HTTP server to connect to, but they don't change the URI that was requested.
There was a problem hiding this comment.
I guess this is akin to using CNAME records with regular HTTP web browsing...
There was a problem hiding this comment.
As CNAME can't be used at top level, like "https://edvina.net" these records will work there. Yes, it's similar.
| - URL: `https://www.example.com/transparency/d4d9f54a-abcf-11ee-ac79-1a52914d44b1/` | ||
| - DNS record: `products.example.com` | ||
| - Server found in DNS HTTPS record: `teapot.prod.example.com` | ||
| - URL: `https://products.example.com/.well-known/tea/d4d9f54a-abcf-11ee-ac79-1a52914d44b1/` |
There was a problem hiding this comment.
As per above - I'm unclear why the URL would not be https://teapot.prod.example.com/.well-known/tea/d4d9f54a-abcf-11ee-ac79-1a52914d44b1/
There was a problem hiding this comment.
DNS is just used to find the server for the HTTPS://products.example.com URI
I parse the RFC as this is NOT a redirection which would change the URI.
There was a problem hiding this comment.
I don't know if any web browsers or curl actually use these records. Will check with CURL.
…wn name space Text copied from RFC 6474 Signed-off-by: Olle E. Johansson <[email protected]>
|
Text from the RFC: "Note that none of these forms alter the origin or authority for So if the URI points to "products.example.com" - this is what you use to validate the TLS cert for the first server. After 302 you got a new or the same server. |
Signed-off-by: Olle E. Johansson <[email protected]>
|
https://www.netmeister.org/blog/https-rrs.html “Firefox has been making HTTPS lookups (albeit only over DoH) since May 2020, Apple’s iOS and Safari / macOS since September 2020, Chrome has had partial support since December 2020, and just recentlyenabled ECH by default. Various DNS service providers also offer support for HTTPS and SVCB records already.” |
Add UPC bar code Co-authored-by: Paul Horton <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>
Typo Co-authored-by: Paul Horton <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>
Co-authored-by: Paul Horton <[email protected]> Signed-off-by: Olle E. Johansson <[email protected]>
