On Thu, Sep 24, 2020 at 10:58 AM Peter van Dijk <peter.van.d...@powerdns.com> wrote:
> Hello dnsop, > > early 2019, Manu of Facebook proposed the DSPKI record - a parent-side- > of-the-delegation record to hold a pin for authenticating child-side > DoT servers. This would be undeployable. > > A few months ago, Tim April proposed NS2/NS2T, which looks like it > would clearly benefit from the ability to publish signed data on the > parent side of a delegation. This ability seems unlikely today. > > Also a few months ago, myself and a few others proposed shoehorning > certificate hashes into the DS record. The shoehorning (and perhaps > some other aspects of that proposal) were not well received by > everybody. > > When talking to Petr Spacek about this, he came up with the following: > -if-, long enough ago, besides DS, a range of RRtype numbers would have > been reserved with the same processing rules, i.e. these types live in > the -parent- and not on the -child-, then both DSPKI and NS2T could > become parent side records through the simple act of requesting an > IANA allocation from that special range. > > Sadly, it is not five years ago today. It is today today. So, here is a > draft that requests that IANA reserves such a range. Knowledge of that > range and its DS-like handling can then end up in implementations over > time. When that has happened at some useful scale, we could do a DSPKI > experiment. NS2T could explore what benefits come from the ability to > publish in the parent. And, nobody will have to shoehorn hashed TLS > certificates into DS records. > > This draft is a bit rough; I trust it, and this email, have brought the > idea across. Editorial comments are welcome via GitHub (link is in the > draft), or via the WG of course. > > Looking forward to your thoughts on this. > The motivating use cases to justify this, were flawed in a number of ways. One of those (IMHO, the biggest flaw) was that the pertinent information in question was often an attribute of the name server serving the zone, rather than a zone attribute. And, for reasons very similar to the problems in the recent draft on publishing information on the authority servers in their zone (draft-pp-dnsop-authinfo), there are problems in the mapping relationship from zones to nameserver IPs to physical servers. These schemes only work under a small subset of conditions, and as such, are not useful as a standardized method. The simplest scenario for a zone, is where the zone is managed by the domain owner, served only on name servers run by the domain owner, with name server names which are exclusively in the domain in question. Any situation that does not fall into that scheme, not only won't work, but would impose significant operational challenges in attempting to maintain the suggested scheme. This doesn't even address the significant challenges of developing a method of passing the information from the domain owner (registrant) to the parent name server (registry). The current mechanism of EPP, does not even accommodate the DNS operator unless the DNS operator is also the registrar. This doesn't mean that there isn't interest in some of the related problems, only that the solutions that have been discussed, including this one, either won't work, won't scale, or can't be deployed. The lack of a dedicated RRTYPEs for the parent side is thus a moot problem. I concur with Paul Wouters that these would also be particularly dangerous and problematic. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
