I attended this "morning" (for me)'s discussion about DNS4EU. I don't know much about what the EC is put out in it's RFP as I don't live in the EU (..yet?) and aren't in a position to respond to it. Right now, people know about 8.8.8.8. They spray painted it on walls in Turkey a few years ago! Amateur network administrators, aka local teens, know that if someone is having problems with their device, that sticking 8.8.8.8 in sometimes helps. Many ISPs and many "pro-sumers" who configure their own home gateways will stick 8.8.8.8 in as a DNS server. I run my own recursive resolvers, but, on my desktop I have: nameserver 2607:f0b0:f::babe:f00d nameserver 209.87.249.18 nameserver 8.8.8.8 search sandelman.ca (The first two point to the same machine) Why? because sometimes shit happens, and that local VM is broken, and it's easier to use DNS to fix DNS. Yeah, I have breadcrumbs in my /etc/hosts too. So what I would like DNS4EU to do is to create a European hosted and operated alternative. It doesn't have to be run by a single entity. In fact, I think that this is a bad idea. But, it does have to have the same kind of "name" recognition as 8.8.8.8 (%) That might mean, literally, spray painting it on walls. Berlin people could hire 1UP crew maybe. It seems clear that this new resolver address will need to have multiple servers and and be anycasted. It could be run by a multitude of operators, with at least one per country. That solves the entire digital sovereignty issue, and the "local" denylist. a) This is where RIPE NCC starts to come in: find and allocate some memorable IPv4/24, and IPv6/48 for this. Let's call this R.R.R.R b) In order to run DoT, DoH, we need TLS certificates. If the system is anycast, and is run by a multitude of entities, then we need to be able to deploy certificates to a multitude of entities and each need to manage their own private keys. "dns.google" works because Google is a CA. (I didn't know that was the FQDN for it until I visited it just now) This is the second activity which RIPE NCC should be involved it: coordinating the certificates for the entities. How exactly to do this, technically, is an open question to me. There are many possible arrangements, including some new ones like RFC9060. c) The variety of entities running these servers need consistent and regular training. There is a further interesting thing to me, and that involves the IoT situations with DoT/DoH. There are three issues. 1) IoT devices that ignore the local resolver settings and try to use 8.8.8.8. This upsets many people (Vixie is loudest), because many of us have concerns about what the devices are doing. DoH makes it near impossible to observe. I have an IETF OPSAWG draft about DNS and MUD. There are privacy issues with the devices crossing national jurisdictions with their queries. I suspect GDPR ones, but I'm no lawyer. 2) Many would like to use DNS queries as canaries for malware on IoT devices. 3) Many would like to prevent IoT devices from being able to reach certain known malware sites. Recognize that when we allocate R.R.R.R, we get all of R.R.R.0/24 at least, and we could run a number of diffentiated services at R.R.R.I, etc. If R.R.R.I was promoted as a GDPR-safe place for IoT devices to send queries to, and if the canaries could be coordinated, then that would likely be a win for the security of the Internet. (Of course, making IoT devices pay attention to RDNSS and DHCP values would be my priority. But, return R.R.R.I to those IoT devices would make sense) (%) I know that 8.8.4.4 is also a google resolver, but I rarely use it. 1.1.1.1 is easier to remember. I can't remember the IPv6 for any of them offhand. Yet, I know sprint.net is http://[2600::] for instance. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide