WEB / WEB-03.04

Domain boundaries and resolver choices

Separate DNS views and encrypted resolver choices from browser origin/site boundaries.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Public view / DoH

URL and resolver context ready
No candidate IP yet. The channel is assumed established; TLS and bootstrap are not replayed.
Client and URL
https://notes.example.org/book; awaiting A
Selected resolver
DoH; HTTPS; warm authenticated
View data
public view; A=198.51.100.200
DNS query arrival
The query arrived at the resolver over the selected authenticated channel; view lookup is local.
Client and URL
https://notes.example.org/book; awaiting A
Selected resolver
query received: notes.example.org A; DoH; HTTPS
View data
public view; A=198.51.100.200
Local view selection
Policy context selects the view. The view data is not drawn as a separate storage query.
Client and URL
https://notes.example.org/book; awaiting A
Selected resolver
public selected locally; A=198.51.100.200; TTL=120
View data
public view; A=198.51.100.200
DNS answer arrival
The answer arrived at the client; it does not establish application TCP/TLS/HTTP success.
Client and URL
notes.example.org A=198.51.100.200; TTL=120
Selected resolver
public selected locally; A=198.51.100.200; TTL=120
View data
public view; A=198.51.100.200
Local candidate context
The URL origin is preserved and a candidate prepared. Post-DNS server identity and application results remain outside this model.
Client and URL
origin=https://notes.example.org; candidate=198.51.100.200; server identity not checked
Selected resolver
public selected locally; A=198.51.100.200; TTL=120
View data
public view; A=198.51.100.200

Employee view / DoT strict

URL and resolver context ready
No candidate IP yet. The channel is assumed established; TLS and bootstrap are not replayed.
Client and URL
https://notes.example.org/book; awaiting A
Selected resolver
DoT strict; TCP 853; warm authenticated
View data
employee view; A=192.0.2.40
DNS query arrival
The query arrived at the resolver over the selected authenticated channel; view lookup is local.
Client and URL
https://notes.example.org/book; awaiting A
Selected resolver
query received: notes.example.org A; DoT strict; TCP 853
View data
employee view; A=192.0.2.40
Local view selection
Policy context selects the view. The view data is not drawn as a separate storage query.
Client and URL
https://notes.example.org/book; awaiting A
Selected resolver
employee selected locally; A=192.0.2.40; TTL=120
View data
employee view; A=192.0.2.40
DNS answer arrival
The answer arrived at the client; it does not establish application TCP/TLS/HTTP success.
Client and URL
notes.example.org A=192.0.2.40; TTL=120
Selected resolver
employee selected locally; A=192.0.2.40; TTL=120
View data
employee view; A=192.0.2.40
Local candidate context
The URL origin is preserved and a candidate prepared. Post-DNS server identity and application results remain outside this model.
Client and URL
origin=https://notes.example.org; candidate=192.0.2.40; server identity not checked
Selected resolver
employee selected locally; A=192.0.2.40; TTL=120
View data
employee view; A=192.0.2.40

Shared IP, different origin

URL and resolver context ready
No candidate IP yet. The channel is assumed established; TLS and bootstrap are not replayed.
Client and URL
https://api.example.org/book; awaiting A
Selected resolver
DoH; HTTPS; warm authenticated
View data
public view; A=198.51.100.200
DNS query arrival
The query arrived at the resolver over the selected authenticated channel; view lookup is local.
Client and URL
https://api.example.org/book; awaiting A
Selected resolver
query received: api.example.org A; DoH; HTTPS
View data
public view; A=198.51.100.200
Local view selection
Policy context selects the view. The view data is not drawn as a separate storage query.
Client and URL
https://api.example.org/book; awaiting A
Selected resolver
public selected locally; A=198.51.100.200; TTL=120
View data
public view; A=198.51.100.200
DNS answer arrival
The answer arrived at the client; it does not establish application TCP/TLS/HTTP success.
Client and URL
api.example.org A=198.51.100.200; TTL=120
Selected resolver
public selected locally; A=198.51.100.200; TTL=120
View data
public view; A=198.51.100.200
Local candidate context
The api host remains a different origin despite a shared IP. Candidate selection does not widen browser boundaries.
Client and URL
origin=https://api.example.org; candidate=198.51.100.200; server identity not checked
Selected resolver
public selected locally; A=198.51.100.200; TTL=120
View data
public view; A=198.51.100.200

