Support Port Prefixed QNAMEs
Categories
(Core :: Networking, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox100 | --- | fixed |
People
(Reporter: djackson, Assigned: kershaw)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(2 files)
The HTTPS RR uses Port Prefix Naming (Section 2.3), with one
modification: if the scheme is "https" and the port is 443, then the
client's original QNAME is equal to the origin hostname, without any
prefix labels.
...
Note that none of these forms alter the HTTPS origin or authority.
For example, clients MUST continue to validate TLS certificate
hostnames based on the origin host.
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-00#section-7.1
When querying the SVCB RR, an origin is translated into a QNAME by
prepending the hostname with a label indicating the scheme, prefixed
with an underscore, resulting in a domain name like
"_examplescheme.api.example.com.".
Protocol mapping documents MAY specify additional underscore-prefixed
labels to be prepended. For schemes that specify a port
(Section 3.2.3 of [URI]), one reasonable possibility is to prepend
the indicated port number (or the default if no port number is
specified).
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-00#section-2.3
As I read it, https://example.com:8080
would become a QNAME of _8080._https.example.com
when looking for HTTPS resource records.
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
Depends on D141717
Comment 4•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/5f73835f055f
https://hg.mozilla.org/mozilla-central/rev/bdbda5a1f1a8
Description
•