On Wed, 2020-11-11 at 19:07 +0000, Tony Finch wrote:
>
> * Encryption would apply to the server as a whole, whereas the
> working group consensus is that it should be possible for
> different zones on the same server to use encrypted and
> unencrypted transports.
(plus, in another email, Tony wrote: "A nice thing about TLSA records
is they also tell the client what name to look for in the server's
cert.")
This looks like a mistake to me, or at least, a choice that would have
to be made very deliberately.
Today, the name through which I reach an NS does not matter - it is not
part of the protocol exchange like the HTTP Host header is. This
simplifies a lot of things, and allows some leeway for mismatches in
names between parents, childs, etc., as long as they reach the same IP.
It also seems that any 'split' between which zones on a certain IP
support encryption and which zones do not, would make any opportunistic
proposal obsolete immediately.
I'd like to assume that all transports offered by an NS host the ~same
data (ignoring, for a moment, that we might one day imagine data that
should only be seen over transports with certain security properties,
but I'm imagining that such data would not cover whole zones).
In fact, it would be good if I don't assume. Instead, we should
actively decide whether any such splits are allowed, or forbidden.
I note that the phase2 doc has this text:
9. A given name server may be authoritative for multiple zones. As
such, a name server MAY support use of a secure transport
protocol for one zone, but not for another.
So in fact, right now we have written down that this is allowed. But I
think it is a mistake.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
