At Wed, 15 Apr 2015 09:08:44 -0400,
Warren Kumari <[email protected]> wrote:

> For *each* of the below documents, please **clearly** state if you
> would like DPRIVE to adopt it, or if you think that it will be a
> distraction / not helpful.
>
> 1) Confidential DNS:
> https://datatracker.ietf.org/doc/draft-wijngaards-dnsop-confidentialdns/
>
> 2) Private-DNS: https://datatracker.ietf.org/doc/draft-hallambaker-privatedns/
>
> 3) TLS for DNS: Initiation and Performance Considerations:
> http://datatracker.ietf.org/doc/draft-hzhwm-dprive-start-tls-for-dns/

I'd like DPRIVE to adopt #2 and #3.  I don't think DRIVE has to adopt
#1.

I think #3 is the most promising approach in terms of deployability.
Using TLS for this purpose may not look elegant, but on the other hand
we have a lot of experience with it and development tools to make the
implementation efforts less difficult.  I also don't believe in
clean slate approaches, especially for anything related to legacy
technologies such as DNS.  While it's true that we'll need to modify
both the server and client in a non-trivial manner, I believe we
shouldn't underestimate the deployment cost of clean slate approaches.

The biggest obvious concern with the TLS approach is that it doesn't
work for UDP.  I agree that this has to be able to be usable by
default in a very busy environment such as a large ISP that provides
millions of subscribers with a recursive DNS service.  We'll need more
analysis and experiments, and the latter should be conducted for more
harsh environments than a research network.  I hope these data points
will be provided as we discuss protocol details in this wg, and,
hopefully, the result will be acceptable.

But it's also possible that it turns out that we cannot just rely on
TCP in the end.  So I think we'll need to discuss at least one other
approach that allows the use of UDP, i.e, #1 or #2.  I don't have a
strong preference between these two, but #1 seems to me rather ad hoc
while it's essentially closer to a clean slate approach (it seems to
me a totally new protocol except that it still uses DNS message
formats).  If our conclusion is that we need something really new, I'd
keep the DNS protocol less messy.  (There might be other approaches
that allow the use of UDP, but I'm assuming we don't go back to
exploring those other solutions at this stage).

--
JINMEI, Tatuya

_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to