Summary

  • IANA identifies Jones Lang LaSalle Incorporated as the sponsoring organisation for both .jll and .lasalle, establishing a live DNS and registry control surface tied to the company.
  • ICANN publicly classifies .jll under Brand Specification 13 while the .lasalle agreement is shown as Base and Non-Sponsored, so shared ownership does not prove identical contract controls or reliability.

Jones Lang LaSalle Incorporated, commonly known as JLL, is accountable for two strings in the public Domain Name System: .jll and .lasalle. IANA's current delegation records identify the company as the sponsoring organisation for both. ICANN's contract pages also identify Jones Lang LaSalle Incorporated as the registry operator. Those facts establish a real network-control surface tied to the existing company, not a hypothetical branding exercise.

The two strings should not, however, be described as contractually identical. ICANN identifies .jll as a Brand top-level domain under Specification 13. Its public policy material describes centralized eligibility, registration, revocation, DNS-integrity, registrar, WHOIS, transfer, and internationalized-domain-name controls. ICANN's public .lasalle contract index identifies that string as Base and Non-Sponsored without showing the same Brand designation. Both are corporate TLDs controlled by the same accountable company, but the public contract metadata does not justify collapsing their legal and policy characteristics into one label.

That distinction matters because registry technology is not only a capability. A delegation proves that a string exists in the root and that named parties occupy accountable roles. A contract describes obligations. A readiness report records a gate passed at a particular time. None of those items, by itself, proves current availability, measured latency, successful failover, perfect registration-data accuracy, or a customer production result. Product reliability must be evaluated through the controls that keep the running system correct over time, while customer production outcomes require separate evidence that is not present here.

The cost model is similarly layered. Supervision cost appears in ownership, vendor oversight, policy approval, compliance, security governance, and recovery accountability. Integration cost appears where company identity, registrar workflow, registry services, DNS, WHOIS or RDAP, escrow, security monitoring, and incident management meet. Maintenance cost appears in contact accuracy, nameserver and delegation changes, certificate and domain lifecycle work, policy updates, continuity tests, evidence retention, and third-party coordination.

Exception cost appears when an unauthorized registration, stale record, routing or DNS fault, vendor outage, security event, legal request, or recovery failure crosses those boundaries.

The public evidence supports a grounded conclusion: .jll and .lasalle are small in visible scope but operationally real. They turn corporate naming into a chain of running records whose value depends on uniqueness, accuracy, secure change control, and continuity. Their existence says little about commercial adoption. Their reliability depends on repeated work that is easy to overlook precisely because successful DNS is normally quiet.

Two Delegated Strings, One Accountable Company

IANA's root database is the cleanest starting point because it records what is actually delegated. The .jll page names Jones Lang LaSalle Incorporated as sponsoring organisation and shows administrative and technical contacts, authoritative nameservers, WHOIS and RDAP services, and record dates. The .lasalle page does the same for its string. These entries are operational records, not marketing descriptions. They locate responsibility in the root's delegation chain and identify the services by which registration information can be queried.

The identity link is important. A company can use ordinary second-level domains without controlling the top-level registry. Here, the company entity is directly tied to two TLD delegations. That makes the subject suitable for a technology-company analysis focused on DNS, registry governance, network identity, and operational continuity. The inquiry is not whether a real-estate-services company is broadly "digital." It is how a named corporation carries accountability for two scarce, globally unique identifiers in the public namespace.

The .jll IANA record shows that the string was registered in 2015. IANA's delegation report records that the applicant matched the contracted party and completed the required contact and technical-conformance processing before delegation. The corresponding .lasalle report records a similar delegation process for that string. These reports establish a historical control point: before entry into the root, the proposed registry had to pass a defined gate.

That gate is meaningful, but bounded. It does not state that every later configuration was correct. It does not measure availability in 2026. It does not reveal how many second-level names are active, what applications rely on them, or whether users recognize them. It does not show an internal architecture. It also does not establish that JLL employees directly operate every authoritative server. The present IANA records identify technical roles and services; they do not turn accountability into proof of in-house execution.

The two strings also correspond to different corporate identity layers. .jll matches the company's widely used abbreviated brand. .lasalle corresponds to the LaSalle name within the wider corporate identity. That creates a governance question beyond simple string ownership: which business units may request names, which names are authorized, what records may be published, who approves revocation, and how the company prevents one identity domain from drifting away from the other.

Even a limited registration universe needs durable answers. DNS resolvers do not understand organizational ambiguity. A label either delegates correctly or it does not. A nameserver either returns usable data or it does not. A registration-data service either presents the expected record or it does not. Corporate intent must therefore be translated into exact machine-readable state, and the translation must remain correct through reorganizations, vendor changes, staff turnover, security incidents, and ordinary maintenance.

The Contractual Asymmetry Between .JLL and .LASALLE

