One Git Push from Bucharest: Anverino Software and the Hard Economics of LuaDNS

Summary

• Anverino Software SRL is the Romanian legal and network operator behind LuaDNS: the service names the company as owner, the RIPE registry assigns AS41954 to it, and LuaDNS's four advertised IPv4 and IPv6 nameserver addresses sit inside the two prefixes that AS41954 originates.
• LuaDNS's strongest distinction is operational control. Customers can manage zones through a web interface, a REST API, standard BIND files or a Git repository whose Lua configuration is validated and distributed after a push. That makes DNS changes reviewable, but it also requires explicit ownership rules when Git, API and dynamic updates coexist.
• The routing evidence supports a real dual-stack anycast operation and valid RPKI origin authorisations. It does not independently prove the company's advertised PoP count, facility diversity, per-site capacity or DDoS headroom; the public PoP total and the city list are themselves inconsistent.
• Low annual prices, unlimited-query plans, AXFR support and portable source files create an attractive proposition for developers and domain portfolios. The trade is thinner public evidence on service levels, security assurance, staffing depth, abuse response and succession than a regulated or very large buyer would normally demand.
• A serious buyer should test DNSSEC transitions, serial consistency, regional reachability, route withdrawal, API-key containment, Git rollback, external-secondary operation, incident escalation and full export before delegating a critical production zone.

The twenty-minute route failure that explains LuaDNS

On December 25, 2018, LuaDNS recorded what it called its first outage. A system update left the BIRD routing daemon unable to start, and the anycast DNS network was unavailable for roughly twenty minutes. The entry in the company's status history is short, almost disarmingly so. Yet it captures the whole economic and technical problem that LuaDNS is trying to solve.

Authoritative DNS is a tiny part of an application's visible machinery. It usually consumes less management attention than the application, database, cloud account or content-delivery network to which it points. But if a resolver cannot obtain an authoritative answer, healthy servers become practically unreachable. The control plane may be a few records in a web form; the operating obligation is to keep those records reachable through software changes, hardware failures, carrier faults, routing mistakes, attacks and human error. The customer is buying the absence of an event that most users will never know was prevented.

Anycast is one answer. The same address is announced from multiple locations so that routing normally directs a query towards a nearby available site. The principle is well established in RFC 3258 and is now routine for authoritative DNS. But anycast does not abolish shared failure. It moves the reliability question from a single server to the systems that distribute identical service and identical routes across many servers. A common routing configuration can withdraw every location. A bad zone build can distribute the same bad answer everywhere. A control-plane outage may leave answering nodes healthy but make emergency changes impossible.

LuaDNS's own incident list illustrates those different boundaries. The 2018 event touched the routed DNS network. A May 2023 hardware problem took down the API before it was restored. In March 2024, a job-queue problem delayed some zone updates. In June 2025, a Heroku outage made the sandbox used for Git builds inaccessible. These are not equivalent incidents: one affects the answer plane, another the management interface, another the speed at which new data becomes authoritative, and another a dependency in the code-to-DNS workflow. A buyer who asks only for a single uptime percentage misses the architecture.

That architecture is why LuaDNS is more interesting than its size suggests. It is not merely inexpensive hosting for records. It is an attempt to expose the mechanics of authoritative DNS to people who already know how to review code, run deployment pipelines and reason about rollback. The wager is that a small operator can automate enough of the work to make a globally routed service affordable, while giving customers sufficient control to reduce their own change risk. The corresponding buyer's wager is that the operator has removed more common failure than it has concentrated.

Proving the Anverino Software–LuaDNS–AS41954 bridge

The public identity is unusually important here because the brand and the legal entity do different work. Customers encounter LuaDNS. Contracts, routing resources and corporate continuity attach to Anverino Software SRL. Treating Anverino as a generic software consultancy would miss the operating asset; treating LuaDNS as an unconnected product name would miss the accountable entity.

The first link is direct. LuaDNS's privacy policy says the service is owned by Anverino Software S.R.L., a Romanian company. The contact page gives the same legal name, while the footer on the service's main pages attributes copyright to Anverino Software SRL. The about page names Vitalie Cherpec as founder, dates the idea to October 2011 and describes the service's infrastructure and software. This is not an inference from a similar name: it is the operator's own attribution.

The second link is the routing registry. The RIPE Database record for AS41954 names the autonomous system ANVERINO-AS, binds it to Anverino Software SRL and records Romanian registration number 23552306. Romanian company data collected by MetricBiz matches that number, the exact company name, a March 2008 incorporation date and an active custom-software business. PeeringDB's network record independently maps AS41954 to Anverino Software.

The third link joins the product to the network. LuaDNS publishes four IPv4 addresses, 185.142.218.1 through .4, and four corresponding IPv6 addresses, 2001:67c:25a0::1 through::4, for ns1.luadns.net through ns4.luadns.net. Live DNS queries on July 18, 2026 returned those same addresses. RIPEstat showed AS41954 originating 185.142.218.0/24 and 2001:67c:25a0::/48. The four authoritative endpoints therefore sit inside the exact address space originated by the Anverino autonomous system.

