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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