It is tempting to call both strings "brand TLDs" because one company controls both and both correspond to company names. The public ICANN metadata requires more care. ICANN's .jll registry-agreement index explicitly marks the string as Brand under Specification 13. The accompanying policy application explains a restricted governance model in which registration eligibility, registrar use, name allocation, revocation, DNS integrity, WHOIS, transfers, and internationalized names are centrally controlled.

The .lasalle contract index identifies Jones Lang LaSalle Incorporated as registry operator but labels the agreement Base and Non-Sponsored. The public page does not display the same Specification 13 Brand classification. That does not mean .lasalle is open to anyone, nor does it prove how registrations are allocated in practice. It means the public evidence supports a narrower description: .lasalle is a corporate-controlled TLD under its published agreement, while .jll has the additional publicly identified Brand status.

This asymmetry is not a footnote. Contract type influences the evidence needed to understand registration eligibility, change rights, compliance, and exceptional handling. If an analyst assumes both strings share every policy provision, the resulting control map may be wrong. A registrar workflow that is valid for one string may not automatically describe the other. A policy exception in one agreement may not exist in the other. A recovery plan that treats the pair as one undifferentiated service may miss contract-specific responsibilities.

The shared parts remain substantial. Each agreement sets expectations around registry services, DNS operation, registration data, escrow, continuity, interoperability, and compliance. Each string must continue to fit within the root and registrar ecosystem. Each has an accountable operator. Each presents change-management and security responsibilities. But shared obligation categories do not eliminate differences in policy or legal treatment.

This is a useful example of why corporate infrastructure should be read at the record level. A high-level portfolio diagram might draw two boxes under "brand domains." The reality layer is more exact: two root delegations, two public agreement records, two histories, potentially distinct registration policies, and a set of technical services whose current state can be queried independently. Reliable governance begins by preserving those differences.

The same principle applies during incidents. If a fault affects only .lasalle, operators need to know which agreement, contacts, nameservers, registrar relationships, and recovery procedures govern that string. If a policy change applies only to .jll, it should not be propagated automatically to .lasalle without verification. Shared ownership can simplify escalation, but it can also create a false expectation of identical behavior. Good supervision uses the common company identity as an accountability anchor while keeping the two operational records distinct.

Delegation Readiness Is a Gate, Not a Reliability Benchmark

IANA's delegation-process reports and the new-gTLD readiness material provide evidence of pre-delegation review. For .jll, the published readiness report refers to evaluation of DNS stability, registry services, financial capability, and technical and operational capability. The delegation reports for .jll and .lasalle record applicant identity and technical-conformance checks. Passing those gates was necessary for the strings to enter the root.

The evidence should not be stretched into a current benchmark. A readiness review answers whether a proposed registry met specified conditions at that time. Product reliability asks whether the running system continues to meet operational needs after years of software updates, personnel changes, supplier changes, new threats, policy revisions, and ordinary configuration work. The first is a point-in-time admission decision. The second is a continuing property.

This distinction prevents several unsupported claims. A passed readiness review does not prove a particular uptime percentage. It does not prove that DNSSEC, if deployed at a given layer, has never been misconfigured. It does not prove that recovery time has been measured under current dependencies. It does not prove that all registration data has always been accurate. It does not prove that no security incident has affected the service. It does not establish customer satisfaction or economic return.

What the review does provide is a baseline for accountability. The operator could not reasonably treat the registry as an informal website feature after passing a formal delegation gate. Entry into the root creates a long-lived obligation to preserve uniqueness, service continuity, and accurate records. The technical and organizational capabilities considered during delegation must be converted into recurring operations.

That conversion is where much of the hidden cost sits. A control that existed for an application may need updating when a vendor changes. A contact that was accurate in 2015 may need replacement. A test plan may become stale after infrastructure migration. A registrar relationship may need new credentials or security controls. A recovery assumption may fail when an upstream dependency changes its interface. None of those changes invalidates the original gate, but each can reduce present reliability if left unmanaged.

An effective diligence process therefore asks two separate questions. First, what was required and demonstrated for delegation? Second, what evidence shows that those capabilities remain operational now? The public record answers much of the first and only part of the second. Current IANA delegations show that both strings remain in the root and expose current nameserver and registration-data information. They do not provide the full operating evidence that an internal reviewer would need.

The Running DNS and Registration-Data Control Surface

A corporate TLD is a layered system. At the top is the root delegation, which points resolvers toward authoritative nameservers. Below that sits the registry's authoritative data for the TLD. Registration records connect names to registrants, contacts, statuses, and lifecycle events. WHOIS and RDAP expose defined registration information. Registrar processes create, update, renew, transfer, suspend, or delete names according to policy. Security and continuity controls surround each layer.

