MLB Advanced Media DH, LLC's Two-TLD Control Surface: Delegation

Summary

MLB Advanced Media DH, LLC is the exact current directory company entity and the sponsoring organisation recorded by IANA for both .baseball and .mlb.[1][2][3]
The two delegations expose live DNS, DNSSEC and RDAP control surfaces, but public records and bounded observations do not reveal private architecture or establish longitudinal reliability.
ICANN agreements, renewals, data escrow and emergency-operation mechanisms define continuing responsibilities rather than proving that an outage occurred or a service objective was achieved.[7][8][9][10][16][17]
Supervision, integration, maintenance and exception handling remain recurring costs across authority, keys, delegation, registration data, suppliers, recovery and evidence quality.

Image note: The accompanying Creative Commons photograph shows a generic networking rack and cabling. It provides network-control context only. It does not depict MLB Advanced Media DH, LLC, either TLD registry system, a company facility, a backend service, a customer deployment, an incident, measured reliability or a production outcome.

MLB Advanced Media DH, LLC has a public technical role that is narrower and more consequential than the familiar consumer meaning of the MLB brand. The current BTW directory identifies the company as an existing entity, while IANA's root-zone records name it as the sponsoring organisation for both .baseball and .mlb.[1][2][3] Those records place the company on a control surface that connects corporate authority, root-zone delegation, authoritative DNS, DNSSEC, registration data, data escrow, emergency continuity, and contracted service obligations.

That role should not be confused with ownership of the DNS root or with general authority over the Internet. A top-level-domain registry operator manages a bounded namespace under recorded agreements and shared technical processes. IANA maintains delegation records. ICANN administers contractual obligations. Registrars, registry service providers, DNS operators, certificate authorities, network providers, and registrants each control other parts of the end-to-end path. A registry is an accountable operator inside a distributed system, not a sovereign.

The public record also does not disclose MLB Advanced Media DH, LLC's complete private architecture. IANA names GoDaddy Registry as the technical contact for both delegations.[2][3] Live RDAP responses identify Registry Services LLC or its designated representatives in their terms of service.[12][13] These facts show visible role boundaries. They do not prove an exclusive supplier arrangement, a specific backend topology, private staffing, incident history, capacity, uptime, or the way every operational responsibility is allocated.

The distinction matters because a TLD can look simple from the outside. A user types a name ending in .baseball or .mlb; a resolver asks the DNS; an application receives an answer. Behind that exchange sit several records and state machines. The root must contain the intended delegation. Parent and child DNSSEC data must remain coherent. Authoritative servers must be reachable over the expected transports. RDAP discovery and responses must preserve entity meaning. Registrars and registry systems must agree about names and statuses. Escrow deposits and emergency arrangements must remain usable if normal operation fails.

The IANA delegation reports show that both strings completed recorded eligibility, contact-confirmation, technical-conformance, and other processing steps before delegation.[4][5] The .baseball and .mlb registry agreements then set out continuing duties that include registry services, data escrow, registration-data services, interoperability, reporting, continuity, and transition provisions.[7][8] Renewal documents published in 2025 provide evidence of contractual continuity, not evidence that every technical outcome has been perfect.[9][10]

The live control surface was observable during this research. IANA listed multiple authoritative nameservers for each TLD, RDAP service endpoints for both, and a WHOIS service for .baseball.[2][3] Independent DNS queries returned the expected a.nic, b.nic, and c.nic server set for each TLD and found DS records in the parent. The IANA RDAP bootstrap file mapped both TLDs to their service family.[11] Direct queries for nic.baseball and nic.mlb returned structured domain entities, status values, events, nameservers, and signed-delegation data.[12][13] Those observations establish that specified interfaces answered at a particular time. They are not a longitudinal availability study.

This report therefore asks an operating question rather than a branding question: what work is required to keep two delegated namespaces aligned across records, running services, suppliers, policy, and recovery over time?

The answer is not a single platform feature or annual fee. It is a combination of supervision cost, integration cost, maintenance cost, and exception-handling cost. Those costs exist in ordinary operation and become visible during rare changes or failures. The evidence supports analysis of responsibilities and observed interfaces. It does not support invented benchmarks, fabricated customer stories, private architecture, or claims that either TLD produced a particular commercial result.

The featured photograph shows a generic networking rack and cabling. It does not show MLB Advanced Media DH, LLC, .baseball, .mlb, a registry facility, a backend service, or a customer system. It provides visual context for physical network dependencies only.

The exact company and delegation identities

