December 2021 - dns-wg - mailman.ripe.net

DNS4EU?
by Hank Nussbacher 12 Jan '22

12 Jan '22

19 53

OARC 37 Call for Contributions
by Hazel Smith 28 Dec '21

28 Dec '21

OARC 37 will be an *online/hybrid* meeting on *February 17th and 18th 2022 starting at 16:00 UTC (10:00 CST)*. The onsite part of the meeting will be held in Austin, Texas. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: Managing DNS changes and propagation, release process, change management. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: Managing service capacity, failovers, disaster recovery. As it is an *online/hybrid* workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** * 27 December 2021 - Submissions open via Indico * 10 January 2022 - Deadline for submission (23:59 UTC) * 11 January 2022 - Initial Contribution list published * 18 January 2022 - Full agenda published * 3 February 2022 - Deadline for slideset submission and Rehearsal * 17 & 18 February 2022 - OARC 37 Workshop The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc37> DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups at DNS-OARC. See the registration page for details. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers of OARC 37: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * you will be expected to attend a rehearsal on *3rd February 2022*. It would be very useful to have your slides (even if draft) ready for this. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> *Hazel Smith, for the DNS-OARC Programme Committee* OARC depends on sponsorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- Hazel Smith Site Reliability Engineer // Google Cloud, London hazelesque(a)google.com sre.google

1 0

DNS4EU?
by Andrew Campling 21 Dec '21

21 Dec '21

I've noted various comments about the EU's DNS4EU initiative on the list over the last week or so. If anyone is interested in more detail and missed the related discussion on our weekly call a few weeks back, you can find the recording at https://419.consulting/encrypted-dns/f/dns4eu. > On 17 Dec 2021, at 11:21, Stephane Bortzmeyer <bortzmeyer(a)nic.fr> wrote: > > On Fri, Dec 17, 2021 at 01:43:12AM +0000, Geoff Huston <gih(a)apnic.net> > wrote a message of 67 lines which said: > >> The problem for everyone else is the incursion of a US private entity >> into the heart of the Internet?s name resolution infrastructure. >> >> Over the past 16 months the number of EU users who pass queries to >> Google?s Public DNS has risen from a little over 15% to touching 30% >> >> If you are working in the EC and you see yet another piece of the >> Internet?s digital communications infrastructure being aggregated and >> centralized by a gigantic US entity, then wouldn?t you be a little >> bit disconcerted? > > I think we all understand the starting point, and the concern of the > EC. The problem is that they apparently don't provide a detailed > problem analysis. Observing that the market share of US public > resolvers increases is one thing, understanding why is another thing, > and which is very important to solve the problem. Was there are survey > about the reasons for this switch to these resolvers? > > For instance, an important reason (may be the main one) why users use > US public resolvers is because they don't implement censorship > (SciHub, football events, music and film sharing). The DNS4EU project > is silent about whether or not they will have censorship (a > problematic silence!) but I note that they claim DNS4EU is a lying > resolver. Even if lies are initially limited to malware and C&C, I > have no doubt that the IP people (IP not being the Internet Protocol) > will, as soon as they discover DNS4EU, ask for censorship and they are > a very powerful lobby. If DNS4EU yields to their requirments, then the > project is doomed. The use of the pejorative term "lying" resolver is unhelpful in this context. It is important to acknowledge that the vast majority of Internet users are not experts; indeed most are unaware of either the purpose or the existence of DNS. They are however exposed to vast amounts of malicious content and, in my opinion, any mass-market resolver that does not block access to such content by default is not fit for purpose. In addition, for citizens of countries covered by GDPR, accessing a resolver located in the same jurisdiction is beneficial as it doesn't then export personal data elsewhere - US-based resolvers have the disadvantage of falling under the US CLOUD Act and FISA 702. As far as protection of intellectual property is concerned, it seems reasonable to me that Internet companies comply with court orders in the same way that other companies have to do so: despite the assertions of cyberlibertarians, the Internet is not a separate place beyond the reach of national legislation. This is just as well, otherwise we'd still be prey to the whims of surveillance capitalists and not protected by GDPR etc. > >> So I think this is not really about the quality of the alternatives >> available for European users (and ISPs) in the DNS resolution market. > > I don't think that many people switched to Google or Cloudflare > because of DNSSEC validation (unfortunately) but may be they switched > because of technical malfunctions. Each time there is a big breakage > of the resolver of an IAP, everybody on the social networks advise > "use 8.8.8.8" and people don't come back after that. So, even if > DNSSEC doesn't matter, robustness does. > I know that one of the drivers of the DNS4EU project was to improve the resilience of Internet infrastructure given the way that increased centralisation has weakened this over the last few years. Providing an alternative open resolver is just one of several approaches being taken in this regard. An additional benefit of a European resolver is the opportunity to extract localised cybersecurity intelligence, something that I know the similar Canadian Shield project has already acknowledged has been an outcome of its operation. Many of the commercial threat feeds are US-centric whereas DNS4EU provides the ability to draw insight from what may be a significant European user base. Andrew

2 1

Lower TTLs for NS and DS records in reverse DNS delegations
by Anand Buddhdev 03 Dec '21

03 Dec '21

Dear colleagues, Users may request reverse DNS delegation by creating "domain" objects in the RIPE Database. Such domain objects must contain "nserver" attributes to specify the name servers for a reverse DNS zone, and may contain "ds-rdata" attributes, to specify delegation signer (DS) records. When the RIPE NCC publishes these records in the appropriate parent zones, the Time to Live (TTL) of all these records is set at 172800 (two days). The TTL of delegation NS records may be overridden by the TTL of NS records from a zone's apex. Alternatively, many large resolvers ignore the TTL values of NS records and cap them at much lower values such as 21600. Finally, there is no way for a zone operator to change the TTL of a DS record, which is only present in a parent zone. Long TTLs can cause problems for users when they want to change their name servers or perform DNSSEC key roll-overs. A long TTL on a DS record is especially harmful when a user needs to do a key roll-over in an emergency. We propose to lower, in the first quarter of 2022, the TTL on NS records to 86400 and on DS records to 3600. We welcome feedback or discussion about this, ideally via the DNS Working Group mailing list. If you prefer to send your feedback directly to us, you can email dns(a)ripe.net. Regards, Anand Buddhdev RIPE NCC

17 18

Re: [dns-wg] Lower TTLs for NS and DS records in reverse DNSdelegations
by Jørgen Hovland ☁️ 02 Dec '21

02 Dec '21

1 0