generated: '2026-09-05'
method: probed
source: dns + tls probe of zendrive.com and docs.zendrive.com
name: Zendrive domain security posture
description: >-
  Probed by hand rather than by probe-domain-security.py, which reported "no-hosts" because
  this record deliberately wires no Website pointer and no API baseURL — Zendrive has no live
  web host to point at. The DNS-layer posture is still measurable, and it is the most
  interesting finding in this profile: the zendrive.com zone is actively maintained even
  though nothing is served from it. A Google Trust Services certificate covering zendrive.com
  and *.zendrive.com was issued on 2026-08-26 (Cloudflare Universal SSL), DMARC is at
  p=reject with strict alignment and a live reporting mailbox, and CAA is a long, curated
  issuer allowlist with an iodef security contact. Someone is still holding and defending this
  domain; they have simply removed every A record.
hosts:
- host: zendrive.com
  https:
    reachable: false
    note: No A/AAAA record. Connection cannot be established, so TLS and HSTS are unmeasurable at this host.
  dns:
    a_records: []
    nameservers:
    - melany.ns.cloudflare.com
    - thaddeus.ns.cloudflare.com
    mx:
    - aspmx.l.google.com (10)
    - alt1.aspmx.l.google.com (20)
    - alt2.aspmx.l.google.com (20)
    - aspmx2.googlemail.com (30)
    - aspmx3.googlemail.com (30)
    mx_note: Google Workspace MX records are still published, so mail may still route.
    dnssec:
      dnskey: false
      ds: false
      enabled: false
    caa:
      present: true
      issue:
      - letsencrypt.org
      - 'pki.goog; cansignhttpexchanges=yes'
      - ssl.com
      - amazon.com
      - comodoca.com
      - 'digicert.com; cansignhttpexchanges=yes'
      issuewild:
      - comodoca.com
      - 'digicert.com; cansignhttpexchanges=yes'
      - letsencrypt.org
      - 'pki.goog; cansignhttpexchanges=yes'
      - ssl.com
      iodef: mailto:security@zendrive.com
      note: >-
        The iodef address is a CAA certificate-violation reporting contact (RFC 8659), NOT a
        vulnerability disclosure program. It is recorded as a security contact of record and
        nothing more; no Security or VulnerabilityDisclosure pointer is emitted from it.
    spf:
      present: false
      note: No TXT records at all on the apex, so no SPF policy is published.
    dmarc:
      present: true
      record: 'v=DMARC1; p=reject; rua=mailto:sec-ops@zendrive.com; pct=100; sp=reject; adkim=s; aspf=s'
      policy: reject
      subdomain_policy: reject
      pct: 100
      alignment: strict (adkim=s, aspf=s)
      rua: mailto:sec-ops@zendrive.com
- host: docs.zendrive.com
  https:
    reachable: true
    status: 403
    note: >-
      Answers, but only with Cloudflare's dangling-CNAME error ("error code: 1014", 17 bytes,
      text/plain). No HSTS header is returned on that error response.
    hsts: false
  tls:
    certificate_subject: CN=zendrive.com
    certificate_issuer: 'C=US, O=Google Trust Services, CN=WE1'
    not_before: '2026-08-26'
    not_after: '2026-11-24'
    subject_alt_names:
    - zendrive.com
    - '*.zendrive.com'
    note: >-
      A currently valid certificate, issued well after the company wound down its developer
      program — consistent with Cloudflare Universal SSL renewing automatically for a zone
      that is still on the account.
  dns:
    a_records:
    - 172.67.161.199
    - 104.21.9.243
    provider: Cloudflare
findings:
- Domain is retained and actively certificated, but serves nothing.
- DNSSEC is not enabled.
- DMARC is strong (p=reject, sp=reject, strict alignment); SPF is absent, which is a real gap.
- CAA is present and unusually thorough, with an iodef security contact.
- No HSTS can be observed anywhere, because no host serves a successful response.