I thank ICANN and the multistakeholder community for convening this important discussion and for the opportunity to contribute to the public comment process on DNS Abuse Mitigation.

Framing

This comment responds directly to the Preliminary Issue Report’s request for input on remaining gaps in DNS Abuse Mitigation. One such gap is the lack of a standardized, audit‑ready way to handle subdomain abuse. Attackers frequently exploit disposable subdomains (e.g., login.bank123.com) for phishing and malware. Today, these subdomains appear and disappear without lifecycle logging, leaving contracted parties with no uniform way to demonstrate compliance. The URL Resolution Surface Protocol (URLRSP) and its RDRLNK (Resolved Domain Resource Link) component address this gap by creating a trusted, auditable namespace for intentional short‑linking.

Executive Summary

This comment highlights a mitigation gap in DNS abuse enforcement: the absence of a standardized, audit‑ready response format for resolution events. The proposed safeguard approaches — the URL Resolution Surface Protocol (URLRSP) and its RDRLNK component — provide first‑party, branded, audit‑ready mechanisms that strengthen contracted parties’ ability to comply with DNS abuse obligations. These safeguards should be considered within the scope of any PDP the GNSO Council initiates.

Problem

DNS abuse mitigation today lacks a standardized, survivable response format. While registries and registrars are obligated to address abuse, the absence of a common, audit‑ready mechanism for capturing and reporting resolution events creates ambiguity in compliance and weakens enforcement. This gap undermines both accountability and trust in the DNS ecosystem.

This safeguard directly mitigates phishing and pharming patterns that exploit disposable subdomains and opaque redirects, both of which fall squarely within ICANN’s DNS Abuse definition. It also strengthens contracted parties’ ability to respond to malware, botnet, and spam‑as‑delivery incidents by providing a verifiable resolution trail.

Proposed Safeguard Approaches

The URL Resolution Surface Protocol (URLRSP) and its RDRLNK (Resolved Domain Resource Link) component represent safeguard approaches that strengthen DNS abuse mitigation.

What RDRLNK is: An RDRLNK is technically a subdomain, but unlike ordinary subdomains it is intentionally minted and resolved through URLRSP. For example, today 23.icann.org does not exist and would return a 404. Under URLRSP, an operator can mint 23.icann.org as an RDRLNK, which resolves through the standardized surface into a full resource (e.g., icann.org/policy/abuse-mitigation).

Namespace integrity: Unlike existing redirect tools, URLRSP ensures that every RDRLNK resolves only to a resource within the same registered domain. For example, 23.icann.org will always resolve to a page under icann.org, never to an external site. This preserves brand integrity, prevents deceptive cross‑domain redirection, and guarantees that the landing page is always within the operator’s namespace.

What it does not do: URLRSP does not prevent malicious subdomains (e.g., login.bank123.com) from being created. Instead, it provides contracted parties with a standardized, audit‑ready way to respond once abuse is identified, ensuring that abusive subdomains can be retired or redirected in a verifiable, policy‑aligned manner.

Why it matters: This closes the current gap where subdomain abuse is opaque and unmeasurable. By providing a standardized, audit‑ready record of resolution events, URLRSP and RDRLNK give contracted parties a measurable way to demonstrate they acted “promptly” under RA §4.2 and RAA §3.18.

Comparative Advantage and Adoption Path

Unlike today’s redirect approaches — where operators rely on opaque third‑party shorteners or ad‑hoc redirect scripts — RDRLNK keeps the branded domain visible (e.g., 23.icann.org instead of redirect.com/xyz) and ensures every resolution event is logged in a standardized, audit‑ready format.

To support adoption, a public service (RDRLNK.com) could allow any domain owner to generate RDRLNKs. For registered subscribers, links would appear under their own namespace (e.g., 23.icann.org → icann.org/...), while non‑subscribers could still generate links under a neutral namespace (e.g., 23.non-registered.rdrlnk.com → non-registered.com/...). An API would be available for registered domains to integrate directly into their sites and workflows, ensuring scalability and ease of use.

Multistakeholder Alignment

URLRSP and RDRLNK are consistent with ICANN’s multistakeholder model because they empower both large operators and small domain owners to participate in a standardized safeguard. A global platform like RDRLNK.com ensures that even the smallest registrant can adopt the same audit‑ready practices as the largest registry, reinforcing ICANN’s commitment to inclusivity and equal access to security tools.

Interoperability and Incremental Adoption

Because URLRSP operates entirely within existing DNS resolution flows, it requires no protocol‑level changes and can be adopted incrementally. This ensures interoperability with current infrastructure while allowing contracted parties to integrate the safeguard at their own pace, minimizing disruption and maximizing feasibility.

Compliance and Trust Benefits

Standardized resolution envelopes provide verifiable records that enable ICANN Contractual Compliance to assess whether contracted parties acted promptly and consistently, reducing ambiguity in enforcement. By ensuring that every RDRLNK resolves only within the operator’s domain, URLRSP reduces consumer confusion, strengthens brand integrity, and restores trust in DNS navigation.

Request

I respectfully urge the GNSO Council to consider including URLRSP and RDRLNK (or equivalent standardized safeguard approaches) within the scope of the forthcoming Policy Development Process on DNS Abuse Mitigation. Incorporating these safeguards will not only close a present enforcement gap but also establish a model for lightweight, audit‑native safeguards that can evolve with the DNS ecosystem.

Respectfully submitted,  

Isaac Omar

Visionary Protocol Architect, Solo Inventor, and Legal Strategist  

On behalf of the proposed OGIEX initiative (not yet incorporated)  

This comment identifies a key gap: the absence of a standardized, audit‑ready way to handle subdomain abuse. Attackers exploit disposable subdomains (e.g., login.bank123.com) for phishing and malware, which appear and vanish without lifecycle logging. This leaves contracted parties unable to demonstrate compliance with RA §4.2 and RAA §3.18 obligations to act promptly on abuse.

The proposed safeguard approaches — the URL Resolution Surface Protocol (URLRSP) and its RDRLNK component — address this gap by creating intentionally minted, branded short‑links that always resolve within the operator’s domain. Unlike opaque redirect tools, every resolution event is logged in a standardized, audit‑ready format. For example, 23.icann.org would always resolve to a page under icann.org, never to an external site. This preserves namespace integrity, prevents deceptive cross‑domain redirection, and provides measurable evidence of abuse handling.

To support adoption, a public service (RDRLNK.com) could allow any domain owner to generate RDRLNKs, with an API for registered domains to integrate directly into their sites and workflows. Because URLRSP operates within existing DNS resolution flows, it requires no protocol‑level changes and can be adopted incrementally, ensuring interoperability with current infrastructure.

URLRSP and RDRLNK align with ICANN’s multistakeholder model by enabling both large operators and small domain owners to adopt the same audit‑ready practices. By ensuring that every RDRLNK resolves only within the operator’s domain, the safeguard reduces consumer confusion, strengthens brand integrity, and restores trust in DNS navigation.

I respectfully urge the GNSO Council to include URLRSP and RDRLNK (or equivalent standardized safeguard approaches) within the scope of the forthcoming Policy Development Process on DNS Abuse Mitigation.

Respectfully submitted,

Isaac Omar

On behalf of the proposed OGIEX initiative (not yet incorporated)