ecosyste-ms / ecosyste-ms/roadmap

domains.ecosyste.ms - DNS and registration monitoring for OSS-related domains

Open
#39 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
22
Forks
2
PR merge metrics
No merged PRs in 30d

Description

A service that collects domain names referenced across ecosyste.ms data (maintainer emails, package homepages, repository URLs, registry hostnames, advisory references, funding links) and tracks their WHOIS, registration expiry, nameserver changes and ownership transitions over time.

The OSS supply chain leans heavily on DNS. Maintainer email domains gate password resets on every package registry, package homepages and documentation sites are linked from registry metadata, and project infrastructure (download mirrors, CI webhooks, plugin marketplaces) is addressed by name. Almost none of this is monitored, and domain resurrection is a known and exploited account-takeover vector. PyPI does it inline at the account level via the Domainr and Fastly status APIs (see https://github.com/pypi/warehouse/blob/028cedf773fbc8317acffaf23dd467516d40ffaa/warehouse/accounts/services.py#L1197-L1278), but there is no ecosystem-wide view.

Inputs the service would already have via the existing ecosyste.ms services:

- Maintainer and contact email domains from packages.ecosyste.ms across every registry.
- Homepage, documentation, source, bug tracker and funding URLs from package and repository metadata.
- Registry and mirror hostnames themselves.
- Domains referenced in advisories.ecosyste.ms (advisory URLs, references, affected URLs).
- Domains referenced in commit metadata (committer emails, sign-offs).

What the service would track per domain:

- Registration status (active, pending delete, expired, available), expiry date, registrar, creation date.
- Nameserver set and changes to it over time.
- WHOIS contact churn at the level of "did this change" rather than republishing PII.
- DNS resolution and a basic record snapshot (A, MX, NS, TXT relevant to email auth).
- Aggregate "this domain is used by N maintainers across M packages and K advisories" so the blast radius of a single expiry is visible.

Privacy: public APIs and web pages should not republish WHOIS PII. The useful public signal is "registered/expired/changed", expiry windows, registrar identity, and aggregate usage counts. The detailed history can live behind authenticated or batch access and respect registrar terms of service.

Security uses this enables:

- Alerting when a domain used by an active maintainer email is within N days of expiry, or has just lapsed.
- Detecting nameserver or registrar transfers on domains that own a lot of trust (registry hostnames, widely-linked homepages, advisory references).
- Flagging packages whose homepage or source domain has gone dead or changed hands, which is often the first visible sign of an abandoned-then-hijacked project.
- Giving registries a shared signal so the PyPI-style check does not have to be reimplemented per ecosystem.

Open questions: which WHOIS source to use (RDAP where available, falling back to per-TLD WHOIS), how often to refresh (cheap for the long tail, more aggressive for high-blast-radius domains), and how much DNS history to retain.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.