Policy Statement on Public DNS Telemetry

1. Purpose and Scope

This public notice describes the legal, technical, and governance standards CodePunch applies when indexing and presenting domain names and related Internet telemetry across its services.

This policy explains the principles governing CodePunch's collection, indexing, presentation, and use of publicly observable DNS and Internet telemetry. It also describes how CodePunch distinguishes public technical data from non-public registrant information and how requests concerning indexed domain names are handled.

2. Security Value of DNS and Certificate Telemetry

DNS, domain, and Certificate Transparency telemetry are important inputs to Internet security, threat intelligence, network defense, abuse investigation, and infrastructure monitoring.

  • Threat Intelligence & Defense: Researchers and defenders use DNS and certificate observations alongside other security data to identify suspicious infrastructure, investigate command-and-control systems, and discover phishing or impersonation activity.
  • Protecting Users: Reducing legitimate visibility into publicly observable infrastructure can make it harder for defenders to investigate abuse and can reduce independent scrutiny of malicious or compromised systems.
  • Internet Resilience: Lawful access to Internet infrastructure metadata supports research, measurement, operational security, and accountability across the DNS ecosystem.

3. Sources: Public and Lawfully Accessible Internet Infrastructure Data

CodePunch derives domain observations from Internet infrastructure and telemetry that is publicly observable or lawfully accessible. We do not obtain domain data by breaching private registry systems or bypassing access controls.

  • Certificate Transparency (CT) Logs: CT provides append-only logs of submitted certificates and precertificates. DNS names contained in certificates or precertificates submitted to public CT logs become observable through those logs. RFC 9162 defines Certificate Transparency version 2.0 and obsoletes RFC 6962.
  • Public DNS Queries & Resolution: CodePunch may observe domain names and resource records through standard DNS resolution and other ordinary protocol interactions under RFC 1034 / RFC 1035 and related DNS standards.
  • Zone and Delegation Data: Where zone-file or delegation data is used, CodePunch obtains it through public sources or authorized registry/ICANN access mechanisms, including applicable zone-file access arrangements, and uses it subject to the terms governing that access.

These sources are technically distinct. Public DNS and public CT data should not be conflated with bulk zone-file access, which may be subject to registry agreements or standardized access terms.

4. No Collection of Non-Public Registration Data or Registrant PII

Domain names and non-public registrant identity information are not the same thing. ICANN's current Registration Data Policy governs the processing of gTLD registration data by contracted registry operators and registrars and distinguishes public registration data from non-public data and lawful disclosure processes.

  • A domain name itself may form part of registration data and is also a DNS identifier that can be independently observable through DNS, Certificate Transparency, zone data, and other Internet infrastructure.
  • CodePunch backend telemetry systems and public APIs do not obtain, index, store, or redistribute non-public WHOIS/RDAP registrant identity or contact data such as registrant names, private physical addresses, private phone numbers, or private email addresses.
  • CodePunch does not treat the existence of a domain string, hostname, DNS record, or Certificate Transparency observation as evidence of a registrant's private identity.

This boundary is verifiable from the published API contracts and response schemas:

  • Domain Activity / DNFeed API v2: exposes domain-name activity, TLD and registry-service metadata, activity dates and counts, keyword statistics, and daily domain-name lists. Fields such as whois_server and rdap_server identify public registry lookup-service endpoints; they are not WHOIS or RDAP registrant records.
  • DNS Data API v2: exposes domain and hostname identifiers, nameserver information, DNS resource records, ASN/TLD metadata, and certificate-derived observed hostnames.
  • TLS Certificates API v2: exposes certificate identifiers and metadata, validity information, subject and issuer fields, SAN hostnames, fingerprints, and parsed X.509 or precertificate detail reconstructed from public Certificate Transparency entries. A public certificate may itself contain subject or organization information; that is certificate content, not WHOIS/RDAP registrant data.

Across these public response schemas, CodePunch does not expose WHOIS/RDAP registrant names, postal addresses, telephone numbers, email addresses, or administrative or technical contact records.

Certain CodePunch-associated public tools may provide optional, user-initiated access to publicly available RDAP information. Such lookups retrieve data directly from the relevant third-party RDAP service and are separate from the CodePunch telemetry corpus and public API datasets. Information returned by the RDAP service is presented as third-party public data and is not incorporated into the CodePunch telemetry corpus.

5. DNS Identifiers and Proprietary Claims

A domain name is a DNS identifier. Operating a TLD does not, by itself, confer exclusive proprietary rights over every second-level label, hostname, dictionary word, or character sequence used beneath that TLD.

  • The operation of an ICANN-contracted gTLD does not by itself convert independently observable DNS identifiers into confidential registrant information or give the registry a general right to prohibit third parties from identifying or cataloging those names.
  • This policy does not deny that valid trademark, copyright, contractual, confidentiality, privacy, or other legal rights may exist in particular circumstances. Any such claim must be assessed on its own facts and applicable law.

6. Jurisdiction and Applicable Process

All registry demands received by CodePunch to date concerning the indexing or display of publicly observable domain names have originated from registry operators or representatives based in the People's Republic of China. CodePunch's response to such demands is set out in Section 7, “Response, Escalation, and Accountability.”

A registry demand, administrative notice, or domestic regulatory citation does not, by itself, establish a binding obligation on CodePunch. Any request for action must identify the legal or contractual basis asserted and the authority or mechanism through which that obligation is said to be enforceable against CodePunch.

7. Response, Escalation, and Accountability

CodePunch may reject unsupported demands and may seek clarification, supporting authority, or appropriate formal process before taking action. Where a request or course of conduct raises broader contractual or governance concerns, we may use the mechanisms appropriate to the issue.

  1. ICANN Contractual Compliance: Where conduct appears to implicate a registry operator's obligations under its ICANN Registry Agreement or an applicable ICANN Consensus Policy, CodePunch may submit the matter through the relevant ICANN Contractual Compliance process. Zone-file-access issues may also be raised through the applicable ICANN zone-file-access complaint mechanism.
  2. ICANN Accountability Mechanisms: The ICANN Complaints Office, Ombuds, or other ICANN accountability mechanisms may be used where an issue falls within their respective remits, including concerns about ICANN org processes or treatment. They are not substitutes for Contractual Compliance where the underlying issue is a registry operator's contractual obligation.
  3. Technical and Community Discussion: Where technically relevant, CodePunch may discuss Internet measurement, DNS-security, or telemetry issues in appropriate technical and governance forums, including DNS-OARC or relevant ICANN community groups. Such forums are venues for technical and community discussion, not enforcement authorities.
  4. Legal Defense: CodePunch will defend legal proceedings where appropriate and may seek costs, fees, sanctions, or other remedies where available under applicable law.

Technical and Policy References