- dns-resolver-tf - mailman.ripe.net

Post-quantum crypto?
by Marco Davids (SIDN) 25 Oct '23

25 Oct '23

Hello Task Force, In our resolver testbed (https://dns4all.eu), we experimented a bit with PQC algo's: https://www.sidnlabs.nl/en/news-and-blogs/adding-experimental-support-for-x… And that made me wonder; would this be a topic to consider for the DNS Resolver Best Common Practice document? -- Marco Davids Research Engineer SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 00 | www.sidnlabs.nl | Twitter: @marcodavids https://mastodon.social/@marcodavids | Matrix: @marco:sidnlabs.nl Nostr: 11ed01ff277d94705c2931867b8d900d8bacce6f27aaf7440ce98bb50e02fb34

2 1

Encrypting Internet Infrastructure / A virtual session
by farzaneh badii 02 Oct '23

02 Oct '23

Hello Task Force, Thought you might be interested in this virtual session on encrypting Internet infrastructure: https://us06web.zoom.us/meeting/register/tZwucuCuqj0uH9R3SA06-PMooCJhcOnMsF… Best regards, Farzaneh

1 0

Draft Minutes - DNS Resolver Best Common Practice Task Force - 8 August 2023
by Boris Duval 24 Aug '23

24 Aug '23

Dear TF members, Here are the minutes from our seventh call. Cheers, Boris *** Tuesday, 8 August 2023 17:00 (UTC+2) Attendees: Marteen Aertsen, Shane Kerr, Andronikos Kyriakou, Tim Wicinski Scribe: Boris Duval 1. Recommended Knobs Settings The Task Force discussed recommendations for specific DNS settings: https://github.com/DNS-Resolver-BCP-TF/Resolver-Recommendations/issues/10 Here’s a summary: DNSSEC Validation: · Recommended enabling DNSSEC validation. · Negative caching (NSEC, NSEC3) reduces traffic, safeguards against random subdomain attacks (RFC 8198). · Root KSK update essential; RFC 5011 or resolver operator for updates via OS. · Valuable material in RFC9364 for DNSSEC operations. TTL Limits (max & min): · Software default TTL of 1-2 days; potential reduction for cache size. · Lower TTL removes infrequently-used records, minimal operational impact, memory savings. · Some implementations allow minimum TTL, though a DNS protocol violation. · Software can set differing max/min TTL, impacting queries. TTL Record Pre-fetch: · Certain resolvers prefetch records before cache expiration to extend TTL. · Feature not standardized; related proposal: https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-03 · Recommended enabling if available. Cache Saving: · Exploring downsides; input sought from implementors, DNS OARC list. Local Root (and maybe local TLD?): · Beneficial to use local root (RFC8806). · Not applicable to most TLDs due to frequent changes. Shane offered to develop these notes and come up with a first draft.

1 0

Task Force Status Update
by Shane Kerr 22 Aug '23

22 Aug '23

Hello to everyone interested in DNS Resolvers, We've been having regular weekly meetings to discuss our draft document, and some people have contributed excellent text for this, and the discussions have been good. We have more writing to do, but we are largely done with two main sections: systems/network/capacity and DNS knobs. At our next call we're going to review the work that Farzaneh has been doing, which should put us a lot further along with the privacy/filtering/transparency section. The remaining section is a list of other documents to reference. We intend to provide guidance, rather than just a list of things to read. Maarten will start that work by looking at the FIRST DNS stuff, but we should go through all of it. I think that we are in good shape to have a draft a month or so before the upcoming RIPE 87 meeting in Rome at the end of November 2023. That should give anyone in the RIPE community enough time to have a read and get back to us with whatever feedback they have before a final draft can be published. Since our Mattermost instance went away, we have been using the RIPE Forum for non-public communications - everyone on the task force should check it periodically. It's not quite as nice for real-time or near-real-time communication, but it is what we have. Cheers, -- Shane Chair, DNS Resolver Best Common Practice Task Force

1 0

Draft Minutes - DNS Resolver Best Common Practice Task Force - 18 July 2023
by Boris Duval 26 Jul '23

26 Jul '23

Dear TF members, Here are the minutes from our fifth call. Cheers, Boris *** Tuesday, 18 July 2023 17:00 (UTC+2) Attendees: Farzaneh Badii, Shane Kerr, Andronikos Kyriakou, János Zsakó Scribe: Boris Duval 1. Welcome and Administrivia Shane welcomed all participants and mentioned that he was pleased with the text written by Töma on the pros and cons of running DNS resolution software on bare servers or in the cloud. 2. GDPR Compliance Farzaneh said that she has been looking into the GDPR policy of 10 DNS resolvers based in Europe. She noted that some resolvers have strong policies, while others lack clarity, especially open DNS resolvers. She mentioned that she will be trying to set up interviews with some of those companies to try to better understand their policy as there is limited information available online. Shane agreed with Farzaneh’s approach and mentioned that interviews will be valuable but also time consuming. He also suggested looking outside European resolvers if possible, as it might be interesting to make comparisons. Andronikos shared a link (https://europeanresolverpolicy.com/) that provides guidelines on handling GDPR compliance but noted that it does not apply to major open resolvers. János pointed out that the relationship between the GDPR and IP addresses is tricky, as it will have to be demonstrated that IP addresses are personal data. He also pointed out that the possibility of asking one's data to be deleted (guaranteed under GDPR) would also pose a problem in the case of public resources. Farzaneh said she would try to meet Maarten in August to discuss the GDPR aspects of the text. Farzaneh also asked the task force if they knew of an authoritative list for DNS resolvers. Andronikos shared a list in the chat. 3. IP Blocking / Intellectual Property Farzaneh said she had recently met with policymakers and discussed the implications of IP blocking. She also mentioned the recent Quad 9 case, in which the company was sued by Sony and had to block websites as a result. She added that the other part of the issue was to talk about the implications of blocking websites at the DNS level and asking the resolver to do so. Shane suggested that the task force's only recommendation for operators should be to follow the law. Farzaneh proposed the inclusion of recommendations for transparency and third-party audits if DNS resolvers opt for a blocklist. Shane mentioned that Danish ISPs are required to support three blocklists: one governmental, one against child pornography operated by an NGO, and one run by ISPs. He acknowledged that expanding the scope might be necessary if deemed appropriate. János stated that IP-level blocking is more effective than DNS-level blocking in Hungary. Shane suggested the task force consider highlighting the alternative of recommending IP-level blocking, which may be more logical. Andronikos said that he was surprised about the prevalence of IP-level filtering in Hungary, as DNS filtering is more common in the countries his company operate in. He noted the industry's increasing trend towards DNS filtering despite its imperfections. Andronikos recommended against debating the pros and cons of DNS versus IP filtering, as DNS filtering is currently a functional solution, albeit not perfect. 4. Open Source Compliance Farzaneh proposed providing a definition of open source compliance, with the option to integrate it into the document if agreed upon by the task force. She explained that open source compliance entails offering free resources and best practices instead of paid legal assistance. Implementation plans should also be available through these resources. Farzaneh mentioned the possibility of modifying the terminology if necessary. 5. Timeline The task force discussed the document submission deadline, agreeing on a submission four weeks before the next RIPE Meeting. 6. New Chat Platform Boris mentioned that the task force will have to leave Mattermost for another chat platform in two weeks. The RIPE NCC is looking for alternatives and will keep the task force updated.

3 2

Draft Minutes - DNS Resolver Best Common Practice Task Force - 11 July 2023
by Boris Duval 18 Jul '23

18 Jul '23

Dear TF members, Here are the minutes from our fourth call. Cheers, Boris *** Tuesday, 11 July 2023 17:00 (UTC+2) Attendees: Joe Crowe, Töma Gavrichenkov, Tim Wicinski, János Zsakó Scribe: Boris Duval 1. Systems and Networks Hardening (Issue #21) The task force continued to work on breaking up the systems and networks section. As part of this, they discussed the pros and cons of running DNS resolver software on bare servers or in the cloud, considerations for running servers at 30% capacity, and how to collect a baseline of percentage usage: https://github.com/DNS-Resolver-BCP-TF/Resolver-Recommendations/issues/21 2. Recommended Knob Settings (Issue #10) The task force then discussed recommendations for specific DNS parameters, including DNSSEC, protocols (DoH, DoT, DoQ), client subnet and QNAME minimization: https://github.com/DNS-Resolver-BCP-TF/Resolver-Recommendations/issues/10

1 0

Draft Minutes - DNS Resolver Best Common Practice Task Force - 4 July 2023
by Boris Duval 06 Jul '23

06 Jul '23

Dear TF members, Here are the minutes from our third call. Cheers, Boris *** Tuesday, 4 July 2023 17:00 (UTC+2) Attendees: Maarten Aertsen, Shane Kerr, Tim Wicinski, János Zsakó Scribe: Boris Duval 1. Welcome and Administrivia Shane checked with the task force if they were happy working on the document via GitHub. The task force had no complaints. Maarten mentioned that he will contact Farzaneh to work on the legislation section. Shane said he would be on holiday next week, so Tim offered to chair the next session. 2. Breaking out the systems and networks section (Issue #21) Tim said that he had started to separate out the systems and networks section of the document and had put his ideas on this page: https://github.com/DNS-Resolver-BCP-TF/Resolver-Recommendations/issues/21 The task force reviewed all the items on the issue list and made comments on the page. Topics included BGP fallback issues, recommending to have two IP per address family, comment on HA design, publishing a list of back-end addresses and recommending signing RPKI routes. Tim will put the text together and organise it. 3. Recommended Knob Settings (Issue #10) The task force started to discuss and list different DNS settings. This included DNSSEC, QNAME and Max TTL. The overview is available on this page: https://github.com/DNS-Resolver-BCP-TF/Resolver-Recommendations/issues/10

1 0

Regular meetings to write text
by Shane Kerr 22 Jun '23

22 Jun '23

Hello Task Force, Now that I've completely gotten back into the swing of normal work, I want to set up weekly calls for the task force. Basically, the idea is to Zoom (or whatever) and screen-share and hammer out text until we're happy. I kind of hate having regular calls and working like this, but I'm hoping that maybe it can energize the group. ⚡ Please drop into the Mattermost instance and follow the link for a Doodle poll so we can set up a time. Feel free to e-mail me if you're unable to access this. Cheers, -- Shane

1 0

Draft Minutes - DNS Resolver Best Common Practice Task Force - 8 March 2023
by Boris Duval 22 Mar '23

22 Mar '23

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.

1 0

Invitation to first online meeting of DNS Resolver Task Force
by Shane Kerr 07 Mar '23

07 Mar '23

Dear Colleagues, The least-bad time-slot for our first online meeting is tomorrow evening. Below find the Zoom invitation. (This meeting is only for task force members; we'll publish minutes to this list shortly after for everyone else.) The date/time for the meeting: 2023-03-07 17:00 UTC That's tomorrow, 8 March at 18:00 CET, for folks who don't like RFC 3339 formatting for date and time. 😉 Topic: DNS Resolver Best Common Practice Task Force Time: This is a recurring meeting Meet anytime Join Zoom Meeting https://ripe.zoom.us/j/99624893128?pwd=Q2t1b2JiZnc2M1R6UFZKUEZUazlEZz09 Meeting ID: 996 2489 3128 Passcode: 246309 One tap mobile +31207946519,,99624893128# Netherlands +31207946520,,99624893128# Netherlands Dial by your location +31 20 794 6519 Netherlands +31 20 794 6520 Netherlands +31 20 794 7345 Netherlands +31 707 006 526 Netherlands +31 20 241 0288 Netherlands +31 20 794 0854 Netherlands +1 719 359 4580 US +1 253 205 0468 US +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Washington DC) +1 305 224 1968 US +1 309 205 3325 US +1 312 626 6799 US (Chicago) +1 346 248 7799 US (Houston) +1 360 209 5623 US +1 386 347 5053 US +1 507 473 4847 US +1 564 217 2000 US +1 646 558 8656 US (New York) +1 646 931 3860 US +1 669 444 9171 US +1 669 900 9128 US (San Jose) +1 689 278 1000 US Meeting ID: 996 2489 3128 Find your local number: https://ripe.zoom.us/u/acJI1RXsgD Join by SIP 99624893128(a)zoomcrc.com Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia Sydney) 103.122.167.55 (Australia Melbourne) 149.137.40.110 (Singapore) 64.211.144.160 (Brazil) 149.137.68.253 (Mexico) 69.174.57.160 (Canada Toronto) 65.39.152.160 (Canada Vancouver) 207.226.132.110 (Japan Tokyo) 149.137.24.110 (Japan Osaka) Meeting ID: 996 2489 3128 Passcode: 246309 -- Cheers, Shane

1 1