Physician, Heal Thyself: What 82 Enterprise Technology Providers Reveal About Their Own DNS

We scored 59 domains -- global systems integrators, digital consultancies, IT-services majors, and regional technology providers across Russia and the Middle East -- using NODA's dual-axis methodology: a Health score measuring whether DNS actually works, and a Best Practice score measuring whether it's configured the way current standards recommend, across 41 checks in five categories. Alongside the main sector, we separately scored 23 parent/subsidiary pairs -- companies with a well-known acquisition or spin-off sitting inside the same corporate family -- to see whether the child ever outscores the parent, or the reverse.

The sampling frame extends an earlier finding from this research series. Scoring the hyperscale cloud providers (AWS, Azure, Google Cloud, and others) turned up a bottom-5 cluster on Best Practice that included the very companies selling DNSSEC automation, managed DNS, and the broader DNS-reliability tooling to everyone else. This sample asks the natural follow-up question: what about the companies whose entire business is building and operating enterprise architecture -- including DNS -- for other people? Do they practice what their hyperscaler suppliers preach?

A note on scope: this list was compiled from major-vendor and well-known regional-provider domains, not a canonical index of the enterprise IT services industry -- treat it as a representative sample rather than an exhaustive census. All 82 domains were checked live on August 26, 2026; DNS configurations drift, so exact figures will shift over time.

The numbers

Health holds up extremely well across this sample -- consistent with every sector this research has covered, a nearly-solved problem industry-wide. The meaningful variation, as always, sits on the Best Practice axis.

The comparison this sample was built to make

Mean Best Practice for this sample: 82.3, versus 78.7 for the hyperscale cloud providers scored earlier in this research series. The median tells the same story -- 83 versus 79. And the worst score in each dataset is instructive on its own: the lowest Best Practice score among all 59 enterprise-tech domains was 67 (beyon.com); the lowest among the 49 hyperscalers was 64 -- aws.amazon.com's own corporate domain, with azure.microsoft.com and cloud.tencent.com tied close behind at 68.

That is not a small dataset making a large claim -- it is the same NODA-v1.0 methodology, the same 41 checks, applied to two different populations, one of which sells the infrastructure the other one buys. The systems integrators, consultancies, and regional providers in this sample are, on average, more disciplined about their own DNS than the hyperscale platforms whose managed-DNS and DNSSEC-automation products they resell to their own clients.

Of the 41 checks in this methodology, one produces the cleanest cross-sector comparison, because prior research in this series already established benchmark rates against it. That is not a claim that it is the most important check here -- three findings later in this piece, on nameserver concentration, redundancy depth, and one live open-recursor exposure, arguably matter more day to day.

DNSSEC adoption: second-highest of any sector measured

30.5% of domains in this sample have DNSSEC enabled. That places this sector second only to the non-US-mandate government sample (33.8%) scored earlier in this research series -- ahead of DNS/hosting infrastructure specialists (29.2%), financial services (25.3%), and, notably, the hyperscale cloud providers who build DNSSEC automation tooling for other people's domains (20.4%).

DMARC and SPF look strong across this sample too: only 3.4% of domains are missing a DMARC record outright, and DKIM could not be confirmed present at a standard selector on 50.8% of domains -- worth reading carefully, since NODA's own methodology treats an unconfirmed DKIM key as Informational rather than a hard failure (selector names are not standardized, so absence at a guessed selector is not equivalent to confirmed absence of DKIM signing). That figure is a ceiling on uncertainty, not a confirmed failure rate.

Beyond DNSSEC: reliability, redundancy, and one real exposure

DNSSEC gets the headline treatment above because prior sectors in this series give it a clean benchmark to compare against -- but it is one check out of 41, and treating it as a stand-in for "DNS security posture" understates how much else this methodology actually measures. Three findings from the infrastructure and reliability categories in this sample are arguably more consequential day to day than the DNSSEC figure above.

