pith. sign in

arxiv: 2605.15646 · v1 · pith:LVLCFEGNnew · submitted 2026-05-15 · 💻 cs.NI

The Internet Runs on Names

Geoff Huston , Lixia Zhang This is my paper

Pith reviewed 2026-05-19 19:40 UTC · model grok-4.3

classification 💻 cs.NI
keywords DNS namesIP addressesInternet architectureservice identityload balancingoperational complexitynetwork fragilitytrust
0
0 comments X

The pith

DNS names now serve as the Internet's foundation for identity, reachability, load balancing, and trust, while IP addresses act only as ephemeral routing locators.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper argues that the original TCP/IP design identified hosts by stable IP addresses for packet delivery, but this model no longer matches how the network actually works. Large platforms and applications consolidated services and adopted DNS names to manage identity, direct traffic, balance loads, and establish trust. IP addresses were left as short-lived pointers that change often. This evolution arose from practical needs rather than any coordinated redesign of the architecture. The resulting layers of indirection produce growing operational complexity, fragility, and exposure to failures.

Core claim

The Internet's TCP/IP architecture was designed for resilient packet delivery between hosts identified by IP addresses. Over time, however, the consolidation of applications and services into large-scale platforms built on that universal packet-delivery substrate drove deployment practices that fundamentally changed the Internet's operational model: the network now operates primarily on names. DNS names have become the basis for service identity, reachability, load balancing, and trust, while IP addresses have become ephemeral routing locators. This change was driven by application needs and platform consolidation in the absence of any overarching plan. The resulting mismatch between the 2.5

What carries the argument

The mismatch between the original address-based TCP/IP design and the current name-based operational model driven by platform consolidation.

Load-bearing premise

The observed shift to name-based operation constitutes a fundamental mismatch with the original TCP/IP design that necessarily produces growing operational complexity, fragility, and vulnerability.

What would settle it

A concrete measurement showing that common services can resolve names, balance loads, and establish trust without adding extra layers of indirection or raising the frequency of outages.

read the original abstract

The Internet's TCP/IP architecture was designed for resilient packet delivery between hosts identified by IP addresses. Over time, however, the consolidation of applications and services into large-scale platforms built on that universal packet-delivery substrate drove deployment practices that fundamentally changed the Internet's operational model: the network now operates primarily on names. DNS names have become the basis for service identity, reachability, load balancing, and trust, while IP addresses have become ephemeral routing locators. This change was driven by application needs and platform consolidation in the absence of any overarching plan. The resulting mismatch between the original address-based design and the current name-based operation leads to serious consequences: operational complexity that grows with each new layer of indirection, fragility, and vulnerability - as seen in recent high-profile outages. This paper exposes this mismatch as a necessary first step toward understanding its consequences and addressing the risks of continuing on the same path.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper claims that the Internet's TCP/IP architecture was designed for resilient packet delivery between hosts identified by IP addresses, but consolidation of applications into large-scale platforms has driven an unplanned shift to name-based operation. DNS names now serve as the basis for service identity, reachability, load balancing, and trust, while IP addresses function as ephemeral routing locators. This mismatch with the original address-based design produces growing operational complexity from added layers of indirection, plus fragility and vulnerability, as illustrated by recent high-profile outages. The work presents this observation as a necessary first step toward understanding and mitigating the risks.

Significance. If the interpretive thesis is substantiated, the paper would usefully frame an important evolution in Internet operational practice and its potential systemic consequences for reliability and security. It could stimulate discussion on reconciling naming and addressing in future architectures, though its current lack of quantitative support or causal tracing limits immediate technical impact.

major comments (2)
  1. [Abstract] Abstract: The central assertion that the name-based operational model 'leads to' operational complexity that grows with each new layer of indirection, fragility, and vulnerability is presented as a direct consequence of the architectural mismatch, yet the manuscript supplies no data, measurements, controlled comparisons, or root-cause analysis linking specific outages to this mismatch rather than to configuration, software defects, or attack surfaces that would exist independently of the naming layer.
  2. [Main argument] Main argument (descriptive sections): The claim that DNS names have become the basis for service identity, reachability, load balancing, and trust is advanced without deployment statistics, concrete examples of name-based mechanisms at scale, or contrasts with address-based deployments that would demonstrate the shift as the dominant source of the cited problems.
minor comments (1)
  1. [Abstract] Abstract: The reference to 'recent high-profile outages' would benefit from at least one specific citation or brief description to allow readers to evaluate the connection to the architectural argument.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments, which help clarify the scope and limitations of our observational analysis. The manuscript is intended as a first-step framing of an architectural mismatch rather than a quantitative or causal study. We address each major comment below.

