Post by @paul_ipv6@infosec.exchange

Jan Wildeboer 😷:krulorange:
@jwildeboer @social.wildeboer.net
2026-09-07 DNS Root Server Addresses
Letter IPv4 address IPv6 address Operator Operator origin

A | 198.41.0.4 | 2001:503:ba3e::2:30 | Verisign | United States
B | 170.247.170.2 | 2801:1b8:10::b | usc-Ist | United States
C | 192.33.4.12 | 2001:500:2::c | Cogent Communications | United States
D | 199.7.91.13 | 2001:500:2d::d | University of Maryland | United States
E | 192.203.230 |.10 2001:500:a8::e | NASA Ames Research Center | United States
F | 192.5.5.241 | 2001:500:2f::f | Internet Systems Consortium | United States
G | 192.112.36.4 | 2001:500:12::d0d | Defense Information Systems Agency | United States
H | 198.97.190.53 | 2001:500:1::53 | U.S. Army Research Lab | United States
I | 192.36.148.17 | 2001:7fe::53 | Netnod | Sweden
J | 192.58.128.30 | 2001:503:c27::2:30 | Verisign | United States
K | 193.0.14.129 | 2001:7fd::1 | RIPE NCC | Netherlands
L | 199.7.83.42 | 2001:500:9f::42 | ICANN | United States
M | 202.12.27.33 | 2001:dc3::35 | WIDE Project | Japan
2026-09-07 DNS Root Server Addresses Letter IPv4 address IPv6 address Operator Operator origin A | 198.41.0.4 | 2001:503:ba3e::2:30 | Verisign | United States B | 170.247.170.2 | 2801:1b8:10::b | usc-Ist | United States C | 192.33.4.12 | 2001:500:2::c | Cogent Communications | United States D | 199.7.91.13 | 2001:500:2d::d | University of Maryland | United States E | 192.203.230 |.10 2001:500:a8::e | NASA Ames Research Center | United States F | 192.5.5.241 | 2001:500:2f::f | Internet Systems Consortium | United States G | 192.112.36.4 | 2001:500:12::d0d | Defense Information Systems Agency | United States H | 198.97.190.53 | 2001:500:1::53 | U.S. Army Research Lab | United States I | 192.36.148.17 | 2001:7fe::53 | Netnod | Sweden J | 192.58.128.30 | 2001:503:c27::2:30 | Verisign | United States K | 193.0.14.129 | 2001:7fd::1 | RIPE NCC | Netherlands L | 199.7.83.42 | 2001:500:9f::42 | ICANN | United States M | 202.12.27.33 | 2001:dc3::35 | WIDE Project | Japan

At the core of the global internet are the DNS root servers. These 13 go-to places are at the top of authority when it comes to making sure you can connect to any server with a domain name. What you might not know is that 10 of these 13 root servers are ultimately under US jurisdiction. Should that worry you? I guess not, the current system is quite robust. But I deal in risk assessment and probabilities. And I think this isn't an ideal setup.

en.wikipedia.org/wiki/Root_nam

#DNS #Centralisation

Patrick Mevzek
@pmevzek @framapiaf.org

@jwildeboer There could be more of them... but they are all feeding themselves out of hidden primary root controlled by Verisign, a US corporation. So at the end, those public ones don't really count. Except if you consider they might, collectively, all decide to use another root than IANA one which is never impossible but quite not the highest probability. (and see previous court cases about .LY yes there were attempts to remove TLDs from root). They also all have relationships with ICANN. 1/x

Jan Wildeboer 😷:krulorange:
@jwildeboer @social.wildeboer.net

@pmevzek It's the other way around. ICANN is the master. And ICANN has so far been quite OK-ish at defending the freedom of The Net. My personal preference would be to have no centralisation at all. But knowing that is impossible in the way DNS works, the next best solution would be to put ICANN under the UN, not the US. One letter, big consequences :)

Patrick Mevzek
@pmevzek @framapiaf.org

@jwildeboer "ICANN is the master.". Technically/theoretically just a technical coordinator implementing policies discussed and decided among all stakeholders (including governments with in theory again all the same power, but also other orgs) :-) Yes, no need to point out the difference between theory and practice and who captures what and how much.

Jan Wildeboer 😷:krulorange:
@jwildeboer @social.wildeboer.net

@pmevzek It's a discussion I'd rather have over a long evening with food and drinks. 500 character messages are limiting. Could there be a more decentralised way for trust establishment? Yes. I think there is. It's what the ICAO (a UN agency) has established for travel documents. Which relies on a bilateral system of agreements, not a centralised one. See ICAO 9303 part 12 icao.int/publications/doc-seri

Patrick Mevzek
@pmevzek @framapiaf.org
Public en edited

@jwildeboer You are comparing something that is relevant only between governments (how they trust each other regarding travel documents) with something that has a public reach and needs a consensus, of not just governments but every single party online (who exactly controls .com or any other TLD?). You could mention as well how most BGP peering are set (over a beer πŸ™‚ ?). But otherwise agree on the fact that the topic is far too broad for a thread here πŸ™‚

Jan Wildeboer 😷:krulorange:
@jwildeboer @social.wildeboer.net

@pmevzek I come from the times where you called someone in Dortmund at the university to add your .de domain in the right way, so yes, I am old and biased. I am also one of those that understand the complexity of reliability where centralisation is the obvious choice and decentralisation is an explosion of questions. Right now we can live reasonably well with centralisation on the DNS level but my risk assessment puts doubts on this. What next? That's the question. No real answers.

Paul_IPv6
@paul_ipv6 @infosec.exchange

@jwildeboer @pmevzek

i think that summarizes well where we are. DNS decentralization is hard and we have more questions and concerns than concrete ways to fix it.

our best and easiest chance to fix this was in the 1980s :)

Carl Malamud
@carlmalamud @official.resource.org

@paul_ipv6 @jwildeboer @pmevzek time travel always the best means to a comprehensive solution.