dns: HTTPS and SVCB records for ALPN (DNS slice 7) #71
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
RFC 9460: the client takes
alpn,portand the address hints of an origin. The records themselves are built (HttpsandSvcbwithServiceParameterinstd/dns, DNS.md slice 1); ALPN instd/tlsis built (#118). What is missing is the client side:Clienthas no resolver option, so it cannot ask for anHTTPSrecord at all.This is an epic: it needs a shared resolver abstraction and a client option first (DNS.md section 7 names it as "the next step"), which is its own PR, then the record handling.
Source
h2waits for HTTP/2 (#72, NETWORK.md slice 12).Steps
Resolver,TlsResolver,DohResolver,Clientoption #525 (landed in PR #527)HTTPSrecord of an origin #558h2joins the offered protocols (after #72; otherwise onlyhttp/1.1is offered)Step 2 (filed as #558, decided by the loop)
For an
httpsorigin and a client with a resolver:HTTPSrecord of the host (_<port>._https.<host>where the port is not 443, RFC 9460 section 9.5). AnAliasModerecord (priority 0) is followed to its target, at most 8 hops;ServiceModerecords are tried by ascending priority. No record, a failed lookup or an unusable record means today's behaviour, never a failure of the request.portreplaces the origin's port for the connection (not theHostheader);alpn(plus the defaulthttp/1.1unlessno-default-alpn) is intersected with what the client supports and offered throughTlsSettings.protocols;ipv4hintandipv6hintare used only whenA/AAAAanswer nothing (RFC 9460 section 7.3).echand other keys are ignored (own issues).dns-over-httpsdoes) prove each rule above in VM and--native;Mandatorykeys the client does not know make the record unusable.Design record / seed
Implements DNS.md slice 7 and section 7. Seed: no (std only, no syntax, no native, no string lookup by the compiler).
Dependencies
#118 (tls: ALPN) is closed and landed. Step 3 depends on #72. No
readyon the epic itself; each step is its ownreadyissue.Moved from the planning lists of the docs; the design record stays the specification.
[loop:torbscript] intake: in scope (author orion, label loop), source DNS.md slice 7 (RFC 9460), not a duplicate. Depends on #118 (TLS ALPN). next: waiting (dependency #118) until 2026-10-10T04:00:00Z
[loop:torbscript] claim refine by session:loop-torbscript-20261027 until 2026-10-27T05:00Z
[loop:torbscript] decided by the loop: slice 7 is larger than one PR (no client resolver option exists, DNS.md section 7 lists it as the next step), so #71 is an epic with a checklist; only step 1 is filed (#525, ready, dependency #118 closed). Step 2 is filed when step 1 has landed;
h2waits for #72, until then onlyhttp/1.1is offered. Seed impact: none.[loop:torbscript] refine: epic body rewritten to the definition of ready, step 1 filed as #525 with
ready, next: waiting (step #525). Tokens: ~60000[loop:torbscript] claim refine by session:loop-torbscript-20261029 until 2026-10-29T01:13:11Z
[loop:torbscript] decided by the loop: step 1 (#525, PR #527) is on
main(NameResolverinstd/network,Client.resolver, conformance testhttp-client-resolver) andmainCI is green on its head, so step 2 is unblocked and filed just in time as #558 withready(rules as planned in the epic body; keyword search of open issues for HTTPS/SVCB/resolver found no duplicate; backlog gate off). Step 3 (h2) stays blocked on #72 (HTTP/2, open); until then onlyhttp/1.1is offered, which #558 accounts for. Seed impact: none.[loop:torbscript] refine: step 1 ticked and step 2 linked in the epic checklist, next: waiting (step #558, then step 3 after #72). Tokens: ~45000
[loop:torbscript] wait until 2026-11-06T04:00Z: step 2 (#558) is closed; step 3 (h2) stays blocked on #72 (HTTP/2, still open).
next: waiting (step 3 after #72)