Who Controls the Internet? Authoritative NS Records in gTLDs(netmeister.org)
netmeister.org
Who Controls the Internet? Authoritative NS Records in gTLDs
https://netmeister.org/blog/nsauth-diversity.html
7 comments
This article focuses on DNS, there are many other critical parts of "control" of the Internet such as IP address allocation, root CAs, and infrastructure operators. IMO DNS and CAs are relatively easy to bypass "authority" because you can still communicate with other hosts via IP routing; address allocation and infrastructure operators are where the real control is.
This article focuses on DNS and AS numbers. Which are very much related to actual data plane. (i believe OP only looks at AS of authoritative dns servers, but it's most likely a good first approximation of the actual size and behavior of ASs)
> address allocation and infrastructure operators are where the real control is.
Most of them are also dns operators (at least for themselves), which is why it's a good proxy to study the state of the internet.
Also: in theory dns isn't that much needed (as you say, just use tcp/ip directly), but you'd be surprised what breaks when you blackhole dns packets on a network.
> address allocation and infrastructure operators are where the real control is.
Most of them are also dns operators (at least for themselves), which is why it's a good proxy to study the state of the internet.
Also: in theory dns isn't that much needed (as you say, just use tcp/ip directly), but you'd be surprised what breaks when you blackhole dns packets on a network.
There are alternative DNS roots, so I guess that begs the question, would it be possible to create your own parallel IP address system, or equivalent?
Maybe, but it would take massive amounts of buy in and (likely) money. There are some protocol hooks that could make it possible, but the current set of systems are optimized for one address allocation. It would be prohibitively expensive to either have a parallel transit network, or reengineer routers to manage multiple, parallel routing tables.
It's the social buy-in that the show stopper. There has been multiple DNS replacements, but none gained critical mass enough to get deployed on a large scale. It was never seen as worth the cost to migrate to a new naming system.
It's the social buy-in that the show stopper. There has been multiple DNS replacements, but none gained critical mass enough to get deployed on a large scale. It was never seen as worth the cost to migrate to a new naming system.
Have you heard about IPv6? ;)
Sure, but 99.9% of people on the internet will use the search bar.
This is really nice information. Thank you!
FWIW we have recently acquired funding to demonstrate that GNS can handle large size zones by migrating TLD zones (available through AXFR for now, the number of zones supporting hat is, eh, marginal [1]) to GNS which delegate back into DNS (using [2]).
This allows GNS users to (partially) circumvent the root and manually manage their local root namespace as envisioned for GNS [3].
We think that shipping default configurations and allowing users to modify/enhance that locally is how governance should look like from the user's perspective. If you want ICANN as default -> use the ICANN default configuration... if you need to override a censored/censoring registry, you can do that too... etc
[1] https://jpmens.net/2021/05/18/dns-open-zone-data/ [2] https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#n... [3] https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#n...
FWIW we have recently acquired funding to demonstrate that GNS can handle large size zones by migrating TLD zones (available through AXFR for now, the number of zones supporting hat is, eh, marginal [1]) to GNS which delegate back into DNS (using [2]).
This allows GNS users to (partially) circumvent the root and manually manage their local root namespace as envisioned for GNS [3].
We think that shipping default configurations and allowing users to modify/enhance that locally is how governance should look like from the user's perspective. If you want ICANN as default -> use the ICANN default configuration... if you need to override a censored/censoring registry, you can do that too... etc
[1] https://jpmens.net/2021/05/18/dns-open-zone-data/ [2] https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#n... [3] https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#n...
Really nice analysis. Thanks.
I wonder what it would take to host a website and be reasonably outside the blast radius of any of the parties you named as controlling the internet.
I wonder what it would take to host a website and be reasonably outside the blast radius of any of the parties you named as controlling the internet.
The kiwifarms saga was a really interesting deep dive in to how fragile the internet is. In the end they were able to get back online but it takes a monumental amount of work, redundancies, and relationships with infrastructure companies.
Currently the main weak point is ISPs. It’s not impossible to find hosts who will ignore complaints, but ISPs in the middle of the route can start disrupting traffic and causing connectivity issues for people in certain areas.
In general though it does seem like there is a need for more infrastructure hosts who stick to enforcing the law and just ignore the twitter drama. Epik domains and Terrahost seem to be leading this category.
Currently the main weak point is ISPs. It’s not impossible to find hosts who will ignore complaints, but ISPs in the middle of the route can start disrupting traffic and causing connectivity issues for people in certain areas.
In general though it does seem like there is a need for more infrastructure hosts who stick to enforcing the law and just ignore the twitter drama. Epik domains and Terrahost seem to be leading this category.
Have multiple domains, but verisign may be one of the most reliable as it is quite old.
Have your own ASIN network.
Have machines in datacenters that peer with multiple tier-1 providers.
Spend a lot of money.
Or run everything on an onion.
Have your own ASIN network.
Have machines in datacenters that peer with multiple tier-1 providers.
Spend a lot of money.
Or run everything on an onion.
Depends on your needs, but it is fairly simple to buy a domain-name and manage the dns-servers and hosting of web-server (and I guess e-mail) yourself.
If you have a A/AAAA-record in your top TLD pointing directly to your nameservers you do not depend on anyone but the root servers and TLD-servers to be available (in regards to DNS). Now, you just need to find a TLD that is not managed by one of the big ones, but that should be fairly easy.
I believe there is quite a bit of evidence that the major domain companies like godaddy will delete your domain if they receive complaints.
At the end of the day, it's all about the tyranny of the middlebox.
Let's say you get banned (somehow) by backbone, but you have one other middlebox willing to proxy you.
You're still visible! You're just behind that middlebox's routing. In fact, if you enplace yourself within an AS as an Authoritative DNS provider, suddenly, you da boss. I can make (from my network's point of view) facebook.com resolve anywhere I want for requests coming from within it. Now. If I had a channel to receive updates on the address of a service the big guys were trying to crush, say, TPB, my resplver can be updated to resolve that without honoring upstream.
This was actually how DNS started. It was just lists of host names to IP's/ARPANet addresses.
The challenge is always figuring out how to distribute notice of the changes.
Let's say you get banned (somehow) by backbone, but you have one other middlebox willing to proxy you.
You're still visible! You're just behind that middlebox's routing. In fact, if you enplace yourself within an AS as an Authoritative DNS provider, suddenly, you da boss. I can make (from my network's point of view) facebook.com resolve anywhere I want for requests coming from within it. Now. If I had a channel to receive updates on the address of a service the big guys were trying to crush, say, TPB, my resplver can be updated to resolve that without honoring upstream.
This was actually how DNS started. It was just lists of host names to IP's/ARPANet addresses.
The challenge is always figuring out how to distribute notice of the changes.
"Commercial services exist that sell you zone data, but it seems to me that this data ought to be public, so I excluded ccTLDs from my analysis for the time being."
It is worth considering that if DNS data is public it can easily be mirrored, e.g., users can maintain their own copies. Using locally-stored DNS data is rather easy to bypass the "centralisation" discussed by the author. I have been doing this for over 20 years.
Apparently some folks, like the people running ccTLD registries, believe that allowing the public to know IP addresses for large numbers of domains is a "security" issue. But it is not just the registries. For example, another source of DNS data are public scans such as the ones at opendata.rapid7.com. Recently, opendata.rapid7.com decided that this data should no longer be public.
It reminds me of telephone books and "unlisted" numbers. DNS seems to have no equivalent.
"But if you look closer, you'll notice that many of the nameservers are in the same domain, so if we then flatten the whole thing, we see a bit more of a centralization. "
Before I started using a localhost-bound forward proxy instead of DNS to map domain to IP for applications I used to run localhost-bound authoritative nameservers.1
By putting A record data into local zone file and querying that, non-recursively, instead of recursive DNS and a cache, I could eliminate many unnecessary lookups.
To gather the A record data I used non-recursive queries, not caches. (Which BTW is an excellent way to discover overly complex and brittle DNS configurations.)
One project I was working on was putting all domains using popular registrars into the same zones. For example, imagine example-domain.com uses ns.registrar-nameserver.com.2 Why query 192.5.6.30, a .com nameserver IP, to discover the nameserver for example-domain.com if I already have a list of every domain that uses ns.registrar-nameserver.com. I can put this list of domains into a local zone. Then I can just query ns.registrar-nameserver.com directly and skip remote access to 192.5.6.30 port 53. I found that the number of domains changing nameservers frequently was relativaly small, and was not enough to affect the utility of all the static DNS data.
1. I still do, e.g., I still run a local custom root.zone but I do not put much A record data into it. Instead I use DNS wildcards, as an alternative to using the firewall, to direct HTTP traffic to the proxy.
2. At the time, domaincontrol.com namservers were #1. But it is alarming to see googledomains.com servers at #2. Google did not even exist as a registrar back then, before new gTLDs and cloud computing hype. That said, it is wise to look at the actual domains rather than just count them. If an ISP or CDN is has a domain for every IP address it controls, where the IP address is contained in the domain name, that can skew the numbers considerably.
"Take out Verisign, and the internet's going to have a bad day."
I keep a local copy of com.zone. I can remember when it was a pain just to find the HDD storage for it. With today's computers, it can fit easily on a "phone" and even into RAM. IMHO, this is the most important data in the internet. It is nice to know that network operators could block port 53 and I could still use a very large portion of the www. We already have filtered DNS in certain locations, e.g., where all traffic to port 53 is redirected. I have used internet access with filtered DNS extensively. Using locally-stored DNS data is at least a way to obliviate DNS filtering. I have also used it when www sites have DNS problems.
It is worth considering that if DNS data is public it can easily be mirrored, e.g., users can maintain their own copies. Using locally-stored DNS data is rather easy to bypass the "centralisation" discussed by the author. I have been doing this for over 20 years.
Apparently some folks, like the people running ccTLD registries, believe that allowing the public to know IP addresses for large numbers of domains is a "security" issue. But it is not just the registries. For example, another source of DNS data are public scans such as the ones at opendata.rapid7.com. Recently, opendata.rapid7.com decided that this data should no longer be public.
It reminds me of telephone books and "unlisted" numbers. DNS seems to have no equivalent.
"But if you look closer, you'll notice that many of the nameservers are in the same domain, so if we then flatten the whole thing, we see a bit more of a centralization. "
Before I started using a localhost-bound forward proxy instead of DNS to map domain to IP for applications I used to run localhost-bound authoritative nameservers.1
By putting A record data into local zone file and querying that, non-recursively, instead of recursive DNS and a cache, I could eliminate many unnecessary lookups.
To gather the A record data I used non-recursive queries, not caches. (Which BTW is an excellent way to discover overly complex and brittle DNS configurations.)
One project I was working on was putting all domains using popular registrars into the same zones. For example, imagine example-domain.com uses ns.registrar-nameserver.com.2 Why query 192.5.6.30, a .com nameserver IP, to discover the nameserver for example-domain.com if I already have a list of every domain that uses ns.registrar-nameserver.com. I can put this list of domains into a local zone. Then I can just query ns.registrar-nameserver.com directly and skip remote access to 192.5.6.30 port 53. I found that the number of domains changing nameservers frequently was relativaly small, and was not enough to affect the utility of all the static DNS data.
1. I still do, e.g., I still run a local custom root.zone but I do not put much A record data into it. Instead I use DNS wildcards, as an alternative to using the firewall, to direct HTTP traffic to the proxy.
2. At the time, domaincontrol.com namservers were #1. But it is alarming to see googledomains.com servers at #2. Google did not even exist as a registrar back then, before new gTLDs and cloud computing hype. That said, it is wise to look at the actual domains rather than just count them. If an ISP or CDN is has a domain for every IP address it controls, where the IP address is contained in the domain name, that can skew the numbers considerably.
"Take out Verisign, and the internet's going to have a bad day."
I keep a local copy of com.zone. I can remember when it was a pain just to find the HDD storage for it. With today's computers, it can fit easily on a "phone" and even into RAM. IMHO, this is the most important data in the internet. It is nice to know that network operators could block port 53 and I could still use a very large portion of the www. We already have filtered DNS in certain locations, e.g., where all traffic to port 53 is redirected. I have used internet access with filtered DNS extensively. Using locally-stored DNS data is at least a way to obliviate DNS filtering. I have also used it when www sites have DNS problems.
> Apparently some folks, like the people running ccTLD registries, believe that allowing the public to know IP addresses for large numbers of domains is a "security" issue.
There's some merit to this.
Doing the reverse lookup - finding all other domains that resolve to the same IP (or same subnet) can leak a lot of information. For example: what other businesses are run by the same entity, and test/staging/admin infrastructure.
It can also be another way to attack a specific http server, since different names on the same IP can be routed to different applications or even different internal servers.
Actually relying on this is silly security-by-obscurity, but there's really no upside to publishing a detailed map.
There's some merit to this.
Doing the reverse lookup - finding all other domains that resolve to the same IP (or same subnet) can leak a lot of information. For example: what other businesses are run by the same entity, and test/staging/admin infrastructure.
It can also be another way to attack a specific http server, since different names on the same IP can be routed to different applications or even different internal servers.
Actually relying on this is silly security-by-obscurity, but there's really no upside to publishing a detailed map.
All DBS records these days are unlisted. In the past, or with badly configured servers, you can list all entries of a zone // list all subdomains.
It can give you good information about what a company is doing, who their clients are, or targeting some admin host
It can give you good information about what a company is doing, who their clients are, or targeting some admin host
I should add that one motivation for the project was the possibility of encrypted DNS, made possible at the time by DNSCurve and CurveDNS. The idea is that a large registrar could run CurveDNS forwarders in front of its authoritative servers and the user could then have encrypted DNS packets for many, many domains by connecting directly to the registrar's servers. I doubted at the time, and I still do, that root servers or registries would ever run CurveDNS forwarders.
"If an ISP or CDN is has a domain for every IP address it controls, where the IP address is contained in the domain name, that can skew the numbers considerably."
This is a dumb statement as these are probably subdomains not domains. I apologise. That said, when a CDN is also a domain registry, it's not unthinkable.
This is a dumb statement as these are probably subdomains not domains. I apologise. That said, when a CDN is also a domain registry, it's not unthinkable.
- CISCO / Juniper
-- AWS
--- Cloudflare