Re: [dns-privacy] It's DNS Jim....

[manu tman <[e-mail]>]

On Thu, Dec 20, 2018 at 1:20 AM Ralf Weber <[e-mail]> 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