SLA Compliance Dashboard
Free Tier Data (Hourly)| TLD | Operator | DNS Avail. | DNS RTT | RDDS Avail. | RDDS RTT | TSLAC |
|---|---|---|---|---|---|---|
| .asia | DotAsia Organisation Limited | 100% | 228ms | 100% RDAP | 176ms | |
| .biz | Registry Services, LLC | 100% | 198ms | 100% RDAP | 130ms | |
| .ca | Canada | 88.89% | 33ms | 50.00% RDAP | 50ms | |
| .com | VeriSign, Inc. | 100% | 22ms | 100% RDAP | 68ms | |
| .eu | European Union | 100% | 234ms | 50.00% WHOIS | 655ms | |
| .mx | Mexico | 100% | 82ms | 25.00% WHOIS | 8273ms | |
| .org | Public Interest Registry | 100% | 228ms | 100% RDAP | 430ms | |
| .pr | Puerto Rico | N/A | N/A | — | — | — |
| .укр (xn--j1amh) | Ukraine (Cyrillic) | 100% | 156ms | — | — | |
| .شبكة (xn--ngbc5azd) | International Domain Registry… | 100% | 16ms | 100% RDAP | 100ms |
RTT shows 95th percentile (p95) per Spec 10. Marginal = within 20% of threshold.
DNSSEC Validation Metrics
Registry Agreement Spec 6DNSSEC is required by the Registry Agreement (Specification 6) but is not part of the Spec 10 SLA. We monitor DNSSEC validation independently to track operational health.
| TLD | Operator | DNSSEC Validation | DNSSEC RTT | Status |
|---|---|---|---|---|
| .cloud | Aruba PEC S.p.A. | 100% | 39ms | |
| .cn | China | 100% | 241ms | |
| .de | Germany | 100% | 51ms | |
| .in | India | 100% | 40ms | |
| .net | VeriSign, Inc. | 100% | 38ms | |
| .nz | New Zealand | % | 182ms | |
| .se | Sweden | 100% | 164ms | |
| .shop | GMO Registry, Inc. | 100% | 33ms | |
| .space | Radix Technologies Inc SEZC | % | 54ms | |
| .technology | Binky Moon, LLC | 100% | 156ms | |
| .us | United States | 100% | 19ms | |
| .xyz | XYZ.COM LLC | 94.44% | 589ms |
DNSSEC validation checks that the TLD's DS records are properly configured and that responses are correctly signed. Unlike Spec 10 services, DNSSEC has no formal availability SLA—thresholds shown are operational guidelines.
Root Zone Servers
InfrastructureThe 13 root servers are the foundation of the DNS hierarchy. While not subject to ICANN Spec 10 SLAs, we monitor them using the same standards to verify Internet infrastructure health.
| Server | Operator | IPv4 | IPv6 | Anchor | Status |
|---|---|---|---|---|---|
| a.root-servers.net | Verisign | 18ms | 19ms | ||
| b.root-servers.net | USC-ISI | 227ms | 189ms | ||
| c.root-servers.net | Cogent | 2.3ms | 1.9ms | ||
| d.root-servers.net | UMD | 1.5ms | 1.4ms | ||
| e.root-servers.net | NASA | 1.5ms | 1.3ms | ||
| f.root-servers.net | ISC | 1.4ms | 1.5ms | ||
| g.root-servers.net | DISA | 11ms | 11ms | ||
| h.root-servers.net | US Army | 23ms | 23ms | ||
| i.root-servers.net | Netnod | 42ms | 27ms | ||
| j.root-servers.net | Verisign | 0.87ms | 0.76ms | ||
| k.root-servers.net | RIPE NCC | 40ms | 27ms | ||
| l.root-servers.net | ICANN | 22ms | 18ms | ||
| m.root-servers.net | WIDE | 47ms | 48ms |
Root servers are operated by 12 independent organizations worldwide. View detailed root zone metrics →
DNS Protocol Quirks
Active IssuesTLDs exhibiting non-standard DNS behavior that may affect resolution or DNSSEC validation. These issues were observed in the last 24 hours.
| TLD | Issue | First Observed |
|---|---|---|
| .qa |
aa_missing
— Authoritative response without AA bit
|
2026-01-31 05:30 UTC |
| .qa |
edns0_ignored
— EDNS0 OPT absent in NOERROR response
|
2026-01-30 07:26 UTC |
| .قطر (xn--wgbl6a) |
aa_missing
— Authoritative response without AA bit
|
2026-01-31 05:24 UTC |
| .قطر (xn--wgbl6a) |
edns0_ignored
— EDNS0 OPT absent in NOERROR response
|
2026-01-30 07:24 UTC |
Protocol quirks like rrsig_missing_udp indicate nameservers silently dropping
DNSSEC signatures in UDP responses without setting the truncation bit, which breaks validation.
About TSLAC
TLD SLA Compliance (TSLAC) provides independent monitoring of domain registry service levels. We measure the same metrics defined in ICANN Registry Agreement Specification 10 using a distributed probe network.
While ccTLDs operate under their own national policies rather than ICANN contracts, we believe all of the Internet should aspire to the same operational standards. Spec 10 thresholds represent reasonable baselines for reliable DNS and RDDS services—we apply them uniformly to help identify where improvements benefit everyone.
Disclaimer: We are not ICANN, do not operate SLAM probes, and make no claim that our measurements are authoritative or legally binding. Our probe locations, network paths, and timing will differ from ICANN's infrastructure. Anycast routing means your results may vary. We follow MoSAPI methodology in spirit but cannot replicate it exactly. This service is provided for informational purposes—for official SLA compliance determinations, consult ICANN's published data.
ICANN SLA Thresholds
These thresholds are defined in the ICANN Registry Agreement Specification 10 and the 2023 Global Amendment for RDAP.
RDDS (Registration Data Directory Services) includes both RDAP and WHOIS protocols.
Methodology
Availability Calculation
Per ICANN MoSAPI specification, DNS and RDDS use different availability rules:
DNS Availability (2-of-N Rule)
Per MoSAPI: “The Service is considered up if at least two of the delegated name servers have successful results from tests to each of their public-DNS registered IP addresses.”
- A nameserver is “up” if all its registered IPs (IPv4 and IPv6) respond
- The TLD is “available” if ≥2 nameservers are up
RDDS Availability (Simple Success Rate)
RDDS (RDAP/WHOIS) uses a simple success rate—each query is evaluated independently:
A check is successful if the service responds within the protocol timeout (DNS: 2500ms UDP, RDAP: 20000ms). A check meets Spec 10 thresholds if it also responds within the RTT limits defined in the ICANN Registry Agreement.
Probe Consensus
Following ICANN SLAM methodology, we use multiple geographically distributed probes. A service is considered unavailable during a measurement window if ≥51% of reporting probes observe failures. This prevents a single probe's network issues from triggering false incidents.
RTT Percentiles
Round-trip time (RTT) is measured from query sent to response received. Spec 10 requires 95% of queries to be faster than the threshold (p95 ≤ limit):
- p50 (median) — Typical performance; half of queries are faster
- p95 — Spec 10 threshold; 95% of queries must be faster than this limit
For DNS, p95 must be ≤500ms. For RDAP, p95 must be ≤4000ms.
Status Indicators
We evaluate availability and RTT separately. Spec 10 thresholds differ by service: DNS requires ≥99% availability, RDDS requires ≥99.5%.
Data Aggregation
Public metrics are aggregated hourly to provide meaningful trends while protecting operational details. Paid monitoring tiers receive higher-resolution data with per-minute granularity matching ICANN SLAM cadence.