Direct baseline
idleOrdinary A record points directly to the public TLS endpoint.
Confirms the test server and certificate path are reachable.
open endpoint
A project dashboard and live interoperability sampler for RFC 9460 ServiceMode targets, AliasMode, address hints, alias chains, and alternate ports in Chromium.
The original implementation handled a narrow ServiceMode shape. This stack keeps HTTPS RR metadata associated with its target, resolves target addresses, follows AliasMode links, accepts usable hints without origin addresses, and carries an allowed alternate port into the connection endpoint.
This runs real cross-origin requests through public DNS. The direct case is a control. The other six names have unusable or absent origin addresses, so they only pass when the browser discovers a usable endpoint from HTTPS RR processing.
The ServiceMode case also verifies the response came through the Caddy listener on 159.195.20.167:8443.
Ordinary A record points directly to the public TLS endpoint.
Resolves a different TargetName with A/AAAA followups and connects on port 8443.
The target has no A or AAAA records. The endpoint comes from ipv4hint.
The origin has no A or AAAA record. Its own HTTPS RR supplies the only endpoint via ipv4hint.
The origin has no A or AAAA record. Its HTTPS RR supplies a physical IPv6 endpoint via ipv6hint.
A priority-zero record schedules A, AAAA, and HTTPS queries for its alias target.
Two AliasMode links exercise all six bounded followup transactions.
Extracts ipv4hint and ipv6hint under the HTTPS RR feature.
Turns priority-zero HTTPS records into resolver aliases.
Keeps metadata and hints for ServiceMode TargetNames.
Schedules bounded target queries and preserves final service endpoints.
Carries a scheme-allowed HTTPS RR port through metadata to connection attempts.
The numbering is the intended landing order. Each change has one responsibility and depends on the one above it.
Use a fresh profile so host cache and connection reuse cannot hide DNS behavior. The feature parameters disable Chromium's normal 5-50 ms supplemental HTTPS-query timeout so this validation run waits for the RFC 9460 result instead of intentionally falling back to A/AAAA.
out/Default/chrome \
--user-data-dir=/tmp/chrome-httpsrr \
--no-first-run \
--enable-features=AsyncDns,UseDnsHttpsSvcb:UseDnsHttpsSvcbInsecureExtraTimeMax/0/UseDnsHttpsSvcbInsecureExtraTimePercent/0/UseDnsHttpsSvcbInsecureExtraTimeMin/0/UseDnsHttpsSvcbSecureExtraTimeMax/0/UseDnsHttpsSvcbSecureExtraTimePercent/0/UseDnsHttpsSvcbSecureExtraTimeMin/0,UseDnsHttpsSvcbHttpsRr,HappyEyeballsV3 \
--log-net-log=/tmp/httpsrr-netlog.json \
--net-log-capture-mode=Everything \
https://static.januschka.com/i-40257146/chromium-https-rr_153.0.7994.0_amd64.deb (559 MiB)
Release, non-component Debian package built from all five changes. SHA-256 · build details
sudo dpkg -i chromium-https-rr_153.0.7994.0_amd64.debChromium issue 40257146 · interoperability issue 388545139 · RFC 9460 · CL stack root
Open this section to load server.py.Snapshots are refreshed from the standalone lab directory, not from the production host configuration. Run update.py after Gerrit or lab changes:
./update.py --src /path/to/chromium/src --lab-dir /path/to/https-rr-labThese are the records currently used by the public sampler. The 192.0.2.0/24 addresses are intentionally unusable.
$ORIGIN bartlby.org.
$TTL 60
httpsrr-direct IN A 159.195.20.167
httpsrr-service-origin IN A 192.0.2.1
httpsrr-service-origin IN HTTPS 1 httpsrr-service-target.bartlby.org. alpn="h2" port=8443
httpsrr-service-target IN A 159.195.20.167
httpsrr-hint-origin IN A 192.0.2.1
httpsrr-hint-origin IN HTTPS 1 httpsrr-hint-target.bartlby.org. alpn="h2" ipv4hint=159.195.20.167
httpsrr-hint-target IN TXT "intentional HTTPS RR target without A or AAAA"
httpsrr-no-address IN HTTPS 1 . alpn="h2" ipv4hint=159.195.20.167
httpsrr-ipv6-only IN HTTPS 1 . alpn="h2" ipv6hint=2a0a:4cc0:c1:3cb4:e822:68ff:fef3:fed5
httpsrr-alias-origin IN A 192.0.2.1
httpsrr-alias-origin IN HTTPS 0 httpsrr-alias-target.bartlby.org.
httpsrr-alias-target IN A 159.195.20.167
httpsrr-alias-target IN HTTPS 1 . alpn="h2"
httpsrr-chain-origin IN A 192.0.2.1
httpsrr-chain-origin IN HTTPS 0 httpsrr-chain-hop.bartlby.org.
httpsrr-chain-hop IN A 192.0.2.2
httpsrr-chain-hop IN HTTPS 0 httpsrr-chain-target.bartlby.org.
httpsrr-chain-target IN A 159.195.20.167
httpsrr-chain-target IN HTTPS 1 . alpn="h2"The previous attempt grew into a 63-change plan that tried to revive HEv3, add new connection-attempt abstractions, and implement HTTPS RR at the same time. The architecture kept moving, most of that stack never reached reviewable scope, and many prototype changes were abandoned.
This attempt starts after the useful HEv3 plumbing already exists. It stays in the resolver path that owns DNS transactions: extraction in DnsResponseResultExtractor, bounded followups in HostResolverDnsTask, and endpoint assembly in DnsTaskResultsManager. It does not invent a second query path or restructure the connection layer.
The result is five ordered changes with one concern each: hints, AliasMode, non-matching targets, followups, and ports. That is smaller, easier to review independently, and easier to drop or revise when feedback changes the design.