4.4 Scope Routing

5 min read

PSPU §6.7 gives the routing order. resolvd applies it to each candidate separately, when the candidate is first asked, and the candidate's retries stay with the scope it chose.

The server-availability exclusions below describe source b4f7085. They differ from PSPU's definition of up. The proposed correction is summarised after the historical exclusive-scope case.

4.4.1 Which scopes take part #

Only routable scopes (§1.3) take part: those that are up — at level link or better (PSPU §6.2) — and have at least one server. An up scope with no servers is skipped at every step: it is never chosen, it never wins a tie, and its flags have no effect on routing. The same set decides which search domains apply (§4.3).

4.4.2 The steps #

  1. Exclusive. The routable scopes that are exclusive and at level addressed or better. The one with the lowest metric takes the candidate; among equal metrics, the first in snapshot order.
  2. Search domain. Among the routable scopes, every search domain the candidate equals or ends with, compared label by label and case-insensitively. The scope holding the matching domain with the most labels takes the candidate.
  3. Reverse subnet. When the candidate is a reverse-mapping name (§4.2), the routable scopes that hold an address of the same family whose prefix contains the named address; a prefix length beyond the family's width counts as the full width. The lowest metric wins, then the earliest.
  4. Default route. The routable scopes with default_route set. The lowest metric wins, then the earliest.
  5. Lowest metric. Otherwise, the routable scope with the lowest metric, then the earliest. This step is reached whenever no routable scope claims the default route — including when the only claimant has no servers.
  6. Fallback. When there are no routable scopes at all, the fallback scope, provided FallbackServers names at least one server. Its scope key is fallback.

When none of the steps yields a scope, the candidate is unavailable without a query (§4.1).

4.4.2.1 An exclusive scope that does not qualify #

An exclusive scope at level link, or one with no servers, is not exclusive for routing, and routing continues with step 2. The first takes part in the later steps as an ordinary scope; the second, not being routable, in none of them.

4.4.2.2 Proposed serverless-scope correction #

The proposed source correction treats level link or better as up, independently of DNS servers:

  • Steps 1–4 consider up scopes even when their server lists are empty. Exclusive selection still requires addressed or better. Domain, subnet, metric and snapshot-order rules are unchanged.
  • When one of those steps selects a scope without servers and upstream work is needed, the candidate is unavailable without a query. It does not fall through to another interface or the fallback scope.
  • Step 5 is reached only when earlier steps select no scope. This ordinary lowest-metric choice still requires an up scope with servers. A serverless default-route claimant therefore blocks step 5, while a serverless scope that matches no earlier rule does not block it.
  • Fallback is considered only if no earlier step selects a scope and no up scope has servers. A serverless winner at an earlier step blocks fallback too.

An exclusive scope at link alone still does not qualify for step 1; it can participate in later steps as an ordinary up scope. Synthetic answers and the selected scope's cache retain their existing precedence; this correction does not change cache invalidation or retry policy. These are proposed source semantics, not a released-package or installed-resolver guarantee. Check the installed source revision.

4.4.2.3 Ties between search domains #

Between matching domains with the same number of labels, the one in the scope with the lower metric wins. With equal metrics too, the first match found wins: the earlier scope in snapshot order, and within one scope the earlier domain.

4.4.3 Consequences #

4.4.3.1 Step 1 takes every candidate #

Step 1 is absolute while it applies: with an exclusive scope chosen, every candidate goes to it, whatever its name, and step 2 never runs.

4.4.3.2 Search domains beat the subnet rule #

Step 2 runs before steps 3 and 4, so a scope whose search domain is in-addr.arpa or 10.in-addr.arpa takes reverse names ahead of the subnet rule.

4.4.3.3 Fallback servers are a last resort #

Fallback servers are used only while no scope is routable. As soon as one scope at link or better has a server, the fallback scope takes nothing. Answers cached through it are then not consulted, and stay in the cache until they are flushed, overwritten or evicted (§4.5).

4.4.3.4 A candidate asks only its own scope's servers #

Every attempt for a candidate, and the TCP retry after a truncated reply, goes to a server of the one scope the candidate was routed to. When those attempts fail, the candidate is unavailable (§4.6); the servers of other scopes, and the fallback servers, are not asked for it.

4.4.3.5 Demotion does not affect routing #

Routing reads only the current scope list. Which servers are demoted has no effect on which scope a candidate goes to: a scope whose every server is demoted still takes the candidates routing gives it.

Edit this page