Identity is the first control. The directory entity, IANA root-zone records, delegation reports, and registry agreements need to refer to the intended legal and operational parties without collapsing distinct names into one.

The current directory entry is MLB Advanced Media DH, LLC.[1] IANA lists the same name and a New York address as the sponsoring organisation for .baseball and .mlb.[2][3] The administrative contact in those records is labelled MLB Advanced Media, L.P., while the technical contact is GoDaddy Registry. That difference is meaningful. It shows that the sponsoring organisation, an administrative role, and a technical role are separately recorded. It does not establish the current corporate relationship among every named party or the private division of work.

IANA records .baseball as registered in the root-zone database on September 29, 2016, with a delegation report dated October 28, 2016.[2][4] The report identifies MLB Advanced Media DH, LLC as the proposed manager and records completion of the New gTLD process, confirmation that the applicant matched the contracted party, contact confirmations, technical conformance, and other procedural requirements.[4]

IANA records .mlb with a registration date of May 5, 2016 and a delegation report dated May 20, 2016.[3][5] That report similarly names MLB Advanced Media DH, LLC and records eligibility, an applicant match, confirmed contacts, technical conformance, and completed processing.[5] The two strings therefore share a sponsor but have separate root entities, separate reports, separate zones, separate security data, and separate service endpoints.

The ICANN agreement index for .mlb identifies MLB Advanced Media DH, LLC as operator and gives an agreement date of May 21, 2015.[6] The full agreements for .baseball and .mlb designate the company as registry operator for the respective TLD, subject to delegation and the agreement's terms.[7][8] They include duties that extend beyond publishing a brand website. The operator must maintain defined registry functions and work within procedures for registrar access, data escrow, reporting, registration data, security, continuity, and transition.

These documents are evidence of recorded responsibility. They are not an ownership map of the DNS root. IANA's database is a ledger of delegation facts and contacts. ICANN's agreements are contractual control documents. The registry operator is responsible for a bounded namespace. Root-zone publication, registrar transactions, backend execution, recursive resolution, network transport, and applications remain distributed among multiple actors.

This separation should appear in any operational asset register. A useful register would preserve at least:

the exact legal operator name for each TLD;
the IANA delegation entity and its change history;
the ICANN agreement and renewal records;
administrative, technical, abuse, and emergency roles;
the authoritative nameserver and glue set;
DNSSEC key and parent DS state;
RDAP and any WHOIS service endpoints;
backend, escrow, monitoring, and registrar dependencies;
the people authorised to request, approve, and verify changes.

Treating all those items as "the MLB domain" would hide authority boundaries. Treating them as unrelated would hide dependencies. The right model links them while preserving the meaning and owner of each record.

Two namespaces, not one duplicated product

The two TLDs have parallel public shapes, but parallel is not identical. IANA lists a.nic.baseball, b.nic.baseball, and c.nic.baseball plus three ns*.dns.nic.baseball hosts in the .baseball delegation record.[2] The .mlb record lists the corresponding .mlb server names and addresses.[3] The visible patterns suggest common operating components, but the public evidence does not reveal the complete backend design or prove that every control is shared.

That uncertainty should affect change management. A team may intentionally use one procedure, provider, or platform for both TLDs. Even then, each namespace requires an explicit target. A change that is correct for .baseball can still be wrong for .mlb if a key tag, zone file, service URL, address, contact, credential, or maintenance window is copied without verification.

Shared infrastructure can reduce repeated engineering work. It can also create common-mode risk. A bad automation rule, expired credential, incorrect inventory source, or provider outage may affect both namespaces at once. Separate infrastructure can isolate failure but creates more systems to patch, monitor, test, and recover. The public sources do not establish which design applies. They do establish why the operator needs evidence for the design it actually runs.

The responsibility test is simple: could an authorised responder identify the exact intended state of each TLD without relying on memory? That state should cover delegation, DNSSEC, registration-data discovery, access authority, escrow, supplier contacts, and recovery procedures. If the answer is no, visual similarity between the TLDs becomes a source of risk rather than efficiency.

The 2025 renewal records for .baseball and .mlb are useful continuity evidence.[9][10] They show that the contractual relationship has an updated time horizon. A renewal does not prove service availability, security quality, registration volume, or customer satisfaction. It means the operator must keep the technical and organisational controls coherent for another period. Long duration increases the importance of lifecycle ownership because people, providers, cryptographic practices, software, and corporate structures can change while the namespace must remain stable.

This is a software-lifecycle problem even though the visible entity is a domain suffix. The control plane includes code, configurations, keys, databases, APIs, legal agreements, contact records, monitoring, and human decision rights. Each element changes on a different schedule. The operational challenge is maintaining agreement among them.

