Re: [dns-privacy] Authoritative Server Operator Perspective
Authoritative name servers affect users in ways they cannot avoid or work around, so the primary concern for operators of authoritative name servers when considering changes to the DNS protocol or transport must be to weigh operational risk to availability. Standards developers should assess whether adding a feature to the protocol or transport introduces a significant attack vector that increases the risk of attacks against the name servers (principally DDoS, which is the most prominent risk, but other vectors warrant concern). The DPRIVE charter [1] makes an important observation regarding the question of DNS encryption at the authoritative name server: "There are numerous aspects that differ between DNS exchanges with an iterative resolver and exchanges involving DNS root/authoritative servers." As Bert Hubert so eloquently put it in his "DNS Camel" talk to the DNSOP working group and subsequent blog post earlier this year [2]: ".with the rise in complexity and the decrease in the number of capable contributors, the inevitable result is a drop in quality." These points suggest a need for a profile of encryption standards that sufficiently mitigates operational risk to authoritative name servers while protecting end user privacy. [1] https://datatracker.ietf.org/doc/charter-ietf-dprive/ [2] https://blog.apnic.net/2018/03/29/the-dns-camel/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Authoritative Server Operator Perspective
On 10/11/18 1:56 PM, Tony Finch wrote: > Apart from the basic mechanics that we have already mentioned, I think the > interesting question here is how to manage scalability to lots of zones: if > we publish encryption/authentication information about nameservers in the DNS: > > * is it published per server, associated with the server’s canonical name? > > * what about in-bailiwick aliases? > > * how important is it to avoid replicating this information in every zone > hosted on the server? > > * does it help to use the reverse DNS instead? This question brings up a topic that would require a fair amount of interchange with DANE. What are the benefits/drawbacks of having DANE records in the reverse tree for each server? There are probably a myriad of issues to work through, but it looks like that would alleviate a fair amount of complexity at the zone level. Still need to think through the gory details... Brian signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Authoritative Server Operator Perspective
Apart from the basic mechanics that we have already mentioned, I think the interesting question here is how to manage scalability to lots of zones: if we publish encryption/authentication information about nameservers in the DNS: * is it published per server, associated with the server’s canonical name? * what about in-bailiwick aliases? * how important is it to avoid replicating this information in every zone hosted on the server? * does it help to use the reverse DNS instead? Tony. -- f.anthony.n.finchhttp://dotat.at ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Authoritative Server Operator Perspective
All, Sorry for the delay in getting this week's thread started. I would like the focus for this week (10/8-10/14) to be on clarifying the technical requirements from the authoritative server operator's perspective. This will encompass the technical issues for all servers responding to DNS queries (i.e., *LDs). Regards, Brian signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