Strict channel unavailable

Strict profile selected
No authenticated channel is established; bootstrap/authentication context is selected but no usable service exists.
Client and URL
notes.example.org; candidate absent
Selected resolver
DoT strict; channel unavailable
View data
employee view data not consulted
Local stop before the query
Strict Privacy does not downgrade this query to plaintext. No answer or endpoint success is invented.
Client and URL
no DNS query sent; no answer
Selected resolver
DoT strict; channel unavailable
View data
employee view data not consulted

ACTORS · STATE · DATA FLOW

A public suffix is not simply the last label

A public suffix is an externally listed name boundary and can contain multiple labels. A registrable domain combines that suffix with the label immediately preceding it. Our selected org rule gives notes.example.org a public suffix of org and registrable domain of example.org. This is not a complete PSL parser or current list snapshot.

The PSL is a maintained input for particular browser domain groupings. A listed name does not prove DNS existence, operator identity or trust. Counting dots cannot establish that the last two labels always identify one organization. Registration, DNS authority and application permissions are separate relationships.

Domain, site and origin answer different questions

For ordinary HTTP(S) URLs, compare origins using scheme, host and effective port. A path change preserves origin; changing to api.example.org or port 8443 does not. Our selected browser-site calculation uses scheme and registrable domain: HTTPS subdomains may be same-site but cross-origin, and port is not part of that site calculation.

HTTP and HTTPS differ in this schemeful-site calculation even when their registrable domain matches. The artifact covers ordinary ASCII domain URLs, not opaque origins, IP hosts or IDNA edge cases. A same-site result does not grant same-origin access; a DNS zone boundary is also a different boundary.

Split-horizon: the same query with another selected view

Split DNS describes views that return different answers according to query source or other policy attributes. Our fixture returns notes.example.org A=198.51.100.200 in the public view and A=192.0.2.40 in the employee view. Both are documentation addresses; the employee label does not indicate a connection to a real internal network.

Changing only the returned IP leaves the URL’s origin tuple unchanged. Resolver selection, view policy and cache scope jointly affect results. A browser’s DoH resolver need not be the OS resolver, but this inert scene does not measure which resolver a real browser used. Selecting a view is not application authentication or authorization.

DoH and DoT can carry the same query differently

DoH carries DNS query/response messages in an HTTPS exchange. DoT carries DNS over TLS, by default on TCP port 853, with another port requiring mutual agreement. It is distinct from plaintext DNS on TCP 53. Normal branches in this example use an already established authenticated channel rather than drawing a new TCP/TLS handshake for every query.

The DoT label alone does not guarantee successful authentication in every privacy profile. We select RFC 8310 Strict Privacy: when its authenticated encrypted channel is unavailable, this query does not silently fall back to plaintext. Our DoH endpoint has a separately supplied bootstrap address/context, avoiding a dependency on the still-unreachable resolver to resolve itself.

The encrypted hop’s peer still sees the question

DoH/DoT protect the transport scope between client and selected resolver; that resolver still sees the DNS question it processes. This choice does not prove every subsequent path to authoritative servers is similarly encrypted. DNSSEC validation is not automatically established by either transport label.

Who the resolver is and which view it applies are separate trust decisions from transport encryption. The artifact shows a selected authenticated-channel condition and visibility boundary, without generating certificates, packets, access policies or resolver telemetry. HTTPS alone does not prove the correct DNS answer or application tenant.

DNS selects an address, not proof of backend identity

An A/AAAA answer provides a candidate network endpoint. That address may front a CDN, reverse proxy, load balancer or multiple HTTP hosts; the DNS-visible endpoint need not be the backend application machine. notes.example.org and api.example.org retain different URL origins even when both use 198.51.100.200.

An HTTPS client still needs server-identity verification against the URL host, while HTTP routing uses request authority. Our reference identity and authority remain notes.example.org; selecting an IP does not rewrite them. The scene prepares candidate context after resolution without claiming connection, TLS-verification or HTTP-handler success.

Read every scenario without motion

Shared IP

The requested protection scope was selected
notes.example.org and api.example.org share address 198.51.100.200. Network placement is not origin equality.
Context evidence
Same IP / different hosts
Boundary gate
No boundary gate
Outcome review
No outcome
Unsupported trust expansion was stopped
Origin is evaluated by scheme/host/effectivePort. The hosts may share site https://example.org but still have sameOrigin=false.
Context evidence
Same IP / different hosts
Boundary gate
sameSite=true / sameOrigin=false
Outcome review
No outcome
The boundary outcome was preserved
A shared IP does not transfer notes-origin rights to the api host. A registrable domain or suffix relationship also grants no application resource permission.
Context evidence
Same IP / different hosts
Boundary gate
sameSite=true / sameOrigin=false
Outcome review
Origin grant not inferred
Resolver-view context was retained
Public view gives 198.51.100.200 and employee view 192.0.2.40. Different context for one QNAME can be ordinary; address selection does not prove backend or tenant ownership.
Context evidence
Public / employee views separate
Boundary gate
sameSite=true / sameOrigin=false
Outcome review
Origin grant not inferred
Encryption does not complete another claim
DoH/DoT serverAuthenticated is a supplied channel condition; the resolver sees the DNS question. dnssecValidationClaimed=false remains intact, and HTTPS application reference identity is separate.
Context evidence
Public / employee views separate
Boundary gate
Channel auth ≠ DNSSEC / app auth
Outcome review
Origin grant not inferred
The context-gate regression finished
Origin/site/IP boundaries are separated; notes.example.org remains HTTP authority and TLS reference identity. ActualConnectOrCertificateCheck remains not-executed.
Context evidence
Public / employee views separate
Boundary gate
Channel auth ≠ DNSSEC / app auth
Outcome review
Same IP ≠ same origin; identity separate

Strict unavailable

The requested protection scope was selected
strict-unavailable uses the DoT Strict Privacy profile with channelAlreadyEstablished=false and serverAuthenticated=false. A query cannot be sent while discarding that profile.
Context evidence
DoT / Strict Privacy
Boundary gate
No boundary gate
Outcome review
No outcome
Unsupported trust expansion was stopped
fallbackToCleartextForThisQuery=false and dnsQuerySent=false. Adding silent cleartext fallback after channel failure would violate the supplied profile.
Context evidence
DoT / Strict Privacy
Boundary gate
Query withheld / no fallback
Outcome review
No outcome
The boundary outcome was preserved
answer=null is this branch’s explicit outcome. No resolver or endpoint success state is added; channel failure is not an application server’s permission denial.
Context evidence
DoT / Strict Privacy
Boundary gate
Query withheld / no fallback
Outcome review
No query / answer=null
Resolver-view context was retained
Although the employee view defines 192.0.2.40, this branch never reaches view lookup: dnsQuerySent=false and answer=null remain. Do not present a configured answer as one received from the resolver.
Context evidence
Employee view not consulted
Boundary gate
Query withheld / no fallback
Outcome review
No query / answer=null
Encryption does not complete another claim
With serverAuthenticated=false, the required authenticated channel is absent. The query was not sent to the resolver, so this operation establishes neither resolver receipt of the question nor DNSSEC validation. Do not import the normal channel’s knowledge into this failure branch.
Context evidence
Employee view not consulted
Boundary gate
No channel auth; query not sent
Outcome review
No query / answer=null
The context-gate regression finished
Strict query withholding is preserved; no actual DoT handshake or fallback timing was measured. Do not conceal unavailable resolution by changing the protection profile.
Context evidence
Employee view not consulted
Boundary gate
No channel auth; query not sent
Outcome review
Strict boundary preserved; no answer

