About fast.id

FullAnalysisforStandardTechnologies— the official full name of fast.id.

fast.id is a public tool to check the DNS health of a domain: delegation, nameserver consistency, SOA, MX, reverse DNS (PTR), and more. Results are graded A–F with structured findings that reference the relevant RFCs so they can be acted on directly.

How to Use

Check a domain's health
  1. Enter a domain name (e.g. pandi.id) on the Home page.
  2. Tick "Do not publish result" if the domain should not appear in the public list.
  3. Click Check and wait a few seconds.
  4. The result shows the grade, score, check time, and a list of findings. If a result comes from cache, click "Update to latest" to re-run.
Use Dig online

Open the Dig page, enter a domain, pick a record type (A, AAAA, MX, TXT, NS, SOA, SRV, CAA, DS, DNSKEY, …) and a resolver, then run. The response shows rcode, flags (AA/AD/RA…), response time, and every answer section.

What the A–F grade means

The score is computed from findings per category (delegation, consistency, zone, nameserver, addresses, …) with different weights. A CRITICAL finding (e.g. the domain is not registered) forces grade F. The scoring policy is open and versioned (the profile version appears on every result).

Privacy & data removal

We do not store your IP address in raw form (only a hash for abuse prevention). Checked domains appear in the public list unless you choose the "do not publish" option. To request removal from the public list, contact the operator through the official PANDI channels.

Standards & Tools

This tool implements checks based on the following DNS standards (RFCs):

  • RFC 1034 — Domain names: concepts and facilities
  • RFC 1035 — Domain names: implementation and specification
  • RFC 1912 — Common DNS operational and configuration errors
  • RFC 2181 — Clarifications to the DNS specification
  • RFC 2182 — Selection and operation of secondary DNS servers
  • RFC 2308 — Negative caching of DNS queries (DNS NCACHE)
  • RFC 3901 — DNS IPv6 transport operational guidelines
  • RFC 4033 — DNS Security Introduction and Requirements
  • RFC 4034 — Resource Records for the DNS Security Extensions
  • RFC 4035 — Protocol Modifications for the DNS Security Extensions
  • RFC 6891 — Extension Mechanisms for DNS (EDNS(0))
  • RFC 8624 — Algorithm Implementation Requirements for DNSSEC

Techniques and protocols used to perform the checks:

  • Delegation trace from the root zone (NS/glue at each level)
  • Cross-nameserver consistency (SOA serial/MNAME, NS set)
  • DNSSEC chain validation: DS → DNSKEY → RRSIG
  • Global propagation across public resolvers (UDP/TCP, EDNS)
  • Direct DNS queries (dig) with DNSSEC (DO) and CD toggles
  • IP-to-ASN mapping and lightweight anycast detection

The Website Check (security headers, TLS, cookies) follows these standards — note that CSP, Referrer-Policy and Permissions-Policy are W3C specifications and X-Content-Type-Options lives in the WHATWG Fetch standard, not RFCs:

  • RFC 9110 — HTTP Semantics (HTTPS & redirects)
  • RFC 6797 — HTTP Strict Transport Security (HSTS)
  • W3C Content Security Policy Level 3 (CSP, frame-ancestors)
  • WHATWG Fetch — X-Content-Type-Options: nosniff
  • RFC 7034 — HTTP Header Field X-Frame-Options
  • W3C Referrer Policy
  • W3C Permissions Policy
  • RFC 6265 — HTTP State Management (cookie attributes)
  • RFC 8446 — TLS 1.3
  • RFC 9325 (BCP 195) — TLS recommendations (minimum TLS 1.2)
  • RFC 5280 — X.509 certificates & chain validation
  • RFC 9116 — security.txt