On Sat, Mar 23, 2019 at 12:58:46AM +0000, Reed, Jon wrote: > I’m glad to see this proposal, I find it personally preferable to the > dnscurve-esque proposal with the base32-encoded NS names. In both > cases, however, the examples assume that the nameservers are in > bailiwick for the zone. This is not going to be true for any side > using a cloud authoritative DNS provider, which is fine. > > However, I also think it should be possible for cloud providers to > offer DoT transparently, without customers needing to opt-in. > (I’m open to rebuttals to that, but I don’t see any obvious > drawbacks.) I’d like to see the ability to scale either of these > proposals to cloud services, but I’m not quite sure how that would > work. > > Consider the following delegation from the gTLD servers: > > example.com 3600 IN NS ns1.clouddnsprovider.com > example.com 3600 IN NS ns2.clouddnsprovider.com > > Now, under the clouddnsprovider.com zone, the provider can create the > necessary DSPKI or base32-encoded NS records for > “clouddnsprovider.com” in the gTLDs. But under my reading of this > proposal, that means DOT would only be used to look up names under > “clouddnsprovider.com”, not “example.com”. But, the recursive > _knows_ that ns1.clouddnsprovider.com is capable of doing DoT > (assuming TLS negotiation was successful). Therefore, I think it > should be able to use DoT to lookup names under example.com (or > indeed, under any domain which has the same (ns name, address) tuple. > I’d like to see this use case explicitly addressed in the text of the > draft.
This proposal actually reminds me a lot of idea I had that actually used DS records instead of new record type. AFAIK: - DNSsec ignores any such record (unknown algorithm) -> No interference with DNSsec. - CDS does not ignore such records. -> Automated synchnonization. - Lives on parent side of delegation. -> No post-hoc authentication. The problem that idea ran into was actually the same: If DNS is outsourced to some external provoder (which is actually very common), then key rotations need two parties to coordinate, which is a nasty problem. And then there is issue that not all nameservers for zone might have DoT support, and in that case, one would have to discover which ones do. And NS records might not be signed, so one can not rely on those. The unreliability of NS pretty much means that unless all nameservers support DoT, one has to duplicate nameservers into signed records. And that might be multiple repetitions, which are not compressable, since DS is not magic that way (even if it is magic due to where it lives). Also, writing the nameserver name into DS record is not exactly pleasant (as the field is hex-encoded). One hack upon hack would be to have second key type be indirect reference, which would then be looked up using new RRtype at the target name. This would allow "cloud" case to work without annoying coordination problems. -Ilari _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