The IANA pages make part of this system visible. They show the sponsoring organisation and listed nameservers. They also identify WHOIS and RDAP endpoints. The contract texts describe broader service obligations, including DNS service, registration-data publication, escrow, interoperability, and continuity. These are not decorative fields. They are mechanisms for keeping a unique namespace usable and accountable.

Root-zone accuracy is the first dependency. A correct internal registry configuration cannot compensate for a broken root delegation. Conversely, a correct root delegation cannot compensate for unavailable or incorrectly configured authoritative service below it. A resolver follows the running chain. Organizational charts, contracts, and brand guidelines matter only insofar as they produce consistent records along that chain.

Registration-data accuracy is another control surface. A corporate registry may have a narrow set of eligible registrants, but narrow eligibility does not remove lifecycle work. Records still need correct status, ownership, contact, and delegation information. Changes need authorization. Old names may need revocation or redirection. Security teams need a reliable way to distinguish legitimate use from abuse or stale configuration. Legal and compliance teams may need evidence of who approved a name and under what policy.

WHOIS and RDAP should be understood as record interfaces, not guarantees of organizational truth. The service can accurately publish what the registry database contains while the underlying business ownership has become stale. A business unit can change names while a domain remains active. A technical contact can leave. A vendor can change. A legal entity can reorganize. Preventing that drift requires synchronization between company records and registry records.

Registrar control is equally important. The .jll Brand policy describes centralized registrar and eligibility arrangements. That can reduce the number of external actors, but concentration shifts the risk rather than eliminating it. Credentials, authorization rules, change approval, separation of duties, and emergency access become more important when a small set of people or systems can change high-impact names.

Technical-provider dependencies add another layer. IANA identifies technical roles in the delegation data, and the contract framework allows operational functions to be performed through specialized providers. Outsourcing can provide expertise and resilient infrastructure. It also creates integration and supervision obligations. JLL remains the named operator in the public contract. It needs to understand what the provider operates, what evidence the provider supplies, how changes are authorized, how incidents are escalated, how data is preserved, and how service can continue or transfer if the relationship changes.

The resulting system is best viewed as a chain of authoritative records and executable controls. The registry is a recordkeeper within the DNS hierarchy, not a sovereign authority over the wider internet. Its legitimacy comes from accurate operation of its assigned namespace, adherence to the agreement, secure maintenance, and continuity. The running code and current records matter more than broad claims about ownership.

What JLL Controls and What It May Delegate

Accountability and execution are not the same thing. Jones Lang LaSalle Incorporated is the registry operator named by ICANN for both strings. That places the company at the center of policy, contract, and risk accountability. It does not establish that the company builds or operates every registry component, nameserver, registrar interface, escrow process, or registration-data service with its own personnel.

The practical control surface can be divided into four areas. First is policy control: deciding who may obtain a name, which uses are allowed, what approvals are required, and when a name may be revoked. Second is identity control: mapping company units, brands, services, and responsible people to domain records. Third is technical control: ensuring DNS, registry services, registration-data interfaces, security controls, and continuity mechanisms work. Fourth is contractual control: supervising providers and meeting obligations to ICANN and the wider ecosystem.

Some activities can be delegated to a provider, but accountability cannot simply be outsourced. If a provider changes a nameserver, JLL still needs an authorized change record. If a registration-data service becomes stale, the company needs a route to correct it. If a registrar account is compromised, the company needs incident ownership and recovery authority. If a supplier exits, the registry needs data portability and an executable transition plan.

This division also shapes evidence. A provider dashboard can show service metrics, but those metrics need interpretation and retention. A company approval system can show who authorized a name, but it may not prove the corresponding registry change completed. A contract can require continuity, but it does not prove that a current recovery exercise passed. Reliable supervision reconciles these evidence types rather than treating any one of them as complete.

Policy control can create its own failure modes. An overly permissive workflow can allow names inconsistent with eligibility rules. An overly restrictive workflow can prevent an urgent security or continuity change. A manual approval can be clear but slow. Automation can be fast but reproduce a stale entitlement. The right design depends on the small number of high-impact actions and the need for traceable exceptions.

Identity control is especially sensitive for a global company with many business lines and offices. The public evidence supports JLL's large operating scope, but it does not reveal the internal inventory of .jll or .lasalle names. The defensible inference is narrower: any active portfolio needs an owner, purpose, lifecycle state, and technical contact. Without those fields, a corporate namespace can accumulate records whose business meaning is unclear even while DNS continues to answer.

Technical control is also broader than nameserver availability. It includes data accuracy, access control, key and credential management, monitoring, capacity, change windows, software lifecycle, dependency tracking, and recovery. Contractual control adds audit rights, service expectations, notification rules, evidence access, data return, and exit assistance. The company must integrate all four areas into one operating model.

Capability, Product Reliability, and Customer Production Outcomes

Capability, Product reliability, and customer production outcomes are different claims and should be reported separately.

Capability is the easiest to establish from the public evidence. JLL has two delegated corporate TLDs. IANA shows current root entries and service endpoints. ICANN shows the operator agreements. The .jll material describes a Brand-governance policy and the kinds of controls contemplated for registration and DNS integrity. Delegation and current records demonstrate that the namespace capability exists.

Product reliability is harder. Reliability concerns how consistently the capability behaves under normal change, unexpected demand, supplier problems, software defects, security events, and recovery conditions. The agreements impose categories of obligation, and JLL's broader continuity and technology-recovery documents describe company-wide governance concepts such as ownership, criticality, vendor dependency, recovery objectives, testing, and exception remediation. Those materials make reliability governance analyzable, but they are not measured TLD service results.

A credible reliability assessment would need current evidence such as authoritative-DNS availability, response correctness, registry-service health, change success rates, registration-data accuracy, incident records, recovery exercises, dependency inventories, and unresolved exceptions. None of those measurements should be invented. The public pages confirm the control surface and its obligations, not its observed performance.

Customer production outcomes are harder still. A customer result would connect the TLD to a real external or internal user's production use and show an outcome such as reduced fraud, improved navigation, faster deployment, better availability, lower operating cost, or measurable trust. The cited sources do not provide that chain. They do not identify a customer production deployment dependent on .jll or .lasalle, and they do not quantify a business result caused by either string.

That absence is not a finding that the strings have no value. It is a boundary on what can be reported. A corporate TLD can have identity, governance, security, or strategic option value even if public usage is limited. It can also impose recurring cost despite little visible traffic. The correct conclusion is that the public record supports capability and accountability, offers partial evidence about reliability governance, and does not establish customer production outcomes.

Keeping the three layers separate improves decision-making. Executives can decide whether the capability remains strategically useful. Operators can assess whether reliability evidence is sufficient. Business owners can decide whether specific uses justify the cost. Combining the layers would let a delegated string masquerade as proof of value or let a contract masquerade as proof of service quality.

Supervision Cost

Supervision cost begins with named accountability. Someone must own the .jll agreement, someone must own .lasalle, and someone must reconcile the two with corporate identity, security, legal, procurement, risk, and continuity functions. The company may assign day-to-day technical work to providers, but it still needs people capable of interpreting evidence and making high-impact decisions.

Vendor oversight is a recurring component. A registry technical provider, registrar, DNS operator, escrow agent, monitoring service, certificate authority, or security platform can sit in the dependency chain. The company needs current contacts, service boundaries, escalation paths, evidence rights, and transition terms. A service-level report is useful only if an owner reviews exceptions and understands whether the metric covers the actual critical path.

Contract supervision adds another cost. ICANN obligations can change through amendments, consensus policies, or operational notices. The company must determine which changes affect each string and whether the .jll Brand designation creates requirements or freedoms different from .lasalle. Legal interpretation has to reach technical configuration. A policy update that remains in a document but never changes the running system is not effective governance.

Security oversight adds identity and access work. Registrar and registry access should be limited, reviewed, and recoverable. Emergency access must be possible without normalizing broad privilege. High-impact changes need traceability. Contact details in public or contractual records need review. Supplier security and incident reporting need a responsible owner. These tasks recur even when no incident occurs.

Continuity oversight requires more than a document. Owners need to know which services are critical, what recovery objectives apply, which dependencies can block recovery, who declares an incident, where current procedures live, and what evidence a test produced. JLL's company-wide continuity and technology-recovery materials describe an organized approach to critical systems and vendor dependencies. They do not prove TLD-specific execution, but they identify the governance categories that a TLD owner should connect to the namespace.

Supervision cost often looks small because each individual task is intermittent. The cumulative load is material: quarterly access reviews, annual contract checks, vendor meetings, contact verification, recovery exercises, exception tracking, certificate and domain reviews, policy decisions, risk reporting, and audit response. A realistic ownership model budgets for the whole cycle rather than only the visible DNS invoice.

Integration Cost

Integration cost appears wherever one record system must agree with another. A business unit's approved service name must match the registrar request. The registrar action must create the expected registry entity. The registry must publish correct delegation data. DNS changes must match application and certificate configuration. Registration-data services must reflect the lifecycle state. Monitoring must know what to test. Incident tooling must route alerts to people with authority to act.

The .jll Brand policy illustrates why policy integration matters. Central eligibility and registrar control can make the namespace easier to govern, but only if the company entitlement system and the registry workflow agree. When a team is reorganized or a service is retired, business ownership must propagate to domain ownership. If it does not, the registry can remain technically correct while organizational accountability becomes false.

The two-TLD portfolio adds mapping work. A service may belong under .jll, .lasalle, an ordinary second-level domain, or more than one of them. Consistent selection rules reduce confusion and duplicated controls. Without those rules, teams can build parallel names with different owners, certificates, redirects, monitoring, and retirement dates.