The chain is strong enough to preserve the assigned entity without collapsing it into a brand, affiliate or hosting supplier: Anverino Software SRL owns LuaDNS, holds the network registration, and originates the prefixes containing the service's advertised nameserver addresses. LuaDNS is the public operating identity; Anverino is the legal and routing authority behind it.

There are still reconciliation questions. The address on LuaDNS's contact and privacy pages differs from the address in the RIPE organisation record and the Romanian company-data page. That may reflect a registered-office change, an operating address or stale publication, but the public evidence does not resolve it. A contract should use a current registry extract and state the notice address. This is a due-diligence task, not evidence that the identity bridge fails.

Git is not an integration here; it is the product idea

LuaDNS began from a specific operator frustration. Its founder says he disliked administering tens of domains through a web interface and wanted DNS configuration in Git with Lua available for templating. That origin still shapes the product more clearly than the usual managed-DNS comparison list does.

In the documented workflow, a customer connects a repository, gives the LuaDNS build system read-only access through a deploy key when necessary, and configures a webhook. After a push, LuaDNS pulls the configuration, analyses and validates it, distributes the resulting zones and records to the nameservers, and sends an email with build status. The documentation also provides a public example repository and supports both Lua files and a subset of standard BIND zone-file syntax.

This changes the customer workflow in useful ways. A DNS modification can begin as a branch, be reviewed as a diff, pass organisation-specific checks, and carry the identity of the person who approved it. The repository can preserve why a record changed alongside what changed. Reverting source is familiar. Templates reduce repetition across many similar zones. A team can prohibit direct production pushes, require signed commits, enforce ownership rules for sensitive files, scan for accidental secrets and use ordinary continuous-integration tools before LuaDNS sees the change.

None of those governance controls is automatic merely because Git is present. They belong to the customer's repository and working practice. LuaDNS documents validation before distribution, but its public material does not describe a native approval chain, staged environment, per-location canary, scheduled activation, dry-run API, or a transaction that atomically coordinates changes across unrelated zones. A customer that allows anyone with push permission to deploy to the configured branch has converted repository access into DNS authority.

That can be a better control arrangement than a shared web password, but only if branch protection and emergency access are designed accordingly.

There is also a subtle source-of-truth problem. LuaDNS permits the web interface, API, dynamic-DNS protocol and Git to manage records. Its ignore function exists so that a Git build can leave selected records, such as API- or DynDNS-managed addresses, untouched. That feature is practical, but its necessity is a warning: without an explicit ownership map, the next Git deployment can conflict with a change made through another path, or a dynamic process can quietly diverge from reviewed source.

A sound implementation would assign every record class to one control path. Stable service endpoints, mail policy and certificate-authority restrictions might live in Git. Ephemeral addresses might belong to DynDNS. Automated certificate challenges might use a narrowly scoped API key. Break-glass edits in the web interface should either be prohibited or immediately reconciled back into source. The organisation should test what a Git rebuild does to out-of-band records before production delegation, not learn during an incident.

The June 2025 status entry adds another dimension. LuaDNS disclosed that the sandbox used for Git builds was unavailable because of a Heroku outage. That did not necessarily stop authoritative answers already distributed, but it impaired a flagship change path. Git therefore reduces customer-side dependence on an opaque control panel while introducing repository access, webhook delivery and a hosted build environment into the route from intention to authority. The right question is not whether Git is reliable in the abstract.

It is whether the customer has another authenticated, rehearsed way to make an urgent change when that chain is unavailable.

Lua makes configuration compact—and mistakes scalable

The Lua format is more than a prettier zone file. It offers functions for records, templates, aliases, clones, external secondaries and service-specific behaviours. A portfolio can generate repeated records from common logic rather than copy them through dozens of zones. For an operator managing white-label environments, customer domains or regional variants, this can remove a large class of drift.

The public documentation demonstrates ordinary records as functions, exposes variables for the current zone, and permits reusable Lua logic. It also supports pseudo-records such as ALIAS, REDIRECT and FORWARD, which ask the service to do work beyond serving a literal DNS resource record. ALIAS periodically resolves a target and synthesises address records at a name where a CNAME would be invalid. REDIRECT and FORWARD add web and mail behaviour. HTTPS records support parameters including service priority and encrypted-client-hello material. These are meaningful conveniences, particularly at LuaDNS's price.

Programmability changes the failure mode. A typo in one manually edited record breaks one name. A faulty helper can generate the same wrong record across every cloned zone. An innocent change in a shared template can alter mail, certificate issuance or traffic routing for a whole portfolio. Validation can catch syntax and some structural errors; it cannot know whether a syntactically valid address points to the intended production system.

LuaDNS should therefore be treated as a compiler target, not just a repository host. Before a push reaches the service, the customer should render or otherwise inspect the effective records, compare them with the last deployed set, run policy checks, and set thresholds for unusually large deletions or TTL changes. High-risk records deserve specific tests: apex A and AAAA, NS and glue, MX, CAA, DS, DNSKEY-related transitions, wildcard records, and the TXT records used for domain control. A generated-zone diff is more valuable than a source diff when a small source change can produce many outputs.

