DNS Abuse Verification Methodology
Our verification engine enforces strict technical harm definitions, multi-source corroboration, normalized rate calculations, and jurisdictional intelligence tailored for Uganda's Internet infrastructure.
Strict Core Technical Harms Scope
In accordance with international consensus (ICANN, DNS Abuse Institute, and national policy), our Observatory strictly measures and reports on the 5 universally recognized technical DNS harms:
Deceptive websites mimicking banks, government portals, or institutions to steal user credentials.
Domains hosting, distributing, or acting as download nodes for ransomware, trojans, or spyware.
Infrastructure utilized by attackers to direct, update, or exfiltrate data from compromised device swarms.
Bulk email transmission leveraged specifically as the delivery vehicle for phishing links or malware payloads.
Domains or name servers configured for DNS amplification or targeting digital service availability.
Independent Multi-Source Corroboration ($\ge 2$ Feed Rule)
To prevent automated false positives and defend against bad-faith reporting, a domain is never classified as a High-Confidence Finding from a single unverified signal. Our correlation engine enforces:
- Unverified / Single Signal: When a single threat feed or community reporter flags a target, it is logged in our database for monitoring but marked as `Corroborated: false`.
- Corroborated Status ($\ge 2$ Independent Feeds): Only when at least two independent, reputable threat feeds or verified institutional CERT reports confirm active technical harm does our classification engine elevate the case to `High-Confidence Finding`.
Malicious Registration vs Compromised Classification
Remediation strategies depend heavily on whether a domain was created by an attacker or belongs to a legitimate Ugandan institution:
Domains specifically registered or dedicated for abusive activity (e.g. typosquatting `bank-login-ug.com`). These warrant urgent registrar/registry takedown or DNS suspension.
Legitimate institutional domains (e.g., `.ac.ug`, `.or.ug`, or `.go.ug`) whose servers or CMS suffered technical intrusion. Taking down these domains harms legitimate users; our protocol prioritizes notifying institutional owners and CERT teams for server cleanup.
Normalized Rate Calculation per 10,000 Domains
Raw abuse counts distort evaluation because larger registrars naturally manage vastly more domain names. We calculate normalized metrics across all sectors and providers using the standard formula:
This allows objective comparison between large national registrars and specialized boutique providers.
Jurisdiction-Tailored Suggested Reporting Paths
Many automated abuse tools direct all reports to generic ICANN forms or US-based takedown queues, which do not apply directly to `.ug` Country-Code Top-Level Domain (ccTLD) governance. Our engine generates a tailored multi-stage reporting sequence for every finding:
- Step 1 (Hosting Operator): Immediate notification to the hosting infrastructure operator where the malicious server IP resides.
- Step 2 (Institutional Owner / Registrar): Direct notification to the accredited `.ug` registrar of record or institutional technical contact.
- Step 3 (.ug Registry / National CERT): Escalation to the national `.ug` registry operator (`iNetwork`) or `CERT-UG` when threats pose immediate threat to national digital safety.
Historical Provenance & False-Positive Restoration
To maintain absolute scientific and audit integrity, our database never deletes historical case entries or evidence records. When a domain owner provides verification that a finding was a false positive or that the server has been cleaned and secured:
The case transitions cleanly to `Restored / False Positive` state. The timestamped explanation and restoration events are permanently attached to the case lifecycle timeline, preserving complete historical transparency while clearing the domain's active threat status.