On Sun, Mar 24, 2019 at 06:45:31PM +0100, manu tman wrote: > Thanks Ilari, > > > > 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. > > > > > I heard this idea twice today, and it sounds interesting. > >From what I gather from Paul Wouters is that not all registrars may accept > unknown algorithms as well as they would validate that the DS is valid by > checking the presence of the DNSKEY in the child. > This would seem to be the biggest hurdle.
Well, a new RRtype definitely would not work with unmodified nameservers, since it has magic properties (it is on parent side of zone cut without being glue). > > 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. > > > > If CDS works, then it should be fine right? Well, unless there are multiple provoders used at once, which happens sometimes. Or self-hosted DNS with cloud secondary. > > 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. > > > > yeah, this would be a problem, even more if using multiple providers. On > the other hand, the NS selection heuristic should probably prefer a DoT > nameserver over one that does not support it when possible. DNS is not exactly delay-tolerant, so one wants to minimize timeouts and probing (unless said probing can be parallelized). > > 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. > > > > I am not sure I am fully grasping this fully. Mind sharing a bit more? Something of style: example.org. IN DS 0 137 2 <direct sha256 SPKI#1> example.org. IN DS 0 137 42 <ns1.cloud1.example> example.org. IN DS 0 137 42 <ns3.cloud2.example> ns1.cloud1.example. IN IDK 2 <direct sha256 SPKI#2> ns3.cloud2.example. IN IDK 2 <direct sha256 SPKI#3> ns3.cloud2.example. IN IDK 2 <direct sha256 SPKI#4> This gives four keys, presumably first is for self-hosted, the second is for first cloud provoder, and last two are for second cloud provoder that is rolling over its keys. -Ilari _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