This is also where portability begins to split. Standard BIND files are broadly understandable, but LuaDNS's documented BIND subset is narrower than the full Lua feature set. A customer that uses Lua helpers, clones, provider-specific aliases, redirects or mail forwarding cannot assume another DNS host will interpret the repository. The source remains visible, which is better than a configuration trapped only in a web account, but exiting may require compiling the logic down to ordinary records and replacing service-specific functions.

The API exposes control, not a complete governance layer

LuaDNS's REST API is straightforward. It is HTTPS-only, exchanges JSON, is disabled by default, and authenticates with an account email and API key using HTTP Basic authentication. It supports listing, creating, updating and deleting zones and records. Requests are limited to 1,200 in five minutes, with reset information returned when the limit is reached. Official Go and Ruby clients are published on GitHub, the documentation points Python users to Apache Libcloud, and the broader ecosystem includes a lego integration for ACME DNS challenges.

For a small infrastructure team, this is enough to automate most ordinary work. It can provision a customer zone, create verification records, rotate an endpoint, export inventory or integrate DNS changes into an application deployment. The API also returns request identifiers on errors, a useful primitive for support and audit. LuaDNS added single-zone API-key restriction in 2023, broader resource scoping in 2025 and a user-visible activity page in February 2026. Those changes suggest a continuing shift from one account-wide credential towards least privilege and traceability.

Yet API availability is not the same as safe automation. The public documentation does not describe conditional updates using an entity version, idempotency keys, a mandatory second approval, a preview of the effective zone, or a rollback endpoint. Individual record operations can interleave with other writers. A full-zone update can have a large blast radius. An automation system must therefore create its own safety properties: fetch and compare current state, serialise writers, reject unexpected drift, use the narrowest key, record request identifiers, back off correctly at the rate limit, and verify authoritative answers after the change.

Credential design matters because HTTP Basic authentication sends the email and API key on every request inside TLS. That is a conventional and workable pattern, but the key is a bearer secret in practical terms. It should not be placed in repository files, shell history, build logs or wide-scope shared secrets. Each workload should have a dedicated key, ideally restricted to one zone or resource set, with a documented owner and rotation date. The customer should test whether key revocation is immediate and whether a revoked key can remain effective through any cache or worker queue.

The audit window deserves attention. LuaDNS's privacy policy says audit logs include user, action, resource and IP information, and that those logs are purged after three months. Three months may be sufficient for routine troubleshooting but shorter than the retention required by some regulated organisations or annual investigations. A buyer should determine whether activity can be exported continuously, whether API and Git changes appear in the same chronology, whether failed actions are retained, and whether support can preserve evidence after an incident.

The correct interpretation is favourable but bounded: LuaDNS provides a useful engineering control surface at a price that makes automation accessible to small teams. It does not publicly claim to replace the customer's change-management system. Teams that understand that distinction can obtain substantial leverage; teams expecting the provider to supply enterprise governance around an unrestricted script may instead automate their own outage.

What the anycast evidence proves—and what it cannot

LuaDNS says it operates four anycast nameservers across 22 points of presence in North America, South America, Africa, Europe, Asia and Australia. The service publishes both address families for each server. That claim is partly testable from outside and partly dependent on the operator's disclosure.

The strong evidence is at the prefix level. RIPEstat showed AS41954 actively announcing one IPv4 prefix, 185.142.218.0/24, and one IPv6 prefix, 2001:67c:25a0::/48, on July 18, 2026. The four published IPv4 nameserver addresses are consecutive hosts in the /24, and the four IPv6 addresses are the corresponding hosts in the /48. bgp.tools and IPinfo both classify the network or its addresses as anycast. IPinfo's probes had recently reached the same network with very low latency from different European locations, which is consistent with multiple service sites rather than a single machine in Bucharest.

The routing record also shows more than one upstream. The RIPE entity declares import and export policy with AS20473, AS34927 and AS835, and public collectors saw the same three as upstreams. That is useful evidence against dependence on one transit relationship. Visible peer counts varied across snapshots, which is normal for collector-based views and another reason not to convert a public graph into a contractual topology.

The weaker evidence concerns the physical footprint. A BGP collector can show that a prefix is visible through several paths; it cannot prove that every advertised city has an independently powered, independently operated DNS node with sufficient capacity. PeeringDB's Anverino record identifies the ASN but, at the time of review, disclosed no Internet exchanges, facilities, traffic level, looking glass, policy or public status dashboard. It therefore does not corroborate the claimed locations.

The LuaDNS website introduces a more elementary problem: it says “22 POPs” but its region-by-region city list contains 25 names—seven in North America, two in South America, one in Africa, nine in Europe, five in Asia and one in Australia. The changelog documents network expansion, including an 18-PoP total in 2022 and later additions in Zurich, Santiago and Toronto, but it does not reconcile the current total. The difference may be stale copy, recently changed capacity or the use of a definition that groups some sites. Until explained, neither the total nor the city enumeration should be treated as an audited inventory.