read point-by-point responses

  1. Referee: [Abstract] Abstract: The central assertion that the name-based operational model 'leads to' operational complexity that grows with each new layer of indirection, fragility, and vulnerability is presented as a direct consequence of the architectural mismatch, yet the manuscript supplies no data, measurements, controlled comparisons, or root-cause analysis linking specific outages to this mismatch rather than to configuration, software defects, or attack surfaces that would exist independently of the naming layer.

    Authors: We agree that the paper does not supply new measurements, controlled comparisons, or root-cause analyses of specific outages. The central claim is an interpretive observation: the unplanned shift to name-based operation creates additional layers of indirection whose operational consequences are visible in well-documented incidents. We do not assert that the naming layer is the sole or primary cause of every outage. We will revise the abstract to replace the phrasing 'leads to' with 'contributes to' and to explicitly state that the work is an architectural framing rather than an empirical causal study. revision: yes

  2. Referee: [Main argument] Main argument (descriptive sections): The claim that DNS names have become the basis for service identity, reachability, load balancing, and trust is advanced without deployment statistics, concrete examples of name-based mechanisms at scale, or contrasts with address-based deployments that would demonstrate the shift as the dominant source of the cited problems.

    Authors: The descriptive sections draw on established operational practices (e.g., DNS-based service discovery in CDNs, anycast, and cloud load balancing) that are already documented in the literature and in public platform architectures. We do not present new deployment statistics because the paper's contribution is the identification of the resulting architectural mismatch rather than a measurement study. We can add a small number of additional concrete examples and references to existing measurement papers that quantify name-based traffic, but we maintain that the dominant shift itself is not in dispute among operators. revision: partial

Circularity Check

0 steps flagged

No circularity: descriptive position paper with no derivations or self-referential constructs

full rationale

The paper advances an observational thesis about the shift from address-based to name-based Internet operation and its consequences, supported by historical deployment trends and outage examples rather than any mathematical derivation, fitted parameters, or first-principles chain. No equations exist, no predictions are generated from subsets of data, and no uniqueness theorems or ansatzes are imported via self-citation. The argument remains self-contained as an interpretive analysis of external practices; the claimed causal link between naming layers and complexity is presented as a premise for discussion, not as a result proven by reduction to the paper's own inputs.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the premise that the original TCP/IP design was strictly address-based and that current name-centric practices represent an unplanned deviation without independent quantification of the claimed consequences.

axioms (1)
  • domain assumption The Internet's TCP/IP architecture was designed for resilient packet delivery between hosts identified by IP addresses.
    This baseline is invoked to contrast with current name-based operation.

pith-pipeline@v0.9.0 · 5671 in / 1209 out tokens · 60353 ms · 2026-05-19T19:40:22.979968+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

