netintel

Any record type over DNS-over-HTTPS, with TTLs, RCODE, the authoritative flag, DNSSEC validation status from the AD bit, and per-type timing. Every answer is cross-checked against a second independently-operated resolver and any disagreement is reported with an interpretation — a genuinely useful signal for stale caches, split-horizon DNS and interception.

• 12 record types per call: A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV, PTR, DNSKEY, DS, HTTPS, SVCB, TLSA and more
• CAA and HTTPS/SVCB decoded from the wire format into structured fields, not returned as raw hex
• TXT strings concatenated per RFC 1035 instead of handed back with embedded quotes
• DNSSEC reported as secure / insecure / bogus, including the resolver's Extended DNS Errors

curl -s -X POST https://netintel.example/dns \
  -H 'content-type: application/json' \
  -d '{"name":"cloudflare.com","types":["A","AAAA","MX","CAA"],"dnssec":true}'

{
  "name": "cloudflare.com",
  "records": {
    "A": {
      "status": "NOERROR",
      "authenticatedData": true,
      "answers": [{ "type": "A", "ttl": 300, "data": "104.16.132.229" }],
      "ms": 41,
      "crossCheck": { "resolver": "google", "agrees": true, "ms": 38 }
    },
    "CAA": {
      "answers": [{ "type": "CAA", "data": "0 issue \"letsencrypt.org\"",
        "parsed": { "flags": 0, "tag": "issue", "value": "letsencrypt.org" } }]
    }
  },
  "dnssec": { "validation": "secure", "authenticatedData": true },
  "disagreements": [],
  "warnings": []
}

A full deliverability audit of one address without sending anything to it. Real RFC 5322 parsing, MX reachability, an SPF DNS-lookup count that actually expands every include, DMARC with organizational-domain fallback, DKIM selector probing with key sizes, and disposable/role/free-provider classification — ending in a 0–100 score whose every point is explained.

• RFC 5322 §3.4.1 addr-spec parser, not a regex: quoted local parts, quoted-pairs, domain literals, IDN → punycode
• SPF includes expanded recursively to count the real DNS-lookup total against the hard limit of 10 (RFC 7208 §4.6.4)
• DMARC falls back to the organizational domain per RFC 7489 §6.6.3 and reports which policy actually applies
• DKIM keys decoded from the DER in p= to report algorithm and bit length, so weak 512/1024-bit keys are caught
• 704 disposable domains and 154 free-provider domains embedded — no third-party API call
• Catch-all is reported as not determinable with a reasoned likelihood, because proving it needs an SMTP probe

curl -s -X POST https://netintel.example/email \
  -H 'content-type: application/json' \
  -d '{"email":"billing@paypal.com"}'

{
  "score": 91, "grade": "A", "verdict": "high",
  "syntax": { "valid": true, "domain": "paypal.com" },
  "mx": { "present": true, "count": 6, "allResolve": true,
          "primaryExchange": "mx1.paypal.com", "provider": "Proofpoint" },
  "spf": { "present": true, "allQualifier": "-", "allMeaning": "fail (hard, recommended)",
           "dnsLookups": { "totalLookups": 9, "limit": 10, "exceedsLimit": false, "exact": true } },
  "dmarc": { "present": true, "policy": "reject", "percent": 100,
             "spfAlignment": "strict", "strength": "strong" },
  "dkim": { "foundCount": 1, "found": [{ "selector": "default", "keySize": 2048 }] },
  "classification": { "disposable": false, "roleAccount": true, "freeProvider": false },
  "breakdown": [
    { "signal": "dmarc-reject", "delta": 2, "reason": "DMARC p=reject — the strongest setting." },
    { "signal": "role-account", "delta": -10, "reason": "\"billing\" is a role address…" }
  ]
}

Certificate and HTTPS posture, graded A–F. netintel performs its own TLS 1.2 handshake over a raw TCP socket and parses the X.509 DER itself — which is why it can show you an expired or self-signed certificate that a normal HTTPS client refuses to connect to at all.

• Works on expired.badssl.com and self-signed.badssl.com: a Worker's fetch() cannot, because it validates first and hangs up
• Subject, issuer, all SANs, validity window, days until expiry, serial, signature algorithm, key size, SHA-256 fingerprint, DV/OV/EV level, OCSP and CRL URLs, embedded SCT count
• RFC 6125 wildcard-aware hostname matching, and the full chain the server actually presented
• TLS 1.0–1.3 support probed with separate real handshakes, plus cipher suite with forward-secrecy and AEAD flags and the ALPN protocol
• Every security header graded with per-header reasons: HSTS, CSP with real weakness analysis, XFO, nosniff, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP
• Says plainly what it cannot do — no root store, so no trust-path or revocation claim — instead of inventing the fields