There is a second concentration hidden by the four names. All four IPv4 endpoints share one /24, all four IPv6 endpoints share one /48, and all are originated by one autonomous system. The names can be served from many machines, but they remain inside one routing authority and one set of aggregate announcements. Four hostnames are not four independent routing domains. A mistake in the common route policy, a loss of the origin, or a problem in a shared configuration layer can affect every name together. The 2018 BIRD incident is historical evidence that this common mode is not merely theoretical.

For many small and medium workloads, a well-run anycast network with one origin is entirely reasonable. Large providers also use common automation and common ASNs. The purchasing mistake is to count nameservers instead of testing failure domains. A buyer should ask whether each of the four addresses is present at every site, which sites are full-service versus edge relays, how health causes a route withdrawal, whether IPv4 and IPv6 share hosts and carriers, how capacity is distributed, and what DDoS mitigation is available before congestion reaches a node or transit link.

The best external test uses many probes and multiple networks. Query every nameserver over UDP and TCP, over IPv4 and IPv6, for existing names, nonexistent names, DNSSEC records and deliberately large responses. Record latency, response consistency, truncation, TCP fallback and the observed network path. Repeat during a scheduled route withdrawal or maintenance exercise if the provider will support one. A map is marketing; a repeatable measurement programme is evidence.

RPKI closes one routing door, not every route to failure

The two AS41954 announcements were RPKI-valid in the frozen evidence set. RIPEstat found a Route Origin Authorisation for AS41954 covering the IPv4 /24 with maximum length /24, and another covering the IPv6 /48 with maximum length /48. This is a precise configuration: it authorises the exact published aggregates without allowing AS41954 to originate more-specific routes under those authorisations.

That matters. RPKI allows a prefix holder to make a cryptographically verifiable statement about which autonomous system is authorised to originate the route. Networks performing route-origin validation can reject or de-preference an announcement that conflicts with the authorisation. The RIPE NCC explanation distinguishes valid, invalid and unknown states and makes equally clear that current origin validation does not prove the complete AS path.

For a DNS provider, valid origin authorisation reduces exposure to an accidental or malicious announcement from the wrong origin. It does not stop AS41954 from withdrawing its own route, a transit provider from losing reachability, a path from being manipulated after the origin, or a validly originated node from serving an incorrect zone. It also does not prove that every upstream filters invalid routes or that a route accepted in one region will be accepted everywhere.

Buyers should still give Anverino credit for the valid ROAs. Small infrastructure operators sometimes leave their routes in the “unknown” state; exact valid authorisations are a concrete control, not a slogan. The procurement follow-up is operational: who owns ROA changes, how are certificate and route changes coordinated, what monitoring alerts on a route becoming invalid, and can the operator show alerts from more than one validator? A route-security control is valuable only while it stays aligned with the prefixes actually announced.

LuaDNS's DNSSEC mechanics are strong enough to require serious testing

LuaDNS added DNSSEC in 2020 and has continued to refine it. Its documentation says enabling DNSSEC creates a key-signing key and a zone-signing key, signs the zone, and distributes it to the nameservers. It uses algorithm 13, ECDSA P-256 with SHA-256, and tells customers to confirm that their registrar supports the corresponding DS record. It automatically publishes CDS and CDNSKEY records where registries can use them, pre-signs zones so signed data can pass to external secondaries over AXFR, and added automatic ZSK rollover in 2025.

Those are meaningful capabilities for a low-cost service. Offline pre-signing can keep the answering tier from holding or invoking signing material on every query. Automatic rollover removes a recurring operational burden. CDS and CDNSKEY can reduce manual parent-child coordination when the registrar or registry implements the signalling correctly. The documentation also describes a careful disable sequence: LuaDNS publishes deletion signalling and continues signing until the parent DS record is removed. That is designed to avoid turning an intended downgrade into a validation failure.

The danger in DNSSEC is that a feature can be implemented correctly while an operational transition is performed incorrectly. A resolver that sees a DS record at the parent expects a valid chain. If the child no longer serves the matching DNSKEY or signatures, validating resolvers return failure even though non-validating queries may appear fine. Long TTLs extend the period during which old keys, DS records or answers remain in caches. LuaDNS says its ZSK rollover cycle takes about a month and may take longer for zones with large TTLs, which is a reminder that “enable” and “disable” buttons conceal multi-step distributed state.

External-secondary configurations introduce another layer. If LuaDNS pre-signs a zone and transfers it, the secondary must serve exactly the required signed data and refresh before signatures become stale. If a customer instead attempts a true multi-provider, independently signed design, RFC 8901 explains why each provider's DNSKEY set and signing algorithm must be coordinated. A resolver can cache keys obtained from one provider and then receive an answer signed by another; unless the shared key set validates both, the diversity intended to improve availability can produce intermittent validation failures.

A buyer should therefore run DNSSEC as a migration exercise, not a checkbox test. Start with a non-critical signed zone. Observe DS publication at the parent, DNSKEY and RRSIG responses from every LuaDNS address, and validation through several independent recursive resolvers. Test negative answers and large responses. Confirm serial and signature consistency on the external secondary. Perform a planned ZSK rollover and retain measurements through at least the longest relevant TTL. Then rehearse provider exit or DNSSEC disablement, including the precise order for DS removal.

