Resolution latency is only affected initially when the resolver must fetch the confkey record, after that initial fetch (until TTL expires) there are no additional packets introduced into the query/response exchange.
Zone file size is not an issue - adding a single key record to support confidential operations is not likely to have a meaningful impact to zone file size based on the impact of DNSSEC adoption. If every name server adopted support for confidential DNS there would be an impact - this is an inevitable cost of adding a feature like this. Some of the additional considerations include performance impacts to large scale name servers (both recursive and authoritative). I agree that this has an impact to the DNS ecosystem, however I suspect that the impact is nearly as low as possible. An alternative such as implementing TLS would have a far more severe impact on the high volume name servers and would still require client side changes. On Nov 28, 2013, at 9:09 AM, Guangqing Deng wrote: > Though bringing privacy protection to the DNS query and response, this method > may bring many other negative impacts on DNS system. The DNS resolution > latency will be increased due to fetching so-called ENCRYPT RR which makes > the DNS zone file bigger. Not onlay the DNS server but also the DNS client > have to support encrypt algorithms, which is not a good thing for DNS system. > Maybe more considerations are needed to figure out what will happen if this > methood is choesn. > > Guangqing Deng > CNNIC > > From: W.C.A. Wijngaards > Date: 2013-11-28 21:25 > To: dnsop > Subject: [DNSOP] confidentialdns draft > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I also heard that this is the place to discuss DNS privacy. > > This draft is a protocol, and represents an (interesting) point in the > solution space. I would refer to Borzmeyer's draft and Koch's draft > for problem space analysis. > > http://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-00 > > It supports opportunistic encryption, i.e. try to encrypt but fallback > to insecure. This supports deployment immensely, because clean DNS > paths are uncommon. > > It supports stateless operation. It uses UDP. > > It supports encryption for stub-to-cache and cache-to-authority. > > Best regards, > Wouter > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSl0RiAAoJEJ9vHC1+BF+NbOcP/03f76fPIp8rkKtjYdjTHbZ7 > qoMFVsIbZ6GqoB77U2w2dtVEirfqLkcBQ5gE1LzLGL/AS4aKVBg7GLAY/qv1o+BM > YIvoecRd+P+/mzZZtROJbpe3Pp3ktsL9+A4SaChpWBWPR7qCUKGh2R0YWq6hHj0h > btIOFROGnt/QH0Pho7/0N9UfNBVlc6By8BSwON2kiR9bD+oyCDGxJQ85N03p8FJo > kVIZM6PtsUHQxhX4rhQec5t/LBu1oXVq5tdVSzjiIYZAcUI9lLfv7f7o1QccAIUF > YZ/u1OvIp3l6iKNK3eLrimXRu7dFR09aqUcbYD0LNci6g4AY0awPYk2TE5OtQ1Ll > SHpil/QzKA0V4QPANfZNBV/wL5SitnQuS6fLYkKnsjSED8AUINNLqYttSo+wPEMs > ReCPI51pyuvL0E/ZkfiKRsfb8qiuFh1OkCLFgJZMVzecLcOvrVfxxf4SNe8Z8i7F > IzSNikgqSzIK/hQSEMVjk9O+f97/muQw0fCiqGbIS9hUntEwJ90/Ji20dxlz2aj7 > V7nuC4wz53VWHtIYhiDMP2P9Twbh40TmdIf9yWFZzkayryBVwH5gTuU1ZqL2sVc6 > qMolnaKQdTFnM4jAMzfYBuHyUzFTRqG1u9IXLskmBl0tDAOH0cRV4bD6oH8BZd+X > v//pHQiVWuyMbndChPrm > =PdRr > -----END PGP SIGNATURE----- > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
