A Domain Registry Runs Self-Service Zone File Distribution for Vetted Outsiders on Files.com
A domain registry operator runs the backend registry services for top-level domains on behalf of sovereign nations, city governments, and global brands.
Operating a TLD carries an obligation that has nothing to do with selling domains. The registry must make its zone files, the daily data files describing each TLD's DNS, available to vetted outside parties: researchers, university teams, security vendors, registrars, and companies investigating spam and domain abuse. Those parties are not the registry's customers and not its employees. They are vetted members of the general public, and hundreds of them are entitled to pull the data every day.
Serving that audience meant solving an identity and entitlement problem, not simply hosting two files. The registry replaced its self-hosted Amazon EC2 SFTP service with a branded Files.com portal that lets vetted outsiders create their own accounts and retrieve the right zone files without helpdesk provisioning.
Two Zip Files a Day, and an Account Created by Hand for Every Reader
The distribution ran on a self-hosted SFTP service on a small EC2 instance, with a web server alongside it publishing the files. The registry wanted that publication on a managed platform, with no single instance for anyone to keep alive.
The routine around the server made work of its own. It had no self-service path, so every new user landed on the customer service team: someone connected to the instance over SSH and added the account by hand.
An Audience That Could Never Live in the Registry's Identity Systems
The problem is structurally awkward. The entitled users are outsiders, so none of them can be provisioned through the registry's internal identity systems.
Meanwhile the workload itself looks tiny on paper. Two zip files, tens of megabytes each, updated daily. Building self-service signup, an entitlement model, and resilient hosting in-house is a real engineering project, and it was never going to be justified for two zip files a day. The registry wanted the capability without building it.
The replacement had to let vetted outsiders create their own accounts, gate each of the two files by entitlement, serve automated daily pulls over the protocols those users' scripts already spoke, carry the registry's own branding, and run with no server for anyone to keep alive. The registry selected Files.com to be that distribution portal.
A Portal Whose Users Provision Themselves
The registry's systems engineer built the site, and the result is a standing public endpoint whose user lifecycle is part of the design.
The front door carries the registry's identity. The site runs under a custom domain with the registry's own branding.
Entitlement is two Files.com groups, one per zone file. Vetting stays with the registry; once a requester is approved, placing them in the right group is the entire setup. The group grants exactly the file they are entitled to and nothing else.
Existing users were invited in bulk to sign up through an email link. New requesters onboard the same way after approval, with no account created by hand.
Downloads run over whatever client the user already has. Most script a daily SFTP pull, while some call the REST API. Once the portal was live, the engineer handed day-to-day ownership to the registry operations team. Running it stopped being a systems engineering job.
Hundreds of External Users, Without SSH Provisioning
With the portal in production, the registry replaced a server-and-helpdesk routine with a managed distribution channel.
- Hundreds of external users have been invited onto the platform, and most active users pull the updated zone file every day over SFTP or the API, with almost no human interaction on either side.
- Approval and entitlement remain with registry operations: staff vet each requester and assign the right group. Account creation then happens through a signup link; nobody SSHes into anything.
- The publication obligation sits on a managed platform instead of a single EC2 instance, so there is no server to patch, size, or keep alive.
The Obligation Runs Whether Anyone Touches It or Not
Today, serving zone data to the outside world is not a system the registry operates. It is a standing Files.com portal under the registry's own domain. Registry operations still vets requesters and assigns entitlements, while approved outsiders create their own accounts and retrieve the files without helpdesk or systems engineering work.
Every new researcher used to end in an SSH session. The lesson travels: a user base that can never live in your internal identity systems does not have to route through IT. Self-signup and group-based entitlement turned a daily publication duty into a managed distribution channel, and Files.com is what it runs on.
Related Customer Stories
A Database Software Company Gives Every Support Ticket Its Own HTTPS or SFTP Intake Route With Files.com
API-driven, write-only intake lets customers deliver diagnostics through their firewalls while the company keeps no standing credentials for external uploaders.
Read The Story
A Network Security Vendor Retires Box by Moving a Handful of Beta Users to Files.com
The workload was small, but absorbing it into the file-transfer environment already feeding Oracle ERP eliminated an entire external sharing surface.
Read The Story
An IT Services Provider Replaced Its Former Parent's FTP Service and IBM Sterling File Gateway Without Rewriting Batch Jobs
A hostname under the provider's own name, fixed IP addresses, and one-for-one path mapping let established z/OS workflows keep running across tightly controlled client environments.
Read The Story
Get The File Orchestration Platform Today
4,000+ organizations trust Files.com for mission-critical file operations. Start your free trial now and build your first flow in 60 seconds.
No credit card required • 7-day free trial • Live in minutes