The public evidence also leaves questions for regulated use. It does not describe where private signing keys are stored, whether a hardware security module is used, how KSK access is authorised, what backup and recovery controls protect the keys, or whether customers can import or export signing material. Those details may be available on request; they are not established by the public documentation reviewed here. An organisation whose policy requires customer-controlled keys or a specific cryptographic boundary should resolve that before delegation.

Redundancy belongs in the zone, not in the provider logo

LuaDNS supports AXFR to external secondary servers on every published plan. The documentation describes adding local or third-party secondaries, authorising transfers from LuaDNS's transfer endpoint and using NOTIFY to trigger refresh. This may be the single most important continuity feature in the product because it lets a customer place authoritative copies outside AS41954.

The distinction is structural. Four LuaDNS names share the operator's routing and deployment systems. An external secondary can use another autonomous system, another software stack, another account and another operational team. If LuaDNS's control plane is unavailable, the secondary can continue answering the last transferred version. If a common anycast route disappears, resolvers can reach names outside that route. RFC 2182 has long advised topological and geographic diversity for secondary servers precisely because multiple machines at one failure site do not produce the intended reliability.

LuaDNS appears to apply this principle to its own website zone. A July 18 DNS measurement found luadns.com delegated not only to the four LuaDNS names but also to ns1.linode.com and ns2.linode.com, with matching SOA serials across the six servers at the time of the check. That observation does not prove a contractual recovery plan, but it is concrete evidence that the operator uses cross-provider authoritative redundancy for an important domain.

External secondary service is not effortless insurance. Transfer ACLs must remain correct, serials must advance, DNSSEC signatures must validate, and every listed server must return the same intended data. A stale secondary can extend an incident rather than mitigate it. Service-specific functions such as web redirects or email forwarding may not transfer as ordinary DNS behaviour. A customer must monitor each provider independently and alert on serial lag, answer differences, expired signatures and transfer failure.

There is also a control question. LuaDNS documents sending zones to external secondaries, but the public material does not establish that LuaDNS can operate as a secondary fed from a customer-controlled hidden primary. Those are different architectures. A buyer that requires ownership of the primary source and signing process should ask specifically whether inbound AXFR or IXFR, TSIG, NOTIFY, catalog zones and hidden-primary arrangements are supported. The existence of outbound AXFR should not be stretched into an assumption about every secondary-DNS architecture.

The price is an engineering claim about automation

LuaDNS's pricing is striking. The free plan lists three domains, thirty records, a five-minute minimum TTL, DNSSEC, API access, AXFR and unlimited queries. Basic is $29 per year for ten domains and 500 records; Pro is $39 per year for thirty domains and 1,000 records; the Bulk offer begins at $50 per year for 50 or more domains and 10,000 records, with multiple bundles available. Paid plans lower the minimum TTL to sixty seconds and add vanity nameservers. The page accepts cards, PayPal, wire transfer and purchase orders.

For comparison, Amazon Route 53 charges separately for hosted zones and most queries. On its published rates, thirty ordinary public hosted zones would cost about $13 per month, or $156 per year, before query charges, assuming one zone per domain and no special routing. That is not an assertion that LuaDNS and Route 53 are interchangeable. Route 53 carries a much broader cloud integration, health-check and traffic-policy surface. The comparison shows the economic choice: LuaDNS bundles a meaningful developer feature set into a price closer to a minor software utility than to a mission-critical global control plane.

The likely explanation is automation and scope. A compact operator can standardise the data plane, automate configuration, use open-source components and avoid a large sales or compliance organisation. LuaDNS's about page lists Go, Lua, Elixir, TinyDNS with a DNSSEC patch, Nginx and Linux among its technologies. The service says it uses Puppet for infrastructure management and Nagios for monitoring. Its Git workflow pushes part of change discipline back towards customer repositories. Flat pricing also removes metering and billing complexity.

That explanation is an inference, not disclosed unit economics. Public Romanian company data reinforces the picture of a lean business: MetricBiz reports 2025 turnover of 168,616 Romanian lei, profit of 108,545 lei and an average employee count of zero. Employee counts in such filings can exclude owners and contractors, and financial scale does not directly measure operational competence. The service's survival since 2011 is strong counter-evidence to any assumption that small automatically means transient. Still, the figures make continuity and support capacity legitimate procurement subjects.

“Unlimited queries” also needs operational definition. Paid terms do not publish a query charge, but the public pages do not describe a contractual fair-use boundary, attack-traffic treatment, per-zone rate policy, or mitigation capacity. A buyer should ask whether a DNS flood can trigger a service move, suspension or commercial discussion, and whether attack traffic is included without surprise charges.

The economic test is not whether $39 is good value; it plainly can be. It is whether the service's scope matches the domain's consequence. A hobby project, agency portfolio or small software business may value transparent annual cost and Git control more than a formal service-level agreement. A bank's login domain may rationally spend far more for contractual remedies, audited controls, staffed escalation and independent secondary service. Low price is not evidence of low reliability, but it leaves less room to assume that expensive organisational layers exist offstage.