28 extracted references · 28 canonical work pages

  1. [1]

    2025.Post-Incident Report: DynamoDB DNS Race Condition in US-EAST-1

    Amazon Web Services. 2025.Post-Incident Report: DynamoDB DNS Race Condition in US-EAST-1. https://www.thousandeyes.com/blog/aws- outage-analysis-october-20-2025

    work page 2025

  2. [2]

    2024.Sandvine’s 2024 Global Internet Phenomena Report: Global Internet Usage Continues to Grow

    AppLogic Networks. 2024.Sandvine’s 2024 Global Internet Phenomena Report: Global Internet Usage Continues to Grow. Technical Report. App- Logic Networks. https://www.applogicnetworks.com/blog/sandvines- 2024-global-internet-phenomena-report-global-internet-usage- continues-to-grow Formerly published under Sandvine

    work page 2024

  3. [3]

    Arends, R

    R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. 2005.DNS Security Introduction and Requirements. RFC 4033. IETF. https://www. rfc-editor.org/rfc/rfc4033 The Internet Runs on Names

    work page 2005

  4. [4]

    Matt Calder, Xun Fan, Zi Hu, Ethan Katz-Bassett, John Heidemann, and Ramesh Govindan. 2013. Mapping the Expansion of Google’s Serving Infrastructure. InProceedings of the ACM Internet Measurement Conference (IMC ’13). ACM. doi:10.1145/2504730.2504754

    work page doi:10.1145/2504730.2504754 2013

  5. [5]

    David D. Clark. 1988. The Design Philosophy of the DARPA Internet Protocols. InProceedings of the ACM SIGCOMM Conference. 106–114

    work page 1988

  6. [6]

    Cloudflare. 2025. Cloudflare June 2025 outage. https://blog.cloudflare. com/cloudflare-service-outage-june-12-2025/. Cloudflare Blog. Ac- cessed April 12, 2026

    work page 2025

  7. [7]

    Cloudflare. 2025. Post Mortem: Cloudflare outage on November 18,

    work page 2025

  8. [8]

    Cloud- flare Blog

    https://blog.cloudflare.com/18-november-2025-outage/. Cloud- flare Blog. Accessed April 12, 2026

    work page 2025

  9. [9]

    Carlo Contavalli, Wilmer van der Gaast, David C Lawrence, and Warren Kumari. 2016. Client Subnet in DNS Queries. RFC 7871. doi:10.17487/RFC7871

    work page doi:10.17487/rfc7871 2016

  10. [10]

    Geoff Huston. 2025. Names, Addresses, and the Future of the Inter- net. NDNComm 2025. https://ndncomm2025.named-data.net/slides/ NDNComm2025/s2-3-Geoff-Huston.pdf

    work page 2025

  11. [11]

    2021.More details about the October 4 outage

    Santosh Janardhan. 2021.More details about the October 4 outage. Meta Engineering. https://engineering.fb.com/2021/10/05/networking- traffic/outage-details/

    work page 2021

  12. [12]

    Aqsa Kashaf, Vyas Sekar, and Yuvraj Agarwal. 2020. Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned from the Mirai-Dyn Incident?. InProceedings of the ACM Internet Measurement Conference (IMC ’20). ACM. doi:10.1145/3419394. 3423664

    work page doi:10.1145/3419394 2020

  13. [13]

    Balachander Krishnamurthy, Craig Wills, and Yin Zhang. 2001. On the Use and Performance of Content Distribution Networks. InProceedings of the ACM SIGCOMM Internet Measurement Workshop. ACM, 169–182

    work page 2001

  14. [14]

    Craig Labovitz. 2019. Internet Traffic 2009 - 2019. Presentation at LAC- NOG 2019. https://www.lacnic.net/innovaportal/file/4016/1/lacnog- internet-traffic-2009-2019.pdf Measurements conducted via Nokia Deepfield regarding CDN consolidation and Hypergiant traffic pat- terns

    work page 2019

  15. [15]

    Matt Lepinski and Stephen Kent. 2012. An Infrastructure to Support Secure Internet Routing. RFC 6480. doi:10.17487/RFC6480

    work page doi:10.17487/rfc6480 2012

  16. [16]

    Microsoft Azure. 2025. Post Incident Review: Azure Front Door Outage. Azure Status History. https://azure.status.microsoft/en-us/status/ history/

    work page 2025

  17. [17]

    Mockapetris

    P. Mockapetris. 1983. Domain names: Concepts and facilities. RFC

    work page 1983

  18. [18]

    doi:10.17487/RFC0882

    work page doi:10.17487/rfc0882

  19. [19]

    Mockapetris

    P. Mockapetris. 1983. Domain names: Implementation specification. RFC 883. doi:10.17487/RFC0883

    work page doi:10.17487/rfc0883 1983

  20. [20]

    Giovane C. M. Moura, Sebastian Castro, John Heidemann, and Wes Hardaker. 2020. Clouds, Caches or Unicast? Characterizing DNS Re- solver Centralization. InProceedings of the ACM Internet Measurement Conference (IMC ’20). ACM. doi:10.1145/3419394.3423625

    work page doi:10.1145/3419394.3423625 2020

  21. [21]

    Tommy Pauly, David Schinazi, Alex Chernyakhovsky, Mirja Küh- lewind, and Magnus Westerlund. 2023. Proxying IP in HTTP. RFC

    work page 2023

  22. [22]

    doi:10.17487/RFC9484

    work page doi:10.17487/rfc9484

  23. [23]

    Jon Postel. 1981. RFC791: Internet Protocol

    work page 1981

  24. [24]

    Jon Postel. 1981. RFC793: Transmission Control Protocol

    work page 1981

  25. [25]

    J. H. Saltzer, D. P. Reed, and D. D. Clark. 1984. End-to-end arguments in system design.ACM Trans. Comput. Syst.2, 4 (Nov. 1984), 277–288. doi:10.1145/357401.357402

    work page doi:10.1145/357401.357402 1984

  26. [26]

    David Schinazi. 2022. Proxying UDP in HTTP. RFC 9298. doi:10. 17487/RFC9298

    work page 2022

  27. [27]

    Schwartz, Mike Bishop, and Erik Nygren

    Benjamin M. Schwartz, Mike Bishop, and Erik Nygren. 2023. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). RFC 9460. doi:10.17487/RFC9460

    work page doi:10.17487/rfc9460 2023

  28. [28]

    2026.Proxying Ethernet in HTTP

    Alejandro Sedeño. 2026.Proxying Ethernet in HTTP. Internet-Draft draft-ietf-masque-connect-ethernet-09. Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-ietf-masque-connect- ethernet/09/ Work in Progress

    work page 2026