Web Tools

From Actionable Screenshots to Resolution and Management-Ready Post-Mortem Reviews
Tools and research for digital trust, internet governance, and authoritative data structures.

  1. Sharing Cloud & Hosting Knowledge (since November 3, 2018) — webhostingtech.nl
  2. Domain Lookup, WHOIS & DNSSEC Analysis (since August 15, 2021) — rdap.hostingtool.nl/modeling_domain
  3. Testing Email Receipt from a False Sender (PHP/SMTP, since June 25, 2022) — not publicly available
  4. Hosting Control (PHP/JSON, since November 30, 2024) — control.hostingtool.org
  5. Homepage Route Overview (PHP/Python, since February 26, 2025) — www.workingornot.org
  6. Security Header Overview (PHP/Python, since March 18, 2025) — securityheaders.hostingtool.org
  7. Web Hosting Lookup (PHP/Python/JSON, since May 6, 2025) — lookup.hostingtool.org
  8. Registry Table Definition Design (PostgreSQL, since May 16, 2025) — github.com/janwillemstegink/rdap.hostingtool.nl
  9. Top-Level Domain Lookup (PHP/JSON, since June 21, 2025) — rdap.hostingtool.nl/modeling_tld
  10. Inbound Mail Flow Analysis (PHP/Python, since March 2, 2026) — analyzemx.hostingtool.org
  11. Post-Quantum Cryptography for TLS (PHP/Python, since March 2, 2026) — analyzetls.hostingtool.org
  12. State of EU Top-Level Domains (since June 5, 2026) — analyzetlds.hostingtool.org
  13. Preparing Trade Registers for Modern PKI (since June 11, 2026) — analyzesubject.hostingtool.org
  14. Making RDAP Self-Explanatory (since June 18, 2026) — janwillemstegink.nl/self-explanatory-rdap
  15. Browser and Mail Client Readiness (since July 6, 2026) — clientreadiness.hostingtool.org

The Dutch website internet.nl (en.internet.nl), a Django-based application, provides valuable action points for responsible parties based on automated test results. However, several structural and conceptual aspects deserve closer attention:

  1. Score weighting limitations — Because internet.nl covers a broad range of test topics, a serious issue may result in only a small score deduction within an otherwise high overall percentage. In practice, this can obscure real problems behind near-perfect scores.
  2. Inaccessible services can still score well — Web or mail services that are closed or unreachable can still achieve scores of approximately 61% (web) or 70% (email) based solely on DNS configuration, despite the service itself being unusable.
  3. Time-outs should count as hard failures — Time-outs are often treated as temporary conditions. From a user perspective, however, a time-out means the service is unreachable. In that sense, a time-out is as critical as missing HTTPS or broken redirects and should be handled as a hard failure.
  4. Domain holder name checks are complex — Verifying domain registration holder names depends heavily on country-specific rules. While most technical components exist, meaningful progress also requires regulatory and political alignment, not just technical solutions.
  5. “Hall of Fame” may need rethinking — The current Hall of Fame concept works well today, but may require more future-proof criteria, such as ownership or control validation through email-based identification.
  6. Separate IPv4/IPv6 and www results — IPv4, IPv6, www, and non-www configurations are frequently not identical. Presenting results in four separate columns makes these differences immediately visible and easier to interpret.
  7. Email scores can be misleading — Email delivery and reception depend on many external factors. A 100% email score may suggest completeness, while real-world behavior can still differ significantly.
  8. Public display of (sub)domains — Publishing 100% test results for (sub)domains can lead to unwanted or unsolicited contact. For this reason, public display of such results should be carefully reconsidered.
  9. Create a second table and processing structure suitable for the interface —
    • result_id – database technical id
    • domain – identifier (sub)domain without a leading “www.”
    • www – identifier without_www / with_www
    • protocol – identifier v4 / v6 / v4v6
    • requested_at – for request identification
    • started_at – retrieval time initialization
    • finished_at – retrieval time calculation
    • action_points – including urgency descriptors
    • … (existing fields)
  10. Optional extra run — The numerous TLS checks for incoming mail servers are time-consuming. In addition, SMTP TLS scanning involves many parallel TLS handshakes. While OpenSSL itself has no hard limit on concurrent connections, the practical limits of SSLyze, system resources, and SMTP server rate limiting require careful engineering. This remains the reason to test email separately. The modernization is almost ready to deploy.

Note: These observations focus on structural and conceptual aspects rather than engineering details.