Who Actually Runs the Internet: The Standards Bodies Behind Linux and Networking

Every command you type on a Linux box, and every website that server talks to, rests on a stack of standards most sysadmins never look at directly. Knowing who actually governs the internet and the open systems ecosystem underneath Linux is genuinely useful, both for troubleshooting (“is this a bug or is this the spec”) and for understanding why things are named the way they are. Here is the real map, organization by organization, with the actual sites.

Who runs the internet’s core infrastructure

• IANA (Internet Assigned Numbers Authority): manages the DNS root zone, global IP address allocation, and protocol parameter registries. When you wonder why port 443 means HTTPS everywhere, this is the registry that says so.
• ICANN: the nonprofit that coordinates the domain name system and oversees IANA’s functions at a policy level.
• Root Servers: the technical home of the 13 logical root name server systems that anchor global DNS resolution.
• Internet Society (ISOC): provides organizational and funding support for core internet infrastructure and policy work.
• Internet Architecture Board (IAB): technical oversight of the IETF’s standards process.

Where the actual protocols you run come from

• IETF (Internet Engineering Task Force): the working body that develops TCP/IP, DNS, TLS, and HTTP itself. If you have ever run dig, curl, or configured a firewall rule, you were implementing an IETF specification.
• RFC Editor: the official archive of every Request for Comments, the actual documents that define these protocols. RFC 9110 (HTTP semantics) and RFC 1035 (DNS) are both here, in full, for free.
• W3C: governs HTML, CSS, and web accessibility standards, relevant the moment you’re serving any web content off a Linux box.
• The Open Group: owns POSIX (the specification that defines what “a Unix-like system” actually means at the API level) and the UNIX trademark/certification itself.

The organizations that actually shape Linux and open source

• Linux Foundation: hosts the kernel development process and maintains cross-distro reference specs, including the Filesystem Hierarchy Standard (why /etc, /var, and /usr mean what they mean across every major distro) at refspecs.linuxfoundation.org.
• Free Software Foundation (FSF): maintains the GNU Project and the GPL family of licenses that a huge share of the Linux userland (bash, coreutils, gcc) is released under.
• ISO Networking Database: home of the formal OSI reference model definitions still used as the shared vocabulary for describing network layers, even though the internet itself runs on TCP/IP rather than the full OSI stack.

Hardware and lower-level standards that affect what you install on

• IEEE Standards Association: owns Ethernet (802.3) and Wi-Fi (802.11), the two specs underneath almost every network interface a Linux server has.
• IEC: electrotechnology and hardware specifications at the international level, working alongside ISO on many joint standards.
• JEDEC: sets DDR RAM and semiconductor memory standards, worth knowing when you’re reading a server’s memory compatibility list.
• PCI-SIG: governs PCI Express, the bus standard behind most server expansion cards, NICs, and NVMe controllers.

Text, characters, and encoding

If you have ever debugged a mangled character in a log file or a database, you were fighting a mismatch against the Unicode Consortium‘s specification, the body that defines UTF-8 and every character encoding a modern Linux system assumes by default.

Why this actually matters day to day

Knowing this map helps in a specific, practical way: when something behaves unexpectedly, you can go check whether it’s a bug in the implementation or genuinely correct behavior per the actual specification, rather than guessing. A DNS resolution quirk, a TLS handshake failure, or a filesystem permission edge case usually traces back to a document one of these organizations publishes, openly and for free.

Frequently asked questions

Do I need to read RFCs to be a good Linux admin?
Not routinely, but knowing they exist and are freely readable at rfc-editor.org changes how you troubleshoot. When a tool’s documentation is ambiguous about exact behavior, the underlying RFC is the actual source of truth, and reading the relevant section directly often resolves a debugging session faster than searching forums.

Is POSIX still relevant if I only use Linux and never touch other Unix systems?
Yes. POSIX compliance is why a shell script written with portable syntax behaves the same way on Ubuntu, RHEL, and macOS’s terminal. The moment you write a script depending on a Linux-specific (GNU) extension instead of the POSIX-standard behavior, portability breaks, which is a common source of “works on my machine” bugs when scripts move between systems.