Public security evidence is thinner than the feature set

LuaDNS makes several sound security choices in public view. API access is disabled until enabled. Keys can be scoped. Git access can use a read-only deploy key, with newer Ed25519 support and increased RSA key size documented in the changelog. DNSSEC uses a modern algorithm and automated rollover. The two originated prefixes have valid, exact RPKI authorisations. Activity logs record resource changes. The service supports CAA, SSHFP, TLSA and OPENPGPKEY records for customers that use DNS as part of other security controls.

The privacy policy is also more specific than a generic promise. It says server and audit logs are automatically deleted after three months, account information is retained while the service is active or as legally required, correspondence may be retained indefinitely, and deleted information may remain in offline archives for up to a year. It identifies Anverino Software as a Romanian owner and gives a contact route for access or deletion requests.

What is not public is equally material. In the pages reviewed, there was no published security architecture, independent assurance report, penetration-test summary, ISO 27001 certificate, SOC 2 report, data-processing addendum, subprocessor register, vulnerability-disclosure policy, encryption-at-rest description, backup design, recovery objective, or contractual breach-notification timetable. The security section on the marketing page says the company follows best practices and audits its application and servers, but it does not provide evidence that a third party can evaluate.

For many DNS customers, the provider stores mostly public records. That does not make the account low-risk. Unpublished future endpoints, domain-control TXT values, API keys, repository URLs, user identities, change history and billing data can be sensitive. Compromise of the authoritative account can redirect web traffic, alter mail routing, enable fraudulent certificate issuance if CAA and validation paths are changed, or break service globally. Web redirect and email forwarding features expand the provider's role beyond authoritative responses and deserve separate data-flow review.

NIST's March 2026 Secure DNS Deployment Guide treats DNS as an enterprise-wide security dependency and emphasises role-specific protection, logging, monitoring and defence in depth. Applied to LuaDNS, that means the buyer should not ask only whether DNSSEC exists. It should ask how administrative access is protected, whether multi-factor authentication can be enforced, how account recovery is verified, how support authenticates emergency requests, whether logs can be exported, how backups are tested, and how the answering service is isolated from the application and build systems.

The result is not a negative verdict. LuaDNS exposes more technical detail than many small services, maintains a long changelog and publishes past incidents that could simply have been omitted. But its public assurance layer remains aimed at developers, not compliance teams. A buyer with formal obligations must obtain evidence directly or use the service only within a design whose external secondary, registrar controls and rapid exit reduce the consequence of unanswered questions.

Incidents reveal dependencies more clearly than architecture diagrams

The status history is sparse, so it should not be treated as a complete availability record. It is nevertheless valuable because each entry names a different operating dependency.

The 2018 routing-daemon failure shows a common anycast control risk. The 2023 API hardware issue shows that management availability can depend on an individual host or hardware boundary even when authoritative service may continue. The 2024 queue delay shows that accepted changes and globally distributed changes are separate states. The 2025 Heroku event shows that Git builds depend on a third-party platform. Mail-forwarding delays in 2025 show that auxiliary services have their own failure modes and should not be folded into DNS uptime.

The company's public technology list adds other dependencies without mapping them to precise components. TinyDNS and its DNSSEC patch appear in the answering stack; Go, Lua and Elixir appear in service construction; Nginx and Linux are named; Puppet and Nagios are described for deployment and monitoring. The 2018 event identifies BIRD in routing. Open-source components can improve inspectability and reduce licence dependence, but they still require patching, integration knowledge and maintained operator expertise.

A buyer should ask for a service dependency map divided into answer plane, routing plane, signing plane, control panel, API, Git builder, notification service, analytics and billing. For each, it should ask whether failure stops answers, stops changes, delays changes or only reduces visibility. That distinction determines the right response. If the Git builder is down but the API works, a rehearsed emergency path may be enough. If all routes to the anycast prefixes disappear, no control-panel action fixes reachability.

Independent incidents elsewhere show why this separation matters. In February 2026, Clerk reported that an outage at its DNS provider made some APIs unreachable even though the underlying application infrastructure was healthy; its postmortem also noted that its own monitoring had not explicitly checked authoritative nameserver uptime. The lesson for a LuaDNS customer is not that one provider's incident predicts another's. It is that application monitoring which begins after name resolution can miss the dependency that prevents the monitor itself from finding the application.

Support, abuse response and the key-person question

LuaDNS promises access to real people and publishes a general contact address. Its RIPE organisation also has a separate abuse role and mailbox. This is better than an anonymous service with no accountable network contact. Yet the public pages do not state support hours, severity definitions, response targets, telephone escalation, languages, named support tiers or an abuse-handling timetable.

Those omissions matter differently by customer. A developer moving a low-risk zone may be satisfied after receiving a knowledgeable answer from the founder. A business whose domain controls authentication, payments or incident communication needs to know who answers at 03:00 UTC, how an emergency requester proves authority, and what happens if the usual expert is unavailable.