curl -s -X POST https://netintel.example/tls \
  -H 'content-type: application/json' \
  -d '{"host":"expired.badssl.com"}'

{
  "grade": "F", "score": 33,
  "certificate": {
    "subject": { "commonName": "*.badssl.com" },
    "issuer": { "commonName": "COMODO RSA Domain Validation Secure Server CA" },
    "validity": { "notAfter": "2015-04-12T23:59:59.000Z",
                  "daysUntilExpiry": -4128, "expired": true },
    "serialNumber": "4E5BC1FE0D26F1E38A4B1E4F1F4B24F1",
    "signatureAlgorithm": { "name": "sha256WithRSAEncryption", "weak": false },
    "publicKey": { "algorithm": "RSA", "keySize": 2048 },
    "hostnameMatch": { "matches": true, "viaWildcard": true }
  },
  "certificateIssues": ["Certificate EXPIRED 4128 day(s) ago…"],
  "handshake": { "negotiatedVersion": "TLSv1.2",
                 "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256", "forwardSecrecy": true },
  "verification": { "trustPathVerified": false, "revocationChecked": false, "note": "…" }
}

An IPv4/IPv6 address, a CIDR block or a hostname in; network classification, reverse DNS, ASN and blocklist status out. Private addresses are welcome input and fully described — netintel just never opens a connection to anything you name here, so it cannot be turned into a network scanner.

• Network class with the governing RFC: public, private, loopback, link-local, CGNAT, reserved, documentation, benchmarking, multicast, broadcast — and cloud-metadata addresses flagged
• Reverse DNS and forward-confirmed rDNS, the check mail servers actually apply
• ASN, AS name, organisation, announced prefix, RIR and country from Team Cymru, plus upstream peer ASNs
• 6 DNS blocklists queried concurrently — and the 3 that refuse a Worker's resolver are reported as unknown, never silently as clean
• CIDR input returns network/first/last address, total addresses and usable host count with exact big-integer maths

curl -s -X POST https://netintel.example/ip \
  -H 'content-type: application/json' \
  -d '{"ip":"8.8.8.8"}'

{
  "ip": "8.8.8.8", "version": "IPv4",
  "network": { "class": "public", "isPublic": true,
               "description": "globally routable public unicast" },
  "reverseDns": { "present": true, "primary": "dns.google" },
  "forwardConfirmedReverseDns": { "confirmed": true,
    "note": "Forward-confirmed: the PTR hostname resolves back to this address." },
  "asn": { "asn": 15169, "asName": "GOOGLE", "organization": "Google LLC, US",
           "prefix": "8.8.8.0/24", "countryCode": "US", "registry": "ARIN",
           "upstreamPeers": ["AS2914", "AS3257", "AS6461", "AS6939"] },
  "blocklists": { "checked": 6, "listedCount": 0, "clean": true,
    "unavailable": [{ "zone": "zen.spamhaus.org",
      "reason": "Spamhaus blocks queries arriving via public/open resolvers…" }] }
}

One record, up to eleven public resolvers, all queried at the same time. Tells you each resolver's answer, TTL, latency and RCODE, groups them into distinct answer sets, and says whether the record has actually propagated — or whether one operator is filtering it.

• Resolver ids: cloudflare, google, opendns, adguard, adguardFiltered, dnssb, nextdns, controld, cleanbrowsing, dnspod, alidns
• Default set spans eight operators and two jurisdictions, including Chinese resolvers — so regional divergence shows up
• A dead resolver is excluded from the consistency maths and reported in warnings[], never counted as a disagreement
• Distinguishes 'mid-propagation' (some resolvers still NXDOMAIN) from 'genuinely different data' and says which it is
• Resolvers unreachable from a Worker are listed with the technical reason rather than quietly dropped

curl -s -X POST https://netintel.example/propagation \
  -H 'content-type: application/json' \
  -d '{"name":"example.com","type":"A"}'

{
  "name": "example.com", "type": "A",
  "consistent": true, "agreementRatio": 1,
  "resolversQueried": 8, "resolversAnswered": 8, "distinctAnswerSets": 1,
  "majorityAnswer": { "answers": ["104.20.23.154", "172.66.147.243"], "resolverCount": 8 },
  "resolvers": [
    { "id": "cloudflare", "operator": "Cloudflare", "ok": true, "ms": 38,
      "answers": ["104.20.23.154", "172.66.147.243"], "agreesWithMajority": true },
    { "id": "dnspod", "operator": "Tencent", "ok": true, "ms": 210,
      "answers": ["104.20.23.154", "172.66.147.243"], "agreesWithMajority": true }
  ],
  "interpretation": "All 8 responding resolvers returned identical data…"
}