Subject: [dns-privacy] Amortization techniques for less popular name server names

From: Brian Dickson <[email-masked]>
Date: Sun, 15 Nov 2020 16:01:34 -0800

One issue that is likely to arise regardless of the specific technique used for signaling availability of ADoT is the cost differential between popular and less popular name servers (referring to number of zones and/or aggregate zone popularity).

It is clear that the costs to revolvers will be amortized significantly if those costs depend on that popularity.

I would like to offer some suggestions for techniques that may be able to improve the costs towards less popular name servers.

These are not the only viable methods, nor is it the case that such methods are for certain necessary. However, if there arises a need for such a solution, I think it could be useful to have a possible solution in advance to address that hypothetical need. I don’t mind spending this effort, and am not married to the idea. If it isn’t needed, or if other solutions work better, that’s great.

These suggestions are in part to generally improve performance of DNS generally and to support privacy as much as possible. It is also partly to mitigate any possible  perception that there is any intent to leverage market position to influence the ADoT standardization process. Any ADoT solution should be evaluated neutrally, on the basis of meeting requirements, especially on a scalability perspective. Choosing a solution that scales badly but does so equally, would be a bad outcome IMHO.

So, what possible techniques could improve scaling for less popular name servers?
That depends on what those costs are and what scaling attributes they have.
I believe that the main costs would be computational costs and latency.
Latency can potentially be addressed by considering when any queries that are required occur. Early cache population  (rather than “just in time”) can reduce or eliminate such latency. (This is the classic space vs time trade-off.) Also worth considering are methods that replace queries and caches with use of secondary server functionality (on resolvers in particular) and notifies zone transfers. These have the additional potential benefit of being TTL-agnostic: they are as “live” as low TTL records, but as stable and performant as long TTL records.

Attempting to do XFR for many name servers which are infrequently used would have scalability issues from any resolver, if the server names are in a large number of zones. One approach to reducing this issue is aggregating server names inside many fewer zones. Doing this aggregation creates trust issues, however. This trust issue can possibly be addressed by using multiple (but still many fewer) zones containing aggregated sets of name server names, operated by different parties, and possibly registered in different TLDs and served in different jurisdictions. The presumption is independent operation reduces the risks of collusion, the impacts of operator error, and the risk of legal issues causing operational problems.

This is not without operation complexity. For instance, if secondary service was used, the operators of the aggregating zones would likely need to find a way of managing the client base of resolvers, or of publishing information to allow clients to validate transferred zones themselves.

There would still be operational cost, particularly if signed zones meant individual records required validation. One possible method of reducing the need for validation of signed records retrieved by XFR is the use of ZONEMD. It might allow for deferred validation or no validation of individual records, depending on what the resolver operator considered acceptable. (The zone digest would still need to be calculated and verified, but that is likely much less expensive.)

The example set up would be something like:

DNS operator:
snowflake.example.org NS small-ns-operator.dns-cooperative-one.example.net

Aggregate operator:
dns-cooperative-one.example.net ZONEMD value
dns-cooperative-one.example.net DNSKEY value
small-ns-operator.dns-cooperative-one.example.net AAAA v6addr
privacy-thing.small-ns-operator.dns-cooperative-one.example.net TYPE value // eg TLSA record

ResolverX:
zone “ dns-cooperative-one.example.net” {
 type secondary;
 primary v6addr-of-primary;
 use-zonemd;
};

The end result in this example would be that ResolverX could have pre-populated ADoT info for rarely used nameservers, and be able to perform privacy-preserving queries to them with minimal incremental latency. (Establishing TLS session keys in advance would be one feasible way of speeding it up. Another would be maintaining open TLS sessions to every authority server, which might not be an available option depending on the policies of the authority server operators.)

Further scalability might be possible by using similar techniques such as catalog zones for publishing aggregator zones.

DNS software developers might ship example configs containing real aggregator zones to facilitate use of them.

The mutual benefit between small DNS authority operators and resolver operators would provide the incentives to set these up.

This is probably best discussed further in Tony Finch’s thread(s), or possibly at a later point if/when it becomes relevant.

Brian

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Nov 2020 01:28:40 +0000

Brian Dickson <[email-masked]> wrote:

> Attempting to do XFR for many name servers which are infrequently used
> would have scalability issues from any resolver, if the server names are
> in a large number of zones. One approach to reducing this issue is
> aggregating server names inside many fewer zones. Doing this aggregation
> creates trust issues, however.

Summarizing brutally :-) this sounds a bit like a combination between DLV
and hyperlocal root zones?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames, Dover: Southwest 5 to 7. Moderate or rough, occasionally slight later.
Rain or drizzle at first. Moderate or good, occasionally poor.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 16 Nov 2020 17:45:58 -0800

> and hyperlocal root zones?

Yes, exactly. (When I was writing it up, that thought even crossed my mind.)
The irony is not lost on me, either. :-)

Brian