The public record raises a key-person question without proving a one-person operation. The about page centres the founder. The GitHub organisation shows no public members, but private membership is invisible. Romanian data reports zero average employees in 2024 and 2025, but owners and contractors may not appear in that number. The service has operated for nearly fifteen years, which suggests durable knowledge and automation. The correct conclusion is therefore not “there is only one operator”; it is “staffing depth and succession are not publicly evidenced.”

Contract diligence should ask who holds routing, signing, infrastructure and account-recovery knowledge; whether more than one person can perform every critical action; how credentials and documentation survive illness, departure or a corporate transaction; and whether a successor could continue the service. A current corporate extract, insurance position, business-continuity plan and named escalation chain are proportionate requests for a critical domain even when the annual invoice is small.

Abuse handling deserves its own test. Authoritative providers can receive reports about phishing, malware or other misuse of domains using their service, while having limited ability or legal basis to judge content. ICANN's 2025 complaint guide emphasises directing evidence to the party able to act. Buyers should ask what LuaDNS considers actionable, how it authenticates complainants, when it warns a customer, when it suspends service, how it handles manifestly false reports, and how an urgent security contact differs from ordinary support.

LuaDNS has an exit door, but customers must keep it clear

Vendor exit is unusually important in authoritative DNS because a customer cannot simply wait for an account problem to resolve. The registrar delegation, cached NS records, cached answers and DNSSEC chain all have their own clocks. A hurried move can create a longer outage than the event that prompted it.

LuaDNS provides several useful exit primitives. Zones and records can be exported in CSV. Standard BIND files can be used as source for the supported record set. The API can enumerate zones and records. AXFR can continuously copy ordinary zone data to external secondaries. Git keeps configuration and history in an account controlled by the customer. These features substantially reduce captivity compared with a service that exposes records only through a proprietary console.

The strongest exit design uses those primitives before trouble. Keep the authoritative source in a repository the customer owns. Produce a regular machine-readable export of effective records, not just Lua source. Run an external secondary on another provider and monitor serial equality. Retain registrar access under separate credentials. Document every DS record and signing transition. Maintain an inventory of service-specific functions that will not survive as plain DNS.

The last point is where switching cost hides. ALIAS, REDIRECT, FORWARD, templates, clones and Lua-generated logic are not portable protocol records in the same way as A, MX or TXT. A CSV or AXFR export may preserve the resulting addresses and text but not the intention, polling behaviour, redirect service, mail forwarding or reusable program that produced them. The public BIND parser also supports a narrower set than the full service. A buyer seeking maximum portability should use standard records where practical and treat each provider-specific helper as a documented dependency with a replacement design.

DNSSEC raises the cost of a rushed exit further. An unsigned zone can often be dual-served while the parent delegation changes. A signed zone requires keys and DS records to remain coherent across old and new providers. If the customer uses LuaDNS's pre-signed AXFR design, it should verify how long the secondary can continue serving valid signatures without fresh transfers. If it moves to another signer, it needs a rollover plan rather than a simple nameserver swap.

Exit testing should happen at least annually. Create a test zone with the same record classes and DNSSEC posture as production. Export it, load it elsewhere, place both providers in the delegation, compare every answer, then remove LuaDNS without a validation failure. Time the work and record which steps require support. The result is not only an insolvency plan. It is leverage in any incident where the answer plane works but the account, API or build path does not.

A buyer's proof should be a failure exercise, not a feature comparison list

LuaDNS offers enough capability for a disciplined proof of service. The test should be designed around the qualification question: how much operational control is exposed, what does the routing footprint really demonstrate, and what must be proved about DNSSEC, change safety, redundancy, abuse response, continuity and exit?

First, prove identity and authority. Obtain a current Romanian company extract for Anverino Software SRL and reconcile the contracting address with the service and RIPE records. Confirm that the invoice, privacy terms, support contact and network resources all refer to the same entity. Ask whether any affiliate, hosting company or individual owns production assets or customer contracts. The public bridge is strong, but a contract should not rely on a footer.

Second, build a representative zone. Include A and AAAA records, MX, CAA, TXT, a wildcard, HTTPS, a deliberately large response and a name that returns NXDOMAIN. If production will use ALIAS, Lua templates, clones, redirects, mail forwarding or DynDNS, include them. Use paid-plan TTLs if that is the intended tier. Verify answers directly from each of the four nameservers over IPv4 and IPv6, UDP and TCP.

Third, test every change path. Make one change through Git, one through the API and one through the web interface. Record the time at which LuaDNS accepts the change, the time at which each authoritative endpoint serves it, and the time at which several recursive resolvers observe it after TTL expiry. Then create a controlled conflict between Git and API state to prove how ignore and ownership rules behave. Revoke the API key and confirm immediate failure. Trigger the documented rate limit in a safe test account and verify backoff.

Fourth, test rollback as an outcome. Introduce a syntactically invalid Git change and confirm that validation prevents distribution. Introduce a syntactically valid but intentionally wrong low-risk value, deploy it, revert it, and measure restoration. Confirm whether activity history shows the actor and both operations. Export that history before the three-month retention window expires. Ask how to preserve logs after a suspected compromise.

