Phpwhois Laravel Package

Technical Evaluation

Architecture fit — poor as a Laravel component, acceptable as a raw PHP dependency. This is not a Laravel package: no service provider, no facade, no config/ publishing, no extra.laravel auto-discovery. It is a framework-agnostic Composer library of per-TLD handler classes (WhoisHandler, WhoisParser, socket client) that must be instantiated manually. Any use in our app requires us to author the container binding, configuration surface, and adapter ourselves.

Integration feasibility — mechanically easy, production-readiness is the real question. composer require works; instantiation is a few lines. But the library performs synchronous, blocking TCP/43 socket I/O via fsockopen/sockets — it does not use Guzzle or Laravel's HTTP client, which means we lose Http::fake(), middleware, retry policy, proxy config, and per-request timeout governance. Every call must be pushed into a queued job by us.

Technical risk — several, in descending severity:

• License (high). GPL-2.0 is copyleft. Internal, non-distributed SaaS use is typically defensible; distributing the library inside a shipped product (or any derivative) triggers source-release obligations for the derivative work. This is a hard blocker for a commercial/on-prem distribution path and warrants counsel sign-off before adoption, not after.
• Protocol obsolescence (high). This library speaks legacy WHOIS only. ICANN has standardized on RDAP for gTLDs, with WHOIS sunset for gTLDs; many registries throttle, filter, or decommission port 43. A WHOIS-only library is betting against the protocol direction of travel.
• Stale parser surface (medium-high). Parsing is regex/string matching per-TLD handler. TLD registry formats drift continuously; a 2021 handler table will silently return partial or null fields rather than erroring — the worst failure class for data consumers.
• Maintenance signal (medium). 1 star, 0 dependents, last release June 2021, single maintainer. No evidence of CI, test suite, or security advisory channel. PHP 8.2/8.3/8.4 deprecation compatibility is unverified.
• Security surface (medium). Outbound raw sockets to registry-advertised hosts, with user-supplied domain input, is an SSRF-shaped risk if the handler table or referral chain is ever influenced by input. Untrusted remote responses feed regex parsers, so pathological-response CPU burn is possible.

Key questions for the technical spike:

1. Does it install and run clean on our PHP version without deprecations or fatal errors?
2. What is the actual parse success rate across our top 20 TLDs by request volume — and does it fail loudly or silently?
3. Does our hosting/egress allow outbound TCP/43? (Many cloud providers and PaaS platforms block or rate-limit it.)
4. Is there a distribution path for this code, now or in 18 months, that triggers GPL-2.0 obligations?
5. Who is the named internal owner of the TLD handler table if we adopt?

Integration Approach

Stack fit. Composer/PSR-4 library loads into Laravel 8–11 without conflict risk — precisely because it has no framework coupling and almost no dependency tree. That same thinness is why we own the integration layer entirely. Confirm ext-sockets/ext-filter/ext-ctype availability in our runtime image before committing.

Migration path — adopt behind an interface, never call it directly. Define a DomainLookupService contract in our domain layer with a driver-based implementation (rdap, whois, commercial_api). Bind the driver via config and the container. This makes the library a swappable leaf dependency rather than an ambient dependency, and lets us add RDAP-first/WHOIS-fallback routing without touching call sites. Given the repo is small and the license is GPL-2.0, an internal fork under our own namespace is plausible — but a fork inherits the license, so it does not resolve the distribution question.

Compatibility. Pin an exact version and lock it; there will be no upstream patch stream, so a pin is a durable decision, not a temporary one. Audit the handler directory for hardcoded server names/ports before trusting it. Verify behavior on IDN/punycode input, which is a common parser blind spot.

Sequencing:

1. License review (counsel, 1–3 days) — gate everything else on this.
2. Spike + benchmark (2–3 days) — sandbox install, run our top-20-TLD sample, record success rate, latency p50/p95, and silent-failure rate.
3. Adapter + queue + cache (3–5 days) — interface, queued job with timeout/backoff, cache with multi-day TTL.
4. RDAP-first routing (3–5 days) — IANA RDAP bootstrap as primary, WHOIS as fallback.
5. Instrumentation (1–2 days) — per-TLD success/latency/error metrics, alerting on silent-parse degradation.
6. Decision gate — keep, fork, or replace with a commercial WHOIS/RDAP API, decided on measured coverage vs. cost of ownership.

Operational Impact

Maintenance — the dominant cost, and it is ours. Upstream is effectively dormant: one release, 2021, one star, zero dependents. We inherit the per-TLD handler table, which is a perpetually drifting artifact as registries change formats and new TLDs delegate. Budget a fractional engineer per quarter for handler repair plus one-off work for each PHP major/minor bump. Treat this as a decaying asset in the roadmap, not a stable dependency.

Support. No community, no issue triage, no CVE feed. Internal ownership is mandatory: one named engineer, one runbook, documented fallback behavior for "no parser for this TLD." Without that, the first registry change becomes an unowned incident.

Scaling — the primary architectural constraint. Synchronous socket calls consume a PHP-FPM worker for 0.5–3s per lookup, plus referral hops. All lookups must run on Horizon/queue workers with per-registry concurrency caps, exponential backoff, and aggressive response caching (WHOIS data changes on the order of days, not seconds). No batching or connection reuse; each query and each referral is a fresh connection. Throughput scales by adding workers, not by optimizing the library.

Failure modes to design for explicitly:

• Port 43 egress blocked by the hosting provider — fails 100% of lookups at deploy, often discovered in production. Verify during the spike.
• Registry throttling/blackholing — increasingly common for gTLDs; surfaces as timeouts or truncated responses, not clean errors.
• Silent parse degradation — regex misses yield partial records with no exception. This is the most dangerous mode; it corrupts downstream data without tripping an alert. Mitigate with field-level presence assertions and a canary set of known-good domains checked on a schedule.
• Worker starvation from hung sockets lacking aggressive timeouts.
• Missing TLD handler — throws or returns empty depending on entry point; needs a defined product behavior (graceful "not supported," not a 500).
• IDN/unicode domains — normalization gaps produce wrong or empty results.

Ramp-up. Basic usage is hours. Production-hardened usage is roughly 1–2 weeks of engineering across the sequencing above, plus counsel time, plus ongoing handler maintenance. That is a large multiple of the effort implied by "composer require a WHOIS library," and it should be scoped against the alternative of a paid API that absorbs protocol churn, rate limits, and parser maintenance entirely.

Recommendation. Do not adopt as a primary dependency. Use it at most as a narrow WHOIS fallback behind an RDAP-first interface, contingent on a clean license review and a spike that proves outbound port 43 plus acceptable top-20-TLD coverage. If either gate fails, replace with a commercial WHOIS/RDAP API and treat this repo as a reference implementation only.