ASSUMPTION · BOUNDARY · CONTROL

Broken assumption: one IP means one origin

An application substituting an IP address for URL origin can merge different hosts on a shared endpoint into one trust scope. The necessary condition is losing scheme/host/port comparison. A shared IP describes network placement, not authorization.

The control is to keep URL/origin and application-resource boundaries explicit. A suffix or same-site result does not automatically widen origin equality.

Broken assumption: a resolver view is universal

An employee-view answer may differ from one available through a public resolver. Different query contexts can select different endpoints. Losing context or cache/view separation may cause wrong-address selection or unexpected outages, breaking the assumption of one universal answer per name.

Defensive review identifies resolver, view and query tuple. Having a DNS answer is not permission to bypass application policy; this lesson does not investigate views by querying external systems.

Broken assumption: encryption settles every trust decision

An encrypted channel can still connect to an incorrectly selected resolver, which sees the question and applies its policy. Mixing Strict Privacy requirements with silent cleartext fallback loses the selected protection level. Authentication context and fallback conditions are decisive.

The control is to record endpoint identity and profile choice and assess resolver transport separately from DNSSEC and application HTTPS identity. The unavailable-channel branch produces neither a query nor a successful answer.

Read every scenario without motion

URL boundary

The base origin was established
For base URL https://notes.example.org/book, the origin is https://notes.example.org and the effective port is 443. Changing the path to /other stays same-origin. Host or port changes affect other tuple components.
URL / view evidence
https / notes / 443
Scope comparison
No comparison
Endpoint evidence review
No evidence verdict
The scope matrix was compared again
The HTTPS api host and notes:8443 are cross-origin but same-site; HTTP notes is both cross-origin and schemeful cross-site. The selected org suffix rule is not a full PSL snapshot or ownership proof.
URL / view evidence
https / notes / 443
Scope comparison
Path / host / port / scheme separate
Endpoint evidence review
No evidence verdict
View and answer were labeled together
sharedAddress supplies sameAddress=true and sameOrigin=false. Address equality does not change the URL-matrix result.
URL / view evidence
sameAddress=true / origin=false
Scope comparison
Path / host / port / scheme separate
Endpoint evidence review
No evidence verdict
Channel outcome is separate evidence
public-doh and employee-dot assume warm authenticated channels. Strict-unavailable stops without a query; these supplied conditions do not measure DNSSEC validation or a new handshake.
URL / view evidence
sameAddress=true / origin=false
Scope comparison
Channel supplied / query withheld branch
Endpoint evidence review
No evidence verdict
The endpoint claim was not expanded
Selected IP, URL host, HTTP authority and tlsReferenceIdentity are separate fields. Preparing a DNS candidate proves no actual connection, certificate acceptance or body delivery.
URL / view evidence
sameAddress=true / origin=false
Scope comparison
Channel supplied / query withheld branch
Endpoint evidence review
UNKNOWN: connect/certificate
Regression preserved the distinctions
Shared addresses, split views and strict failure are separate ordinary/negative controls. Source identity, URL origin and DNS-transport scopes are evaluated without substituting one for another.
URL / view evidence
sameAddress=true / origin=false
Scope comparison
Channel supplied / query withheld branch
Endpoint evidence review
Scopes distinct; connect/certificate unknown

Resolver views