Delegation as a recorded change-control boundary

The IANA reports for .baseball and .mlb document minimum steps before the strings entered the root.[4][5] Applicant identity had to match the approved or contracted party. Contacts had to confirm their details and accept responsibility. The proposed technical configuration had to satisfy conformance checks. Other procedural checks had to complete before implementation.

Those steps are important because root changes have broad consequences. An incorrect TLD delegation can affect every name beneath the suffix. The report creates an accountable record that a defined request passed a process. It does not eliminate future change risk. It also does not prove that the same configuration remains in place years later.

Present-day change control needs comparable discipline. A nameserver change should start from an approved intended state, not from whatever a dashboard happens to display. The request should identify the exact TLD, old and new server sets, glue addresses, IPv4 and IPv6 reachability, DNSSEC implications, maintenance timing, outside observation points, rollback criteria, and authorised decision makers.

Contact confirmation is not administrative ceremony. A technically correct change can stop if the authorised contact is unavailable, the account is inaccessible, or the requester's authority is ambiguous. Contact continuity needs role-owned channels, secondary escalation, periodic testing, and recovery that does not depend on one person's device.

Technical conformance is also a floor rather than a complete reliability assessment. A server can answer correctly during a test and fail under another network path, address family, resolver behavior, or later configuration. A delegation can be syntactically valid while pointing to an unintended but responsive service. Verification must compare the public result with approved intent.

The same principle applies to status records. Completion of the 2016 reports does not demonstrate continuous quality through 2026. It establishes a historical control event. Current reliability requires current observations, change records, and operational evidence.

Running DNS and the limits of a point-in-time observation

DNS is where administrative state becomes running behavior. IANA's records identify the parent-side delegation and glue information for both TLDs.[2][3] During the research window, direct DNS queries returned a.nic.baseball, b.nic.baseball, and c.nic.baseball for .baseball, and the corresponding a.nic.mlb, b.nic.mlb, and c.nic.mlb set for .mlb. DS records were also present for both.

That observation is valuable because it checks running code rather than relying only on a ledger. It demonstrates that the selected resolver path received an expected delegation and parent-side security data at a recorded time. It does not prove global reachability, every authoritative server's health, sustained latency, correct answers for every name, or the absence of an intermittent failure.

DNS has several interacting reliability dimensions:

Authority correctness. The server set in the parent must be the intended one. A responsive but unintended server is not a success.

Address-family reachability. IPv4 and IPv6 can fail independently. Monitoring only one family can report a healthy service while part of the Internet sees a different outcome.

Glue coherence. In-bailiwick server names may depend on parent-published addresses. Old or inconsistent glue can produce path-dependent failures during change.

Zone consistency. Multiple authoritative servers should serve coherent serials and data within the operator's change policy. A partial rollout can make answers depend on which server a resolver reaches.

Transport behavior. DNS commonly uses UDP, but larger or truncated responses can require TCP. RFC 7766 describes requirements and operational implications for DNS over TCP.[23] A service that answers small UDP queries but fails TCP fallback has incomplete capability.

Cache and propagation. Resolvers retain data according to time-to-live values. Old and new states can coexist during a planned transition. Operators need a model of that overlap rather than treating different answers as automatically malicious or automatically harmless.

Negative answers. Non-existence must be represented correctly. Incorrect negative caching or authenticated denial can hide a valid name or make a withdrawn name appear longer than intended.

RFC 8499 provides precise DNS terminology for roles, data, and behavior.[24] That vocabulary is operationally useful because loose language causes misdiagnosis. A registry, authoritative server, recursive resolver, stub resolver, registrar, and registrant are not interchangeable. A delegation problem is not the same as an application outage. A timeout is not the same as an authenticated negative answer.

The public delegation records name GoDaddy Registry as technical contact.[2][3] The RDAP responses also reference a registry service provider in their notices.[12][13] It is reasonable to state those recorded relationships. It is not reasonable to infer private nameserver topology, capacity, routing design, service levels, or incident performance. A provider name is a responsibility clue, not a benchmark.

Operational reliability must therefore be measured through a declared test design. A useful programme would observe every authoritative server, both address families, UDP and TCP behavior, DNSSEC validation, selected geographic and network vantage points, zone serial convergence, and the expected response set. It would distinguish a provider alert from an independent external observation and preserve enough data to explain an exception.

Even that programme would not establish a customer production outcome. A healthy TLD delegation can coexist with a failing registrar, a misconfigured second-level domain, an unavailable application, a certificate error, or a local resolver problem. End-to-end diagnosis requires evidence from each boundary.

