On Fri, Oct 12, 2018 at 12:56 AM Tony Finch <[email protected]> wrote:

> Apart from the basic mechanics that we have already mentioned, I think the
> interesting question here is how to manage scalability to lots of zones: if
> we publish encryption/authentication information about nameservers in the
> DNS:
>
> * is it published per server, associated with the server’s canonical name?
>
> * what about in-bailiwick aliases?
>
> * how important is it to avoid replicating this information in every zone
> hosted on the server?
>
> * does it help to use the reverse DNS instead?
>
>
>
I think, from the perspective of authority operators, the main issues have
to do with scaling, which fundamentally correlates to amortizing work,
minimizing work, and constraining work and state.

Scaling authority servers will canonically mean anycast, so the identical
IP addresses may be reached at multiple topological locations. Probably not
a significant issue.

The biggest work involved in any encrypted transport is the set-up (the
heavy part of the crypto). After set-up, my understanding is the
encryption/decryption has a symmetric cost which is generally some fixed
(linear) factor over the data volume (e.g. 4 cpu cycles per byte).

So, the things any design should optimize for, IMHO, are things that
minimize set-up. Session re-use is a big win. The ability for malicious
parties to trigger set-up work is a big loss, so I think some manner of
recursive (client) authentication to authority servers may be needed.

It is possible that a many-to-one relationship between anycast IPs (and
corresponding names) and physical servers might exist; on the authority
server side, TLS certs with Subject Alternative Names would further help
things, provided the resolvers (clients) are able to do session resumption
to the same cert, even if it is on different IPs.

I think the main take-away is transport channels as the unit component,
rather than individual messages, needs to be the starting point.

And I think the TLS certificate is probably going to be the primary
identifier for an authority server, regardless of NS names, IPs, or zones
served.

I'm not 100% certain this requires publishing encryption/authentication
information in DNS.

Brian
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to