On Thu, Dec 20, 2018 at 1:20 AM Ralf Weber <[email protected]> wrote: > > > > Now onto delegation, we have a clear way of delegating information down > the tree to a different entity. All the information needed is handed > down from the parent (NS and Glue for DNS plus DS for DNSSEC). This > seems to be the natural place to put information about enrypted DNS > (maybe TNS, Glue and TDS or something for keys), and while I worked with > software that encoded key material in name server names I don’t think > it will fly as people want to name their name servers. >
Thanks Ralph, I do also see the parent as the right place to put that information and had started to write a draft [0] but completely dropped the ball there. This also comes with its own drawbacks though, be it to have support in the parents for one (e.g *TLDs) but then we could also foresee handling update of such RRType straight from the child using something similar to CDS? That being said, I heard both positive and negative feedbacks on this solution. And hence during IETF 103 hackathon I implemented a PoC for encoding the cert hash in the name. Which too is coming with its own pros and cons. Realistically, there will not be a magic solution which will be perfect, any solution will come with trade-offs and those trade-offs are differents depending on which side of the fence one stands. At least, it seems constructive discussions/suggestions are emerging from the DPRIVE virtual meeting, and it becomes clearer as to what different organizations are seeing as operational issues/burdens. Manu [0] https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-00
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