The base origin was established
For base URL https://notes.example.org/book, the origin is https://notes.example.org and the effective port is 443. Changing the path to /other stays same-origin. Host or port changes affect other tuple components.
URL / view evidence
https / notes / 443
Scope comparison
No comparison
Endpoint evidence review
No evidence verdict
The scope matrix was compared again
The HTTPS api host and notes:8443 are cross-origin but same-site; HTTP notes is both cross-origin and schemeful cross-site. The selected org suffix rule is not a full PSL snapshot or ownership proof.
URL / view evidence
https / notes / 443
Scope comparison
Path / host / port / scheme separate
Endpoint evidence review
No evidence verdict
View and answer were labeled together
public/employee give .200/.40 for the same notes.example.org. A question. Without resolver view and cache context, the difference is not classified as a wrong answer or malicious change.
URL / view evidence
public .200 / employee .40
Scope comparison
Path / host / port / scheme separate
Endpoint evidence review
No evidence verdict
Channel outcome is separate evidence
public-doh and employee-dot assume warm authenticated channels. Strict-unavailable stops without a query; these supplied conditions do not measure DNSSEC validation or a new handshake.
URL / view evidence
public .200 / employee .40
Scope comparison
Channel supplied / query withheld branch
Endpoint evidence review
No evidence verdict
The endpoint claim was not expanded
Selected IP, URL host, HTTP authority and tlsReferenceIdentity are separate fields. Preparing a DNS candidate proves no actual connection, certificate acceptance or body delivery.
URL / view evidence
public .200 / employee .40
Scope comparison
Channel supplied / query withheld branch
Endpoint evidence review
UNKNOWN: connect/certificate
Regression preserved the distinctions
Shared addresses, split views and strict failure are separate ordinary/negative controls. Source identity, URL origin and DNS-transport scopes are evaluated without substituting one for another.
URL / view evidence
public .200 / employee .40
Scope comparison
Channel supplied / query withheld branch
Endpoint evidence review
Scopes distinct; connect/certificate unknown

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Compute the boundary matrix from URLs

Compare scheme, host and effective port for every artifact URL. /book and /other are same-origin; the api host and port 8443 are cross-origin while remaining in the HTTPS site group. Changing to HTTP also changes the schemeful-site group.

State the selected org suffix rule first. Actual product checks require an appropriately maintained PSL-aware library. Do not present this artifact as a full parser, registration check or test of DNS existence.

Read resolver and channel context together

Public DoH and employee DoT branches use the same name/type with different view and transport contexts. Record selected resolver, authentication condition, cache/view scope and plaintext-fallback decision separately.

In the strict-unavailable branch the client stops before sending a query. Warm channels in normal branches are selected conditions allowing reuse, not measurements of a real product’s connection-reuse behavior.

Preserve the boundary after DNS resolution

After selecting an IP candidate, preserve URL host, HTTPS reference identity and HTTP authority. Distinguish resolution, a reachable connection, accepted server identity and an application response as separate evidence.

Use shared-IP, different-origin and split-view cases in local regression comparisons. The scene ends with DNS exchange and local candidate preparation; it does not send decorative traffic to a server to imply unobserved HTTPS success.

NOW APPLY IT TO THE CASE

Which decisions are not shared by origin, resolver view and encrypted channel?

notes and api can share an IP address while retaining different origins. Public and employee resolver views may select different addresses for the same name. The DoT Strict Privacy example stops before sending a query when its channel is unavailable.

Does a DNS answer establish the case’s correct book result? Separate the end of name-resolution knowledge from the start of HTTP and application observations.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