59.3% of domains in this sample (35 of 59) concentrate every authoritative nameserver inside a single Autonomous System -- the same single-point-of-failure pattern this research series has found in every sector measured so far, here at the high end of the range. A single-AS outage, misconfiguration, or targeted attack takes every nameserver down at once regardless of how many individual servers are listed. Where that AS is a large anycast network the practical risk is lower than the raw number suggests; where it is a single non-anycast provider, it is not, and this dataset does not distinguish the two without a further pass.

28.8% (17 of 59) place their nameservers on fewer distinct subnets than NODA's redundancy check recommends, and 42.4% of applicable domains (25 of 59) show the same redundancy-depth gap on their mail-exchange configuration -- both refinements of a "does redundancy exist at all" baseline check that these domains mostly pass. The gap here is in redundancy depth, not redundancy's bare existence.

One finding in this sample is a genuine, unambiguous security exposure rather than a hardening gap: one domain -- orange-business.com -- failed NODA's Open Recursor check, meaning its resolver answers recursive DNS queries from arbitrary requesters on the public internet. An open recursor is a standing reflection/amplification-attack vector (RFC 5358, advisory) and, unlike most findings in this piece, carries no ambiguity about severity: it is a Critical finding on the Health axis, not a Best Practice refinement. Every other domain in this sector passed both the Open Recursor and AXFR/Zone Transfer checks cleanly -- zero zone-transfer exposure anywhere in the sample, worth stating plainly since it is the kind of finding that is only newsworthy in the negative.

A small aside for anyone who spends their working life across DNS, DHCP, and IP address management all at once: none of the three findings above are DNSSEC. If reading a heading called "Beyond DNSSEC" made you exhale a little, this section was written with you specifically in mind.

Regional slices: three cuts, one clear standout

Per-region cohorts were small by design (this is a representative sample, not a census), so these figures are read as directional rather than definitive. Three cuts were checked; all three came back with a real, non-trivial difference from the sample mean.

India-heritage systems integrators (TCS, Infosys, Wipro, HCLTech, Tech Mahindra, LTIMindtree) posted a mean Best Practice score of 88.5 -- the highest cohort in the entire dataset, 6.2 points above the sample mean. Russia-based providers (Yandex, Kaspersky, Sber/SberTech, CROC, TechnoServ, IBS, 1C) came in at 85.6, also above the mean. Middle East providers (elm.sa, Ooredoo, G42, core42, e&, Zain, Beyon, ITWorx) landed almost exactly at the sample mean, 81.6.

The counterintuitive cluster: agile branding doesn't predict DNS hygiene

The bottom of this sample's Best Practice distribution held a genuine surprise, and it's a bigger one once the full tie is visible. Ten unrelated companies land on the identical score of 71, and they span both ends of any "brand era" story you could tell about them. Globant, Thoughtworks, and Slalom market themselves on modern, agile, digital-native engineering culture; PwC is a Big Four traditionalist; Fujitsu and Indra are legacy hardware-and-systems generalists; core42, e&, WWT, and Genpact round out the group. All ten score exactly 71. Whatever produces this specific number, it is not how recently a company's brand was refreshed, how "digital-native" its positioning is, or how old the company is -- the tie cuts across every one of those categories at once.

Best and worst performers

Top scores (Best Practice) -- six domains, including a three-way tie at 92:

Bottom scores (Best Practice) -- eleven domains, including a ten-way tie at 71:

All seventeen are genuine, resolving domains with specific, checkable Best Practice gaps -- not artifacts of a bad domain list. Every domain in the bottom group has a Health score of 92 or higher: these are companies whose DNS works fine today, with headroom against recommended standards rather than active operational risk.

Parent and subsidiary: does the acquisition outscore the acquirer?

Twenty-three domains were scored separately as parent/subsidiary pairs -- companies with a well-known acquisition, spin-off, or sibling relationship inside the same corporate family. These are not part of the top/bottom/mean/median figures above; they are a narrower, more anecdotal set, read here as short comparisons rather than statistics.