Security integration is another recurring burden. DNS changes can interact with certificates, email authentication, web application security, identity providers, and traffic routing. A registry or registrar change can be technically valid but operationally harmful if dependent systems are not ready. Change review therefore needs a dependency view broader than the TLD itself.

Recovery integration is difficult because each provider may expose a different interface and escalation model. A company recovery plan may restore applications while DNS remains stale, or restore DNS while authentication and certificates remain unavailable. The cited JLL recovery material discusses criticality, recovery objectives, vendors, testing, and remediation at a company level. A TLD-specific plan would need to translate those concepts into the exact registry, registrar, DNS, registration-data, and application dependencies for the two strings.

Integration also has an evidence cost. A change ticket may show approval, a registrar log may show submission, and a DNS observation may show the resulting state. Reliable review needs all three. If evidence is fragmented across suppliers and company systems, incident reconstruction becomes slower. A small namespace can justify a simple evidence model, but it still needs one.

Maintenance Cost

Maintenance cost is the price of preventing gradual divergence. Delegation records, nameserver addresses, contacts, RDAP or WHOIS endpoints, registrar accounts, policy documents, access lists, recovery procedures, monitoring targets, certificates, and domain inventories all age. Most failures are not caused by the original design being impossible. They emerge because the environment changed while one dependency did not.

Contact accuracy is a basic example. The IANA records expose administrative and technical roles. If a named person, team, address, telephone number, or escalation route changes, the public and contractual records may need updating. Stale contact data can turn an ordinary incident into an extended one because the right party cannot be reached or authenticated quickly.

Software lifecycle creates another burden. Registry and DNS providers update platforms, protocols, APIs, and security controls. Client tools and monitoring integrations also change. A feature that once worked can become deprecated. A certificate or credential can expire. A firewall or allowlist can retain an obsolete endpoint. Maintenance requires dependency inventory and controlled replacement, not merely renewal of the registry agreement.

Domain lifecycle work continues even in a restricted namespace. Names are created, changed, redirected, suspended, and retired. Each action should preserve ownership and purpose. Retired services need a decision about deletion, defensive retention, redirection, or continued monitoring. Leaving old records active can create security and confusion risks; deleting them without checking dependencies can break production use.

Policy maintenance is equally real. Eligibility rules, naming conventions, reserved names, revocation criteria, and exception rights need review as the company changes. The difference between .jll and .lasalle means a policy update may require separate analysis. A single portfolio document can provide coordination, but it should not erase contract-specific controls.

Continuity maintenance includes exercising procedures. A recovery plan that has not been tested against current provider contacts and interfaces may be little more than historical intent. Tests need scope, expected results, observed results, owners, exceptions, and remediation dates. The absence of public TLD-specific test evidence means an external analyst cannot say whether this work occurred. It remains a necessary category in the cost model.

The central maintenance question is not whether DNS is currently resolving. It is whether the company can explain why it should continue resolving after the next change. That explanation requires current records, assigned owners, provider evidence, tested procedures, and an inventory of dependent services.

Exception Cost

Exception cost becomes visible when normal workflow no longer fits. An urgent security change may need approval outside the standard window. A business unit may request a name that conflicts with policy. A provider outage may require a manual escalation. A registration record may contain stale ownership. A recovery test may miss its objective. A legal or compliance request may require preservation or suspension. Each case demands judgment and evidence.

Restricted eligibility can reduce routine misuse while making exceptions more concentrated. If only a central registrar path is allowed, the exception owner needs authority to act quickly without bypassing accountability. Emergency credentials must be protected but usable. Out-of-band contacts must be current. A break-glass action must leave enough evidence for later review.

Provider boundaries magnify exception cost. The company may discover a problem, but only the provider can implement the technical change. The provider may need proof of authorization. The registrar may depend on the registry. The registry may depend on DNS operators or escrow processes. Every handoff adds time and the possibility of misunderstanding. Clear escalation language and rehearsed contacts are reliability controls.

Data exceptions are especially difficult. A registration can be syntactically valid while its business owner is wrong. A domain can resolve while the application behind it is abandoned. A public contact can meet a format requirement while no longer reaching the responsible team. Detecting these cases requires reconciliation against company records, not just protocol monitoring.

Security events can also create conflicting priorities. Investigators may want to preserve evidence, operators may want to restore service, legal teams may need notification, and communications teams may need an accurate public statement. The TLD owner needs a decision model that protects both continuity and record integrity.

Exception remediation must be tracked to closure. JLL's public technology-recovery material discusses exception and remediation practices in a wider program context. That supports the relevance of exception governance, but it does not prove a particular .jll or .lasalle exception. A defensible analysis therefore describes the necessary control without inventing an incident.