Fifth, measure the network rather than admiring the map. Use probes in every market that matters to the business and at least two access networks per important country. Query all four endpoints, both address families and TCP fallback. Collect traceroutes or equivalent path evidence. Compare results with the claimed PoP list and ask Anverino to explain the 22-versus-25 discrepancy. Request a current topology under confidentiality if necessary, including carriers, sites, capacity and route-withdrawal logic.

Sixth, verify route security. Monitor the IPv4 and IPv6 announcements through more than one routing-data source. Alert if the origin changes, the route disappears, the RPKI state becomes invalid, or the prefix becomes visible through an unexpected path. Ask how Anverino tests ROA changes and whether upstreams reject invalid routes. Remember that a valid origin does not validate the whole path.

Seventh, run the DNSSEC lifecycle. Enable signing on the test zone, publish DS through the registrar, and validate from independent resolvers. Query DNSKEY, RRSIG and negative proofs from every authoritative endpoint. Observe a rollover. Add an external secondary and verify its signed answers. Rehearse disablement and provider migration in the correct order. Do not move the critical zones until the team can explain why each stage remains valid.

Eighth, create real routing diversity. Configure an external secondary whose addresses are outside AS41954 and outside the same hosting suppliers where possible. Verify AXFR ACLs, NOTIFY, serial refresh and behaviour during a simulated transfer failure. Temporarily block one provider from the test vantage points and confirm that resolvers continue to obtain consistent answers from the other. Ask whether LuaDNS can support a customer-owned hidden primary if that is a requirement.

Ninth, test control-plane loss. During an agreed window, assume Git builds are unavailable. Make an emergency change through the API. Then assume the API is unavailable and use the documented break-glass path. Finally assume the LuaDNS account is inaccessible and execute the external-secondary and registrar plan. The exercise should identify which failure can be tolerated, which only delays a change and which requires a delegation move.

Tenth, test humans and contracts. Send a normal support question, a clearly labelled high-severity test request and a non-urgent abuse-process enquiry. Measure acknowledgement and technical quality without manufacturing a false incident. Ask for service hours, escalation contacts, maintenance notice, incident communications, recovery objectives, data protection terms and continuity arrangements. If the required evidence does not exist, record that as a design constraint rather than filling the gap with optimism.

Finally, prove exit. Export the effective records, recreate them at another provider, compare behaviour and estimate the time required to move the parent delegation. Identify every Lua-specific function and replace or deliberately retain it. Store the runbook somewhere reachable when the primary domain and normal identity system are unavailable.

This proof is more work than signing up for a $39 plan. That is precisely the point. LuaDNS has priced away much of the financial friction, not the operational consequence of delegation. The customer must decide how much of the saved spend to reinvest in independent monitoring, secondary service and its own controls.

Where LuaDNS fits—and what to watch next

LuaDNS is especially well matched to developers, agencies, infrastructure consultancies and small software companies that manage multiple public zones, prefer source-controlled configuration and can operate an external secondary. Its flat annual pricing is attractive for portfolios whose query volumes are hard to predict. The Lua layer is valuable when many zones share patterns. The API and open-source clients make ordinary automation accessible without committing to a hyperscale cloud platform.

It is less obviously suited, on public evidence alone, to buyers that require a published service-level agreement, formal assurance reports, 24-hour contractual response, customer-controlled signing keys, advanced traffic steering, health-checked failover, long audit retention or a fully documented multi-provider signing design. Such buyers may still use it as one authoritative component, a secondary route to controlled records, or a service for lower-impact domains, but they should not infer enterprise controls from technically capable software.

The most important watchpoint is whether Anverino turns its operational reality into more verifiable public evidence. A reconciled PoP inventory, facility and peering disclosure, clearer incident metrics, a service-level document, an abuse policy, a security page with specific controls, and a continuity statement would materially reduce buyer uncertainty without changing the product. PeeringDB is currently too sparse to do that work, and the website's own footprint count needs correction.

The second watchpoint is control convergence. Activity history, narrower API keys, modern SSH keys and continued DNSSEC work show useful momentum. The next valuable steps would be documented multi-factor enforcement, exportable audit events, conditional or transactional API updates, clearer Git/API conflict semantics, and a tested emergency path independent of the normal build service.

The third is economic durability. LuaDNS has persisted since 2011, which is more meaningful than startup rhetoric. But the combination of very low prices, a broad feature set and a lean public corporate profile makes capacity, succession and attack economics continuing diligence items. A provider can be both small and excellent; excellence becomes easier to buy when the customer can verify how it survives the loss of a site, carrier, platform dependency or key person.

The decisive insight is that LuaDNS does expose substantial operational control. Its Git and Lua workflow is not decorative, its API is usable, its external-secondary support creates a genuine exit route, its prefixes are visibly originated by the named company, and its RPKI authorisations are valid. The public record also shows exactly why control must be paired with independent redundancy: four nameservers share two prefixes, one autonomous system and common operating machinery.

For the right buyer, that is not a reason to reject LuaDNS. It is a reason to buy it as infrastructure rather than as a cheap form. Keep the source, measure the routes, sign carefully, add another authority, rehearse the exit, and make the invisible dependency earn trust through evidence.