URL, view and endpoint boundary matrix

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "suffixContext": {
    "selectedRule": "org",
    "ruleKind": "single-educational-rule-not-full-PSL-snapshot",
    "host": "notes.example.org",
    "publicSuffix": "org",
    "registrableDomain": "example.org",
    "pslProvesOwnership": false
  },
  "baseUrl": "https://notes.example.org/book",
  "urlCases": [
    {
      "url": "https://notes.example.org/book",
      "scheme": "https",
      "host": "notes.example.org",
      "effectivePort": 443,
      "origin": "https://notes.example.org",
      "site": "https://example.org",
      "sameOriginAsBase": true,
      "sameSiteAsBase": true
    },
    {
      "url": "https://notes.example.org/other",
      "scheme": "https",
      "host": "notes.example.org",
      "effectivePort": 443,
      "origin": "https://notes.example.org",
      "site": "https://example.org",
      "sameOriginAsBase": true,
      "sameSiteAsBase": true
    },
    {
      "url": "https://api.example.org/book",
      "scheme": "https",
      "host": "api.example.org",
      "effectivePort": 443,
      "origin": "https://api.example.org",
      "site": "https://example.org",
      "sameOriginAsBase": false,
      "sameSiteAsBase": true
    },
    {
      "url": "https://notes.example.org:8443/book",
      "scheme": "https",
      "host": "notes.example.org",
      "effectivePort": 8443,
      "origin": "https://notes.example.org:8443",
      "site": "https://example.org",
      "sameOriginAsBase": false,
      "sameSiteAsBase": true
    },
    {
      "url": "http://notes.example.org/book",
      "scheme": "http",
      "host": "notes.example.org",
      "effectivePort": 80,
      "origin": "http://notes.example.org",
      "site": "http://example.org",
      "sameOriginAsBase": false,
      "sameSiteAsBase": false
    }
  ],
  "views": [
    {
      "view": "public",
      "qname": "notes.example.org.",
      "qtype": "A",
      "answer": "198.51.100.200",
      "ttl": 120
    },
    {
      "view": "employee",
      "qname": "notes.example.org.",
      "qtype": "A",
      "answer": "192.0.2.40",
      "ttl": 120
    }
  ],
  "transportCases": [
    {
      "name": "public-doh",
      "kind": "DoH",
      "endpoint": "https://resolver.example.org/dns-query",
      "bootstrap": "selected-address-and-authentication-context-preconfigured",
      "channelAlreadyEstablished": true,
      "serverAuthenticated": true,
      "dnsQuestionVisibleToResolver": true,
      "dnssecValidationClaimed": false
    },
    {
      "name": "employee-dot",
      "kind": "DoT",
      "endpointHost": "resolver.example.org",
      "effectivePort": 853,
      "underlyingTransport": "TCP",
      "profile": "Strict Privacy",
      "channelAlreadyEstablished": true,
      "serverAuthenticated": true,
      "dnsQuestionVisibleToResolver": true,
      "dnssecValidationClaimed": false
    },
    {
      "name": "strict-unavailable",
      "kind": "DoT",
      "profile": "Strict Privacy",
      "channelAlreadyEstablished": false,
      "serverAuthenticated": false,
      "fallbackToCleartextForThisQuery": false,
      "dnsQuerySent": false,
      "answer": null
    }
  ],
  "endpointContext": {
    "urlHost": "notes.example.org",
    "selectedPublicAddress": "198.51.100.200",
    "selectedEmployeeAddress": "192.0.2.40",
    "httpAuthority": "notes.example.org",
    "tlsReferenceIdentity": "notes.example.org",
    "selectedAddressIsProofOfBackendOrTenant": false,
    "actualConnectOrCertificateCheck": "not-executed"
  },
  "sharedAddress": {
    "hosts": [
      "notes.example.org",
      "api.example.org"
    ],
    "address": "198.51.100.200",
    "sameAddress": true,
    "sameOrigin": false,
    "records": [
      {
        "owner": "notes.example.org.",
        "type": "A",
        "address": "198.51.100.200"
      },
      {
        "owner": "api.example.org.",
        "type": "A",
        "address": "198.51.100.200"
      }
    ]
  }
}

suffixContext: Selected org educational rule, not a full PSL snapshot.
urlCases: Origin and schemeful-site comparisons for ordinary HTTP(S) URLs.
views: Two selected view answers for the same query.
transportCases: Warm authenticated DoH/DoT conditions and strict-unavailable boundary.
endpointContext: A DNS candidate address is not proof of URL host, authority or identity.

Uses documentation addresses and reserved domains. No DNS/TLS/HTTP is executed; full PSL, IDNA, opaque origins, IP hosts and actual resolver-cache behavior are outside this matrix.

Two reality checks

The same registrable domain or IP means the same origin.

An ordinary URL origin depends on scheme/host/port. Same-site, shared IP and DNS authority are different comparisons.

With DoH/DoT even the resolver cannot see the question.

The selected resolver processes the question. Encryption protects the client–resolver hop; downstream paths, DNSSEC and application-server identity are separate scopes.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Do the base URL and https://notes.example.org:8443/book share an origin?