Failure Modes and Who Pays for Them

The first failure mode is root-delegation error. Incorrect nameserver or glue information at the root can prevent resolvers from reaching the TLD's authoritative service. The accountable operator must coordinate accurate changes, and the technical provider must supply correct parameters. Detection may involve external DNS observations, but correction requires authorized action through the relevant chain.

The second is authoritative-DNS failure. Servers can become unavailable, return inconsistent data, expose stale zones, or respond incorrectly. Geographic and provider diversity can reduce correlated risk, but the public records do not establish a tested architecture or measured result. Cost falls across monitoring, provider response, company supervision, incident coordination, and dependent application teams.

The third is registrar or registry authorization failure. A legitimate change can be blocked by stale credentials or contacts, while an illegitimate change can pass through weak access control. Centralization reduces the number of actors but raises the impact of compromised privileged access. Prevention requires limited privilege, strong authentication, review, and recoverable emergency procedures.

The fourth is registration-data drift. WHOIS or RDAP can publish a record that no longer matches business ownership or contact reality. Protocol availability will not detect every semantic error. The company pays through periodic reconciliation, ownership attestation, exception review, and incident delay when stale information obstructs response.

The fifth is policy mismatch. A registration may conflict with the eligibility or naming rules for .jll, or an assumed shared policy may be applied incorrectly to .lasalle. The cost appears in manual review, legal interpretation, revocation decisions, remediation, and the risk of inconsistent identity.

The sixth is dependency concentration. A specialized provider may operate several critical functions. Concentration can improve operational consistency, but a supplier incident, contractual dispute, acquisition, or exit can affect multiple layers at once. Mitigation requires evidence access, data portability, transition planning, alternative contacts, and clarity about what can be moved.

The seventh is monitoring blind spots. A test that checks only that a name resolves may miss stale answers, broken registration data, certificate failure, regional inconsistency, or an inaccessible change path. Broader monitoring increases cost, but narrow monitoring can leave the company confident about the wrong property.

The eighth is recovery-plan drift. Documentation can refer to former staff, old interfaces, retired suppliers, or obsolete system relationships. A declared recovery objective has little operational value unless dependencies and procedures can meet it. Failed tests create remediation work; untested plans create uncertainty that becomes expensive during a real event.

The ninth is lifecycle residue. Old domain names, certificates, redirects, credentials, or monitoring rules can remain after a service closes. Attackers or accidental users may encounter the residue. Cleanup has a cost, but indefinite retention also has a cost. The owner needs explicit retirement criteria and evidence that dependencies were checked.

The tenth is false inference from the corporate TLD itself. Teams may assume a name under .jll or .lasalle is trustworthy solely because of the suffix. Registry policy can strengthen authorization, but application security, content integrity, identity controls, and user education still matter. Namespace control is one layer, not a substitute for the security of the service using the name.

Who pays depends on where the failure is discovered and which boundary must move. JLL pays through oversight, business interruption, investigation, remediation, legal work, and supplier management. Providers pay through operational response and contractual duties. Business units pay when services or identity paths are disrupted. Users bear confusion or loss of access. The DNS ecosystem bears coordination work when a problem reaches shared infrastructure.

This allocation explains why cheap registration counts do not imply cheap ownership. The recurring cost is in preventing and resolving cross-boundary failures, not in the number of labels alone.

Continuity, Recovery, and Vendor Dependence

The registry agreements create continuity expectations around critical registry functions, escrow, DNS, and registration data. Those obligations give JLL a contractual baseline. The company's public business-continuity and technology-recovery documents add a wider governance context: critical systems, recovery objectives, network and telecommunications resilience, vendor dependencies, testing, ownership, and exception remediation.

The two evidence sets should be connected carefully. Company-wide continuity statements show that JLL describes a structured program. They do not prove that .jll and .lasalle are mapped into every element of that program or that a TLD-specific recovery exercise met its objective. The sensible diligence question is whether the namespace dependencies are explicitly included.

A complete dependency map would begin with root delegation and continue through registry services, registrar access, authoritative DNS, registration data, escrow, monitoring, certificates, identity systems, applications, and communications. It would identify which party operates each element, where credentials are held, how an incident is declared, what data must be recovered, and what evidence proves restoration.

Recovery time needs similar precision. A company document may define categories for mission-critical systems, but a TLD involves several services with different failure behaviors. DNS may continue answering cached data while an update path is unavailable. Registry access may be down while existing names still resolve. Registration-data service can fail without an immediate website outage. A single recovery label can obscure those differences.

Vendor dependence requires an exit view as well as an outage view. If a provider relationship ends, JLL needs data, credentials, configuration, evidence, contact continuity, and a destination provider or operating model. Contract rights matter, but executable migration steps matter more. A transition that exists only in legal language may fail under time pressure.

Escrow is part of the continuity design because it preserves registry data outside the immediate operating path. Escrow does not by itself restore DNS or registrar access. It is one record-preservation mechanism within a larger recovery chain. Treating it as complete continuity would confuse retained data with a running service.

An external reader cannot determine from the cited material whether all these controls are current or tested. The evidence does establish why the controls matter and where accountability begins. It also supports a direct cost conclusion: continuity for a small corporate namespace still demands cross-functional ownership, provider evidence, current contacts, exercises, and remediation.

JLL's Wider Technology-Risk Context

JLL's annual filings describe a company that depends on information systems and third-party technology across a large international operation. The filings discuss cybersecurity governance, incident risk, data, technology providers, business disruption, and the potential cost of response and remediation. These disclosures provide context for why a corporate namespace should not be treated as isolated from enterprise risk.

The filings do not identify a .jll or .lasalle incident. They do not disclose a TLD-specific architecture, outage rate, or recovery result. They should therefore be used to establish governance context and exposure categories, not to manufacture a domain incident narrative.

The relevant connection is operational. Corporate TLDs can support websites, identity, redirects, email-related records, or other services, but any such use depends on surrounding systems. A secure registry cannot make a vulnerable application safe. A resilient application cannot compensate for a broken delegation. Enterprise risk management needs to recognize the combined chain.

Third-party dependence is another shared theme. The public delegation records identify specialized technical roles, while the filings describe broader reliance on external technology providers. The exact supplier map is not public, but the governance requirement is clear: material dependencies need inventory, monitoring, contractual safeguards, incident routes, and recovery plans.

Global operations can make maintenance more complex. Time zones, regional teams, local legal requirements, acquisitions, divestitures, and different business-unit identities can all affect domain ownership. Central TLD governance can provide consistency, but only if it receives accurate local information and can process exceptions without excessive delay.

The company-wide reporting material also illustrates the difference between policy and execution. Public policies show how JLL says it organizes continuity and recovery. The operating evidence needed for a TLD review would include current control owners, recent test results, open exceptions, provider attestations, and actual service observations. Both layers matter; neither should be substituted for the other.

What the Public Evidence Cannot Establish

The cited material cannot establish measured uptime, DNS latency, query volume, error rate, recovery time, change success rate, or security performance for .jll or .lasalle. No such benchmark should be inferred from delegation, readiness, contract, policy, continuity, or filing records.

It cannot establish the number or purpose of active second-level names. It does not show which applications depend on the TLDs, whether names are customer-facing, or how users respond to them. It does not establish a customer production outcome or TLD-attributable revenue.

It does not establish that JLL directly operates every nameserver, registry component, registrar function, WHOIS or RDAP service, escrow mechanism, or monitoring system. The records identify accountable and technical roles, but not a complete internal architecture.

It cannot establish perfect compliance with the agreements or policies. Contract language describes obligations. Policy language describes intended control. Current root records show present delegation data. None is evidence that every requirement was met without exception at every moment.

It cannot establish that the company-wide business-continuity and technology-recovery controls were tested specifically against the two TLDs. Those documents provide relevant governance context but do not report a DNS or registry exercise.

It also cannot justify treating .jll and .lasalle as contractually identical. .jll is publicly identified as a Brand TLD under Specification 13. .lasalle is publicly listed under a Base, Non-Sponsored agreement without the same displayed designation. The safe description is two corporate TLDs under one accountable company, with different public contract metadata.

These limitations do not weaken the analysis. They define the difference between evidence and inference. The defensible result is a control-and-cost model grounded in delegation, contract, policy, continuity, and risk records, with unknown performance left unknown.

A Reality-Layer Diligence Framework

A serious review of .jll and .lasalle should begin with current records, not brand intent.

  1. Confirm the IANA delegation for each string, including sponsoring organisation, technical role, nameservers, WHOIS, RDAP, and record date.
  2. Keep the two ICANN agreements and classifications separate. Record .jll Brand Specification 13 status and the published Base, Non-Sponsored metadata for .lasalle.
  3. Inventory every active second-level name, business owner, purpose, technical owner, registrar state, DNS target, certificate dependency, monitoring target, and retirement date.
  4. Reconcile eligibility and naming policy against actual registrations. Record exceptions, approvals, and revocation rights.
  5. Map provider responsibilities for registry services, registrar access, authoritative DNS, registration data, escrow, monitoring, security, and incident response.
  6. Review privileged access, authentication, separation of duties, emergency access, credential recovery, and evidence retention.
  7. Test root-to-application observability. Resolution alone is limited public evidence; include authoritative consistency, registration data, certificates, redirects, and dependent service health where relevant.
  8. Connect the namespace to business-continuity and technology-recovery ownership. Define service-specific objectives and dependencies rather than assigning one generic recovery label.
  9. Exercise provider escalation and transition procedures. Verify that current people can authorize and execute a change under time pressure.
  10. Review open exceptions and remediation dates. A control is not complete merely because a gap has been documented.
  11. Separate capability, Product reliability, and customer production outcomes in reporting. Use evidence appropriate to each claim.
  12. Reassess strategic value and recurring cost together. A corporate TLD can remain useful with limited public visibility, but the decision should include full supervision, integration, maintenance, and exception cost.