DNSSEC: security metadata with its own lifecycle

The DS records observed for .baseball and .mlb connect each child zone's key material to the DNS root's chain of trust. The direct RDAP entities for nic.baseball and nic.mlb also reported signed delegation data.[12][13] These are signs of a deployed security mechanism, not proof that every validating query always succeeds.

RFC 4035 describes how validating resolvers use signatures and authenticated denial of existence, and how validation failures can produce a bogus result instead of a normal answer.[22] This creates a security state machine with operational consequences. Keys must be generated, protected, published, activated, rolled, retired, and recoverable. Parent DS state must align with the child's DNSKEY state during each transition.

Automation can compare records, calculate key tags, detect expiry, and simulate validation. That is system capability. Operational reliability depends on inventory accuracy, timing, access control, outside observation, and the operator's ability to stop or reverse a harmful sequence. A tool can consistently publish the wrong key if its authoritative input is wrong.

Key management also creates supervision cost. Sensitive actions need separation of duties, verified scope, and retained evidence. An operator should know who can authorise a rollover, who can access signing material, who can request a parent change, and who independently confirms the result. Emergency access should be tested without weakening routine controls.

Integration cost appears at the boundary among signing systems, authoritative DNS, monitoring, IANA change processes, and organisational approval. A format can be standard while authority and timing remain local. A DS change that happens too early or too late can interrupt validation even if each record is individually well formed.

Maintenance cost includes key ceremonies, software updates, algorithm review, certificate and credential lifecycle, monitoring rules, backup verification, and recovery exercises. Long intervals can increase risk because personnel and systems may change between repetitions.

Exception-handling cost appears when validators disagree, one address family fails, signatures approach expiry, a child key is published without a matching parent record, or a monitoring result conflicts with provider telemetry. The responder must separate cache effects, clock error, route problems, delegation state, signing state, and observation defects before acting.

No public source reviewed here documents a DNSSEC incident involving these TLDs. The failure analysis follows from the protocol and visible control surface. It should not be read as an allegation.

RDAP, WHOIS, and registration-data meaning

Registration data is the second major public control surface. IANA lists whois.nic.baseball and the authoritative .baseball RDAP service endpoint for .baseball; for .mlb, its current root record lists the authoritative .mlb RDAP service endpoint.[2][3] IANA's RDAP bootstrap file maps DNS suffixes to authoritative RDAP service locations, allowing clients to discover where a query should go.[11]

Direct requests for nic.baseball and nic.mlb returned RDAP domain entities during the research window.[12][13] Each entity identified the requested domain, carried server-prohibited status values, exposed lifecycle events, listed nameservers, and reported a signed delegation. The responses also named MLB Advanced Media DH, LLC in a registrar-role entity and carried notices about status codes, complaint mechanisms, terms of service, access limits, and data use.

The help endpoints for both services returned structured RDAP responses as well.[14][15] A help response matters because protocol clients need a defined way to learn service behavior and limitations. It remains one endpoint observation, not a full service assessment.

RFC 9082 defines the query side of RDAP, including paths for domain, nameserver, and entity lookups.[20] RFC 9083 defines JSON response structures, links, notices, events, statuses, entities, conformance declarations, and error responses.[21] Structured data is a capability improvement over free-form parsing, but structure alone does not guarantee accurate, complete, timely, or continuously available records.

ICANN's gTLD RDAP operational profile adds implementation requirements and service expectations, including secure transport, protocol behavior, response consistency, and availability across network families.[18] It turns general protocol primitives into a contracted operating surface. The public page defines requirements. It does not report how either MLB TLD performed against every requirement over time.

Registration-data reliability has several separate dimensions:

Discovery reliability: the bootstrap mapping and service URLs must remain correct.
Transport reliability: clients need working DNS, routes, TLS, and HTTP behavior.
Entity integrity: identifiers, statuses, events, links, and entities must represent the intended registry state.
Update consistency: data should change in a controlled relationship with authoritative registry transactions.
Error meaning: rate limits, absence, invalid queries, and server failures should not collapse into misleading success or empty data.
Privacy and access policy: disclosures and restrictions must follow applicable rules while preserving useful protocol semantics.
Continuity: service ownership and data must remain recoverable through provider or operator change.

The notices in the live responses expressly limit how the data may be used and state that the service may restrict high-volume access.[12][13] That means an operator building monitoring or investigative tooling cannot assume unlimited query behavior. Integration should respect service terms, use bounded request rates, cache appropriately, identify itself where required, and handle throttling as a distinct state.