The single sharpest pair in the whole dataset: Google's own corporate domain scored 67 on Best Practice -- tied for the worst score in the main sector table -- while Mandiant, the threat-intelligence subsidiary Google acquired in 2022, scored 86, nineteen points higher. IBM's own domain scored 71; Kyndryl, IBM's infrastructure-services arm spun off in 2021, scored 87 -- sixteen points higher, from the literal "we run your data center" business.

The pattern is not universal. HPE scored 79, ahead of Aruba Networks, its own networking-specialist subsidiary, at 71 -- the parent outscoring a child whose entire business is the network hardware and protocols this methodology measures. Cisco's family split three ways: Splunk scored 90, well above its parent's 79, while Meraki and Duo both came in at 71, below it. Salesforce, at 92 among the highest scores in either dataset, sits above every one of its own acquisitions measured here -- Slack (86), Tableau (75), and MuleSoft (86) -- the reverse of the Google and IBM pattern. Deutsche Telekom's family shows the same pattern as IBM and Google: the parent scored 71, against T-Systems' 83 and T-Mobile US's 79.

One entry needs a correction rather than a comparison: ntt.com, nttdata.com, and global.ntt were originally treated here as sibling companies, the way IBM/Kyndryl or Google/Mandiant are. That is no longer accurate. NTT Ltd -- the entity historically behind global.ntt -- was operationally combined with NTT DATA, Inc. across 2022-2024, and by April 2024 the two were unified under one global operating model and leadership structure. The three domains are, today, DNS zones inside what is corporately a single combined organization, not three independent siblings. The 16-point spread between them (71 to 87) is still a real, checkable finding -- it just describes internal inconsistency within one merged company rather than a parent-versus-acquisition story, and we're correcting the framing here rather than leaving it uncorrected.

A note on our own configuration

NODA and MarinaDNS are not exempt from the standard this article applies to everyone else. Several of the findings above describe a genuinely fragile category of operational commitment: not a one-time setup task but something that has to be re-verified on a schedule with no natural forcing function until it breaks -- DNSSEC key rotation and algorithm hygiene, yes, but equally nameserver-redundancy audits after infrastructure changes, and periodic external checks for the kind of silent exposure the Open Recursor finding above represents. That difficulty is real, not an excuse offered after the fact; it is the same operational shape this piece describes for everyone else in it. Where our own configuration has room to improve against NODA's own Best Practice axis, the fix is the one this article recommends to every other domain in it: treat these as recurring maintenance commitments, not one-time projects.

The takeaway

This sector offers a genuinely useful counterpoint to the hyperscaler finding that motivated it: the companies whose entire business is enterprise architecture are not, on this evidence, worse at DNS hygiene than the cloud platforms underneath them -- they are measurably better, on both the headline mean and the median. The real signal in this dataset is not "consultancies are disciplined" as a blanket claim -- it splits by region (India-heritage integrators lead clearly), by brand positioning (agile-branded boutiques cluster at the bottom, not the top), and inside individual corporate families (some acquisitions inherit better discipline than their parent, some inherit worse). Whatever produces good DNS hygiene, it is not a single trait that travels cleanly with company size, age, or market positioning.

What to do about it

For enterprise technology providers and their clients specifically:

• If you're evaluating a vendor, check their own domain first -- a consultancy selling DNS/DNSSEC hardening as part of an engagement has a checkable, public signal about whether they practice it themselves.
• After an acquisition, resolve DNS ownership explicitly and early -- the parent/subsidiary gaps in this dataset are most plausibly explained by unclear operational ownership, not technical capability.
• Audit nameserver and mail-exchange redundancy after any infrastructure migration -- ASN concentration and redundancy-depth gaps are the kind of thing that creeps in quietly during a cloud migration or vendor switch, not something anyone decides on purpose.
• Run an open-recursor check on a schedule, not just at initial setup -- it is invisible from the inside and only costs you when someone else notices first.
• Treat DNSSEC as recurring maintenance, not a one-time project -- key rotation and algorithm hygiene are the parts that lapse quietly once the initial signing project is marked complete.

Curious where your own domain lands? Run it through NODA and see the same 41 checks scored live.

⇩ Download full report (PDF, 82 domains)