Subject: Re: [dns-privacy] Authoritative Server Operator Perspective

From: "Henderson, Karl" <[email-masked]>
Date: Fri, 2 Nov 2018 03:28:37 +0000

Authoritative name servers affect users in ways they cannot avoid or work around, so the primary concern for operators of authoritative name servers when considering changes to the DNS protocol or transport must be to weigh operational risk to availability.  Standards developers should assess whether adding a feature to the protocol or transport introduces a significant attack vector that increases the risk of attacks against the name servers (principally DDoS, which is the most prominent risk, but other vectors warrant concern).  

The DPRIVE charter [1] makes an important observation regarding the question of DNS encryption at the authoritative name server: "There are numerous aspects that differ between DNS exchanges with an iterative resolver and exchanges involving DNS root/authoritative servers."

As Bert Hubert so eloquently put it in his "DNS Camel" talk to the DNSOP working group and subsequent blog post earlier this year [2]: ".with the rise in complexity and the decrease in the number of capable contributors, the inevitable result is a drop in quality."

These points suggest a need for a profile of encryption standards that sufficiently mitigates operational risk to authoritative name servers while protecting end user privacy.

[1] https://datatracker.ietf.org/doc/charter-ietf-dprive/

[2] https://blog.apnic.net/2018/03/29/the-dns-camel/

---

From: Brian Dickson <[email-masked]>
Date: Mon, 5 Nov 2018 18:25:40 +0700

On Fri, Oct 12, 2018 at 12:56 AM Tony Finch <[email-masked]> 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