The public data also illustrates a time boundary. An RDAP event can record when an entity was registered or last changed. It does not explain why a change occurred, whether an incident caused it, or whether every downstream cache updated immediately. A field is evidence of recorded state, not a narrative of operator intent.

WHOIS and RDAP should not be treated as two unrelated products if they describe the same registry entities. Where both exist, operators need consistency controls. A discrepancy may arise from update lag, normalization, privacy treatment, service ownership, or a defect. The response should identify the authoritative source and preserve the conflicting observations before correction.

Capability, reliability, and outcome are separate evidence layers

Three claim types recur in registry analysis and must remain distinct.

System capability describes what the system is designed or contracted to do. The root can delegate a TLD. Authoritative servers can answer DNS. DNSSEC can authenticate data. RDAP can return structured entities. Escrow can preserve registry data. An emergency operator can provide defined critical functions. Agreements and standards support these capability statements.[7][8][16][17][18][20][21][22][23]

Operational reliability asks whether a capability works consistently under a defined operating regime. That requires a time window, vantage points, workload, expected states, error classification, maintenance context, and repeatable measurements. A successful DNS query or RDAP entity proves that one interaction succeeded. It does not establish an uptime percentage or recovery objective.

Customer production outcome asks whether a registrant, registrar, rights holder, security team, or end user achieved a particular result. That needs evidence tied to that party: baseline, scope, measurement period, dependencies, and exclusions. None of the public sources reviewed here supplies a customer production result for the two TLDs. This report therefore does not invent one.

The separation prevents several common errors. A signed delegation is not proof that every resolver validated every answer. Multiple nameservers are not proof of independent failure domains. A current agreement is not proof of perfect service. An emergency programme is not proof that an emergency occurred. A structured RDAP response is not proof that every field is accurate. A famous brand is not proof of registry scale or adoption.

For procurement and governance, evidence should be labelled by layer. Capability evidence can come from contracts, standards, and documented interfaces. Reliability evidence should come from measurements and incident records. Outcome evidence should come from named stakeholders and controlled before-and-after analysis. Confidence in one layer must not be borrowed by another.

This discipline also improves response during failure. If DNS answers correctly but a customer application fails, the team can keep the registry layer in scope without assuming it is the cause. If RDAP returns a valid entity but a registrar transaction is wrong, the structured response becomes one piece of evidence rather than a verdict. If the root is correct but one authoritative server differs, the investigation can focus on the child service.

Four recurring operating costs

The public control surface supports a practical cost model. The costs below are not claims about MLB Advanced Media DH, LLC's private spending or staffing. They are the categories any operator must assign when maintaining comparable responsibilities.

Supervision cost

Supervision cost is the work of connecting technical action to authorised intent. It includes role assignment, access approval, change review, key custody, independent verification, incident command, evidence retention, supplier governance, and confirmation that contacts work.

Two similar TLDs make supervision especially important. A reviewer needs to know whether an action is intentionally shared or accidentally copied. The change record should name the exact suffix, environment, entity, source of truth, expected result, rollback boundary, and approvers. A generic "update both" instruction is not enough for a root or DNSSEC change.

Automation does not remove this cost. It shifts human attention toward inventory quality, policy, exception review, and authority. A deployment system can execute a change consistently; it cannot decide that the selected TLD, key, or data set reflects business and legal intent unless that intent is encoded and reviewed.

Supervision also covers restraint. An anomalous external query should trigger investigation, not an unsupported public incident claim. A contract duty should trigger control testing, not an assumption that the duty was breached. Responsible analysis preserves uncertainty until evidence narrows it.

Integration cost

Integration cost appears where authority or data crosses systems and organisations. The registry must interact with IANA and ICANN processes, registrars, backend services, authoritative DNS, RDAP and WHOIS, escrow agents, monitoring, identity systems, security responders, and zone-data access workflows.

ICANN's Centralized Zone Data Service provides a structured route for approved parties to request access to participating TLD zone files.[19] That reduces some administrative duplication but does not remove the registry's responsibility to manage approvals, data delivery, access changes, and exceptions. A central interface is one more dependency whose records must align with registry policy and technical state.

Standards reduce syntax differences but not ownership ambiguity. A valid RDAP entity can still reflect stale source data. A valid DNS message can carry unintended content. A successful registrar transaction can be followed by delayed registration-data publication. Integration controls need both format checks and semantic comparisons.

Supplier boundaries add another layer. Public records identify technical and service roles, but private allocation is not visible. The operator still needs to know who can change which component, who observes it independently, how evidence is exchanged, and what happens when the normal support channel is unavailable.

Maintenance cost

Maintenance cost preserves capability over time. It includes software and dependency updates, authoritative-server lifecycle, DNSSEC key management, TLS certificates, access reviews, role changes, database care, backups, escrow deposits, recovery exercises, monitoring updates, documentation, and contract-linked procedures.

Much of this work is invisible when successful. A certificate is renewed before expiry. A signing key rolls without validation failure. A retired employee loses access. An emergency contact responds during a test. An escrow deposit validates. A restored database reconciles with a known point in time. These actions create continuity rather than a new feature.

Infrequent procedures can be harder than routine ones. Staff, platforms, and suppliers may change between key ceremonies, root updates, provider transitions, or recovery tests. A runbook can remain readable while becoming technically obsolete. Maintenance must test usable state, not merely the existence of documentation.

Renewal extends this obligation.[9][10] A longer contract horizon is not a reason to defer lifecycle work. It increases the chance that multiple generations of software, keys, contacts, and organisational structures will need to preserve the same namespace.

Exception-handling cost

Exception-handling cost is the experienced work required when observed state does not match the normal path. Examples include partial DNS propagation, one-family reachability, inconsistent zone serials, DNSSEC validation failure, a stale RDAP event, rate limiting, a rejected change request, missing authority, a failed escrow validation, or a supplier report that conflicts with outside observation.

These cases are expensive because several plausible causes can produce similar symptoms. A timeout might originate in routing, firewall policy, server load, TCP fallback, resolver behavior, or monitoring. A bogus DNSSEC response might originate in parent state, child state, signature timing, clock error, cache, or key handling. A registration-data discrepancy might be source lag, privacy transformation, endpoint selection, or an incorrect transaction.

Exception handling needs a decision tree and evidence preservation. The responder should capture timestamps, queried entities, resolver and network context, authoritative responses, relevant changes, ownership, and the difference between expected and observed state. Repeating the same action without narrowing the cause can make recovery harder.

The four costs reinforce one another. Weak maintenance creates more exceptions. Poor integration obscures their origin. Weak supervision lets a local error cross both TLDs. Inadequate exception handling turns a bounded inconsistency into a prolonged outage or an inaccurate public statement.

Escrow, emergency operation, and portability

Registry continuity extends beyond ordinary service availability. The .baseball and .mlb agreements include data escrow requirements and provisions for continuity and transition.[7][8] ICANN describes registry data escrow as a mechanism for preserving registration data so critical functions can be recovered under defined conditions.[16] The Emergency Back-End Registry Operator programme provides a framework for maintaining critical registry functions if an operator cannot provide them.[17]

These mechanisms are capabilities with prerequisites. Escrow helps only if deposits are timely, complete, correctly formatted, protected, and recoverable by an authorised party. An existing file is not enough. It must be validated, decryptable, reconcilable, and tied to a known state.

Emergency operation also requires more than naming a standby provider. Authority must be established. Data and credentials must be available. Root, DNS, registration-data, and registrar-facing dependencies may need coordinated changes. The emergency operator needs enough context to avoid preserving one function while corrupting another. Stakeholders need communication that distinguishes critical registry functions from unrelated brand or application services.

The existence of EBERO does not show that it has been invoked for either MLB TLD.[17] It establishes the outer continuity boundary of the service class. The right operational lesson is to prepare for transition before that boundary is reached.

Portability is a useful control measure. An operator should be able to answer:

Can current registry data be exported and validated independently?
Can an authorised successor understand entity meaning and change history?
Can DNS and DNSSEC state be reconstructed without guessing?
Can IANA and ICANN contacts be reached if the normal portal is unavailable?
Can RDAP discovery and entity identifiers be preserved through transition?
Can registrars continue to reconcile transactions and statuses?
Can outside observers verify the recovered state?

These questions do not imply an intended provider change. They test whether operational continuity belongs to the registry operator or is trapped in undocumented supplier knowledge.

Recovery objectives also need to vary by data type. A zone, registration transaction, contact record, abuse case, and billing record do not all tolerate the same data-loss window. A single backup objective can hide unacceptable gaps. The operator should map consequence, update rate, and authoritative source for each class.

Finally, continuity includes people. Corporate reorganisation, role transfer, illness, account loss, and supplier turnover can interrupt authority even while servers remain healthy. Contact and credential recovery should be tested as part of technical continuity, not left to an administrative appendix.

Failure-mode register

The following failure modes are derived from the visible protocols, agreements, and role boundaries. They are control scenarios, not evidence that any event occurred at MLB Advanced Media DH, LLC.

1. Sponsoring-organisation identity drift

The legal operator, IANA sponsor, agreement party, and authorised account records stop matching after a corporate change. Routine service continues, but an urgent root or contract action is delayed because authority is unclear. Detection requires a periodic cross-record comparison and named owner.

2. Stale administrative contact

An email address or individual remains listed after responsibility moves. Normal automated operations hide the defect until a time-sensitive approval, abuse notice, or emergency escalation cannot reach an accountable person. A role-owned secondary channel and tested recovery reduce the risk.

3. Wrong-TLD change

A valid .baseball value is copied into a .mlb action, or the reverse. Similar naming makes the mistake look plausible. The control is an exact suffix, entity, key, and expected-state comparison at authorisation and after execution.

4. Responsive but unintended nameserver

A root change points to a server that answers DNS but is not the approved authority. Basic reachability succeeds, masking the error. Verification must compare the returned delegation and served zone with the approved change record.

5. Glue-address inconsistency

Parent-published glue differs from the operator's intended address set. Resolution becomes dependent on cache, path, or which server is queried. Both IPv4 and IPv6 glue need comparison with the authoritative inventory.

6. One-family outage

IPv4 works while IPv6 fails, or the reverse. A monitor using only one family reports success. The test programme needs independent queries over both transports and routing contexts.

7. TCP fallback failure

Small UDP answers work, but truncated or larger DNS responses cannot complete over TCP. Some query types or network paths fail selectively. Monitoring should include behavior described by RFC 7766 rather than only a minimal UDP lookup.[23]

8. Partial zone rollout

Authoritative servers publish different serials or records beyond the allowed convergence window. Users receive inconsistent answers depending on server selection. The operator needs serial monitoring, a deployment boundary, and a safe rollback or forward-fix decision.

9. Cache-transition misdiagnosis

Old and new answers coexist during a planned TTL window and are treated as an attack or uncontrolled fault. The opposite error is also possible: a real stale server is dismissed as normal caching. The change record should state expected overlap and expiry.

10. Parent-child DNSSEC mismatch

The root DS record and child DNSKEY set do not form the intended chain. Validating resolvers treat answers as bogus while non-validating paths may appear normal. Independent validation before and after each key transition is required.[22]

11. Signature-expiry boundary missed

Zone signatures approach or cross expiry because a signing or publication job fails. Static record checks can look correct until the time boundary arrives. Monitoring needs remaining-validity thresholds and an authorised emergency procedure.

12. Key-custody concentration

One account, device, or person becomes the only practical route to signing or parent-change authority. No server has failed, but recovery is blocked. Separation of duties and tested emergency access should preserve control without normalising broad access.

13. RDAP bootstrap drift

The IANA bootstrap mapping and the operator's intended endpoint diverge after a service move. Clients discover an old or wrong service even though a new endpoint works directly. The discovery chain must be tested, not just the destination.[11]

14. Valid JSON with stale meaning

An RDAP response is syntactically correct but carries an outdated status, event, link, or entity. Schema validation reports success while investigators receive misleading data. A semantic comparison with the authoritative registry state is necessary.[20][21]

15. Inconsistent registration-data services

WHOIS and RDAP expose different entity states or update at materially different times. Users cannot tell which result is authoritative. The operator needs a reconciliation rule, timestamped observations, and a correction path that preserves privacy obligations.

16. Rate-limit ambiguity

An automated client exceeds service terms and receives throttling or restricted responses that it interprets as entity absence. The notices on the live RDAP services make bounded use and explicit error handling important.[12][13]

17. TLS or discovery dependency failure

The RDAP application is healthy, but DNS, routing, certificate validation, or service discovery prevents clients from reaching it. A single application metric misses the dependency. External tests should preserve the failing layer.

18. Registrar-registry transaction divergence

A registrar believes an operation failed while the registry committed it, or the registry rejected a request that a client marks successful. Blind retry can duplicate or contradict work. Idempotency, entity-state comparison, and transaction evidence are needed.

19. Escrow deposit unusable

A deposit exists but is late, incomplete, corrupted, encrypted under inaccessible material, or inconsistent with the expected schema. File presence creates false assurance. Validation and periodic recovery exercises are the meaningful controls.[16]

20. Emergency authority unavailable

Critical services need transition, but the people or credentials able to authorise it cannot be reached. Technical standby capacity does not solve the governance gap. Emergency contact and authority tests must be part of continuity planning.[17]

21. Supplier observation accepted as final proof

A provider reports success and the operator closes the change without an independent view. A shared defect or wrong target remains invisible. Provider telemetry is useful evidence, but it should be compared with outside DNS and RDAP observations.

22. Common-mode error across both TLDs

A shared template, credential, platform, or procedure applies one bad state to .baseball and .mlb. Reuse saves effort but increases blast radius. Per-TLD scope checks and staged execution reduce the chance that similarity becomes correlated failure.

23. Zone-data access ownership gap

An approved request, revocation, or delivery problem in the centralized zone-data workflow has no clear owner. Security, legal, and registry teams each assume another team is handling it. The role map should cover approval, transfer, audit, and exception paths.[19]

24. Contract renewal mistaken for technical assurance

A current renewal document is treated as evidence of measured uptime, security, or customer success. Contract continuity is valuable, but it belongs to a different evidence layer. Reliability and outcomes still require their own measurements.[9][10]

25. Brand reputation substituted for registry evidence

The familiarity of MLB creates an assumption that the registry must have scale, high adoption, or a particular architecture. None of those conclusions follows from the sources here. Operator decisions should use entity-level evidence, not brand halo.

26. Generic image treated as facility evidence

A photograph of networking equipment is read as a depiction of the company's systems. The selected image is generic and carries no such evidentiary value. Captions and surrounding text must keep that boundary explicit.

What operators and counterparties should verify

The public record is strong enough to define verification questions without pretending to know private answers.

For identity and authority

Do the legal operator, IANA sponsor, ICANN agreement party, and account permissions still align for each TLD?
Are administrative, technical, abuse, security, and emergency roles assigned to current role-owned channels?
Can a secondary authorised person recover access and prove authority when the normal path is unavailable?

For delegation and DNS

Does the root contain the approved nameserver and glue set for each suffix?
Are every authoritative server and both address families reachable from independent networks?
Do UDP and TCP behavior, zone serials, negative answers, and response data match the declared state?
Does the monitoring programme distinguish delegation, authoritative service, recursive resolution, and application failures?

For DNSSEC

Do parent DS and child DNSKEY state form the intended chain now and throughout planned rollovers?
Are signing material, change authority, recovery credentials, and audit evidence separately controlled?
Are signature validity, key lifecycle, algorithm support, and validation results monitored with enough lead time to act?

For registration data

Does IANA bootstrap discovery lead to the intended RDAP service for both TLDs?
Do RDAP identifiers, statuses, events, links, entities, and notices reconcile with authoritative registry state?
Where WHOIS is exposed, is its meaning consistent with RDAP after accounting for protocol and privacy differences?
Are throttling, malformed queries, entity absence, and server failures classified distinctly?

For suppliers and integration

Which party can change DNS, DNSSEC, RDAP, registry data, escrow, and registrar interfaces?
Which party independently verifies each change?
Are service contacts, escalation paths, data exports, and transition rights current and tested?
Can the operator diagnose a fault without relying on one supplier's dashboard?

For continuity

Are escrow deposits validated rather than merely delivered?
Can a recovery exercise reconstruct an authoritative and internally consistent state?
Are emergency authority, root-change access, data, credentials, and communications available together?
Can critical functions move while preserving identifiers, statuses, and the same accountable Article of authority?

For evidence quality

Is each assertion labelled as system capability, operational reliability, or customer production outcome?
Are time-bounded observations reported with their limits?
Are missing private facts left unknown rather than filled with vendor assumptions?
Are image, brand, and contract records kept from implying technical results they do not prove?

These questions expose the real operating model. A mature answer may involve several organisations, but it should not involve ambiguity about authority, intended state, evidence, or the next decision.

Conclusion

MLB Advanced Media DH, LLC's public registry role is concrete. IANA names it as sponsoring organisation for .baseball and .mlb; delegation reports record eligibility and technical-conformance steps; ICANN agreements and renewals define continuing obligations; live DNS, DNSSEC, and RDAP observations expose a working control surface at a bounded time.[2][3][4][5][7][8][9][10][11][12][13]

The evidence does not reveal private architecture, measured reliability, registration volume, customer production outcomes, or incident performance. That limit is part of the finding, not a gap to fill with conjecture.

The operational burden lies in maintaining agreement among ledgers, running systems, suppliers, security metadata, and human authority. Supervision cost keeps action tied to intent. Integration cost preserves meaning across boundaries. Maintenance cost keeps rare and routine controls usable. Exception-handling cost contains divergence without turning uncertainty into an invented story.

For two related TLDs, the central test is not whether the public interfaces look similar. It is whether each namespace has an exact owner, declared state, independently observable execution, and recoverable continuity. That is the reality layer behind a branded domain.