Dear TF members, Here are the minutes from our first call. Cheers, Boris *** Wednesday, 8 March 2023 18:00 (UTC+1) Attendees: Farzaneh Badii, Marco Davids, Paul Ebersman, Gaurav Kansal, Shane Kerr, Tim Wicinski, János Zsakó Scribe: Boris Duval 1. Welcome and Administrivia Shane welcomed everyone to the meeting and acknowledged that the task force had a slow start but hoped that they would now pick up pace and have a draft ready for RIPE 86. He also announced that Tim agreed to co-chair the task force with him, and that Boris will be taking minutes. 2. Finalising the Task Force’s Charter Shane asked if anyone had any comments or concerns about the latest version of the charter that was shared via the mailing list. As there were no comments, the final version of the charter was approved and was updated on the website. 3. How to Get Things Done Shane proposed using the public mailing list for official discussions and private channels such as Mattermost for other types of discussions to spare the list all the logistical details. Marco pointed out that it would be better not to share the Zoom links via the mailing list for security reasons. Shane proposed to use GitHub to work on the document. The task force agreed. 4. Target Audience and Scope The task force discussed the target audience and scope of the document. Shane reminded the task force that the main reason for the paper was that the EU was concerned about the centralisation of Internet services, mainly by US companies, and wanted to see these services managed by more European operators. Shane suggested that the document should target organisations based in Europe who want to be responsible public resolver operators. However, he also mentioned that it might be too narrow, and that the task force might also want to consider enterprises, governments, academic institutions and others who want to run public resolvers. Shane proposed to clarify who the document is for, asking whether it should be for anyone who operates a resolver or just for those who operate a public resolver. He also suggested that the task force consider the different relationships between the resolver operator and the users, such as ones completely anonymous, ones where you need an account and ones where it is for employees or students at a university. The task force proposed to divide the scope of the document and to draft it for public resolver operators as well as for closed user groups such as universities or governments. Farzaneh said that she would like to launch a collective action with public resolvers set up by non-for-profit organisations such as CCTLDs to help solve the consolidation problem. She mentioned that the role of the task force was to come up with best practices to help with encryption for example and provide non-for-profit organisations a more cost-effective way to run a public resolver. The task force also discussed the legal aspects of blocking content on public resolvers, citing the recent Quad 9 case as an example. Regarding this case, Farzaneh brought up concerns about intellectual property and blocking practices, noting that some public resolvers do not block unless legally mandated. János mentioned that he was not aware of any intention to block DNS in Hungary but noted that ISPs have an obligation to block certain IPs, which are proven by the court. Shane mentioned that the task force should not be afraid to take an opinionated approach to privacy issues and intellectual content blocking and come up with recommendations. He also added for transparency that his company was recently acquired by IBM, which is the number one sponsor of Quad 9. Tim nominated Farzaneh to lead the section on legal issues such as GDPR. Farzaneh accepted. 5. Terminology Shane briefly mentioned that he preferred the term "public resolver" to "open resolver", as the latter might have bad connotations from the days when you installed a Unix box and it had an open resolver by default. 6. Review of draft list of recommendation topics Shane shared a list of topics to be considered when writing the document. He also mentioned that he would encourage the use of existing work where relevant so as not to reinvent the wheel. a) Capacity Shane mentioned that in the DNS world, CPU and networking would be the two limiting factors and that memory will not be such an issue due to modern memory sizes. He also mentioned that it would be good to determine what to recommend for caching. For example, running each resolver separately to do its own caching, or using multilayer caching, etc. b) Resilience Shane mentioned that in terms of resilience, it will be good to consider what kind of DNS software is used, what are the physical locations, and where those sit on the network. He also noted that most people will not have their own data centres, with the possible exception of some ISPs, so some issues may be relevant to some user groups but not to others. He mentioned a lot of other factors that can influence resiliency such as peering, single transit network, legal frameworks and filtering. He mentioned that all of this can probably be found in existing documentation about security best practices and could be drawn upon to build this section about resilience. c) Anycasting Shane added anycasting to the list because it is the only tool that currently exists in DNS to distribute a geographic service, since everything is configured with an IP address. Marco proposed to write some lines about monitoring in the context of anycasting. Shane agreed and added that the task force should also address inefficient paths and other aspects of anycast monitoring. d) Software Consideration. Marco mentioned that it might be good to encourage the use of open source in the document and briefly discussed licensing. Shane agreed and mentioned that the task force should also consider addressing supporting software as well. e) Knobs to tweak in the DNS The task force discussed several points regarding various topics such as DNS over HTTPS (DoH) or DNS over TLS (DoT), platform diversity, CPU pinning, setting maximum and minimum TLDs, running a local TLD, certificate management, and other technical details. Shane mentions the possibility of making custom tweaks such as CPU pinning but was unsure if they were necessary. János suggested platform diversity as a means of increasing resilience and avoiding an entire system being taken down by a zero-day exploit. He also recommended running the service on different flavors of Linux and BSD to reduce risks. The issue of adding IP addresses to the X509 certificate of the DoH server, as observed in Cloudflare, was also raised. The task force discussed the importance of adding IP addresses to the certificate and the challenges they faced in doing so. There was also a discussion on setting maximum and minimum TLDs and the potential benefits of running a local TLD. 7. Next Meeting Shane thanked all participants and proposed to organise another meeting in a few weeks. He also indicated that in the meantime the task force can continue its work via GitHub and Mattermost.