This framework treats the registry as an accountable recordkeeping and continuity function. It avoids claims of sovereignty or inherent trust. The two strings have value only to the extent that their running records are accurate, secure, transferable where required, and operationally continuous.

Featured Image Context and Attribution

The featured photograph shows Aon Center in Chicago. JLL's regulatory filing reports its principal executive-office address at the building's address, which makes the image relevant corporate context. It does not depict DNS, registry, registrar, or network infrastructure. It does not prove that Jones Lang LaSalle Incorporated occupies the depicted space at the time photographed, and it provides no evidence about the performance of .jll or .lasalle.

Image: "Aon Center, Chicago, Illinois (9181708504)" by Ken Lund, licensed under CC BY-SA 2.0, via Wikimedia Commons: https://commons.wikimedia.org/wiki/File:Aon_Center,_Chicago,_Illinois_%289181708504%29.jpg

Editorial Conclusion

Jones Lang LaSalle Incorporated's control of .jll and .lasalle is a concrete technology responsibility embedded in the public DNS. The IANA records establish current delegation. The ICANN records establish operator accountability and contractual obligations. The .jll materials establish a Brand Specification 13 governance model, while .lasalle carries different public agreement metadata. JLL's continuity, recovery, and regulatory material provides broader context for ownership, vendor dependence, testing, and remediation.

The evidence supports capability. It supports an analysis of reliability controls and costs. It does not support invented uptime, benchmarks, customer deployments, financial outcomes, incident histories, or internal architecture.

The practical lesson is that corporate namespace ownership is not completed by obtaining a string. It is maintained through accurate records, secure authorization, provider supervision, integrated change control, lifecycle maintenance, tested recovery, and disciplined exception handling. These obligations persist even when the namespace is quiet and even when public adoption is not documented.

For JLL, the two-string portfolio also demands precision. Shared corporate accountability does not make the agreements identical. Reliable governance must preserve the distinction while coordinating the common identity, security, continuity, and vendor controls. The quality of the system is ultimately visible in running delegation and registration records, not in the breadth of the brand claim.

Sources

  1. IANA, .jll delegation record: https://www.iana.org/domains/root/db/jll.html
  2. IANA, .jll delegation report: https://www.iana.org/reports/c.2.9.2.d/20150521-jll
  3. IANA / ICANN New gTLD Program, .jll readiness report: https://www.iana.org/reports/tld-transfers/gtld-readiness-1-1250-4137.pdf
  4. ICANN, .jll registry agreement index: https://www.icann.org/en/registry-agreements/details/jll
  5. ICANN, .jll registry agreement: https://itp.cdn.icann.org/en/files/registry-agreements/jll/jll-agmt-html-02apr15-en.htm
  6. ICANN / Jones Lang LaSalle Incorporated, .jll Specification 13 application and policy: https://itp.cdn.icann.org/en/files/registry-agreements/jll/jll-spec13-application-23sep14-en.pdf
  7. IANA, .lasalle delegation record: https://www.iana.org/domains/root/db/lasalle.html
  8. IANA, .lasalle delegation report: https://www.iana.org/reports/c.2.9.2.d/20150609-lasalle
  9. ICANN, .lasalle registry agreement index: https://www.icann.org/en/registry-agreements/details/lasalle
  10. ICANN, .lasalle registry agreement: https://itp.cdn.icann.org/en/files/registry-agreements/lasalle/lasalle-agmt-html-02apr15-en.htm
  11. Jones Lang LaSalle Incorporated, company reporting: https://www.jll.com/en-us/about-jll/company-reporting
  12. Jones Lang LaSalle Incorporated, business continuity program: https://www.jll.com/content/dam/jllcom/en/global/documents/policies/corporate/25-hub-sustainability-esg-business-continuty.pdf
  13. Jones Lang LaSalle Incorporated, technology recovery program: https://www.jll.com/content/dam/jllcom/en/global/documents/policies/corporate/25-hub-sustainability-esg-technology-recovery-program.pdf
  14. U.S. Securities and Exchange Commission, Jones Lang LaSalle Incorporated 2024 annual filing: https://www.sec.gov/Archives/edgar/data/1037976/000103797625000006/jll-20241231.htm
  15. U.S. Securities and Exchange Commission, Jones Lang LaSalle Incorporated 2025 annual filing: https://www.sec.gov/Archives/edgar/data/1037976/000103797626000037/jll-20251231.htm