No; the port differs, while the selected schemeful site matches.
Yes; the same hostname makes all ports one origin.

Read the explained answer

No; the port differs, while the selected schemeful site matches. — 443 and 8443 distinguish origins; the same scheme and registrable domain preserve the site match.

What does the Strict Privacy DoT unavailable record show?

Selected lesson artifact fields; teaching example

transportCases[2]: {"name":"strict-unavailable","kind":"DoT","profile":"Strict Privacy","channelAlreadyEstablished":false,"serverAuthenticated":false,"fallbackToCleartextForThisQuery":false,"dnsQuerySent":false,"answer":null}

This query is not sent; this profile has no cleartext fallback.
Without TLS, the same query is automatically sent in cleartext.

Read the explained answer

This query is not sent; this profile has no cleartext fallback. — channelAlreadyEstablished=false and dnsQuerySent=false; the failure produces no address answer.

Public and employee views return different IPs. Why can TLS reference identity and backend/tenant evidence not be reduced to the IP?

Read the explained answer

The DNS view selects an endpoint address; the URL host notes.example.org remains the reference for service identity. A selected address does not prove backend or tenant ownership. Certificate/name validation and application permission remain separate; actualConnectOrCertificateCheck was not executed in this example.

□ I separated the view address from service identity.

□ I did not infer tenant/backend guarantees from an IP.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 9499 — DNS Terminology6 DNS servers and clients; split DNS · 9 Registration model; public suffix
Public Suffix List — Learn about the listDefinition of public suffix; uses of the list · Dangers of a static list; not a domain-validity test
WHATWG URL — Host miscellaneous3.2 Host miscellaneous; public suffix and registrable domain algorithms
WHATWG HTML — Origins and sites7.1.1 Origins; same origin · 7.1.1.1 Sites; obtain a site; same site
RFC 8484 — DNS Queries over HTTPS1 Introduction; 4 The HTTP Exchange · 9 Security Considerations; 10 Operational Considerations; bootstrapping
RFC 7858 — Specification for DNS over Transport Layer Security3.1 Establishing Connections; 3.2 TLS Handshake and Authentication · 3.4 Connection Reuse, Close, and Reestablishment
RFC 8310 — Usage Profiles for DNS over TLS and DNS over DTLS5 Usage Profiles; 5.1 DNS Resolution · 6.6 Authentication in Strict Privacy; 7.1 Full Direct Configuration
RFC 9110 — HTTP Semantics4.2.2 https URI Scheme; 4.3.4 HTTPS Certificate Verification · 7.2 Host and :authority; 7.3 Routing Inbound Requests
RFC 2606 — Reserved Top Level DNS Names3 Reserved Example Second Level Domain Names
RFC 5737 — IPv4 Address Blocks Reserved for Documentation3 Documentation Address Blocks

YOUR NOTES / THIS BROWSER

Domain boundaries and resolver choices

1. Core · Mechanism

Public view / DoH

Employee view / DoT strict

Shared IP, different origin

Strict channel unavailable

A public suffix is not simply the last label

Domain, site and origin answer different questions

Split-horizon: the same query with another selected view

DoH and DoT can carry the same query differently

The encrypted hop’s peer still sees the question

DNS selects an address, not proof of backend identity

2. Red · Trust & Impact

Shared IP

Strict unavailable

Broken assumption: one IP means one origin

Broken assumption: a resolver view is universal

Broken assumption: encryption settles every trust decision

3. Blue · Secure development & defense

URL boundary

Resolver views

Compute the boundary matrix from URLs

Read resolver and channel context together

Preserve the boundary after DNS resolution

Which decisions are not shared by origin, resolver view and encrypted channel?

Two reality checks

Do the base URL and https://notes.example.org:8443/book share an origin?

What does the Strict Privacy DoT unavailable record show?

Public and employee views return different IPs. Why can TLS reference identity and backend/tenant evidence not be reduced to the IP?

Sources and scope