bwscomputerservice.com — Domain, Email & Health Monitor

bwscomputerservice.com

Spelling matters: the domain is bwscomputerservice.com — “service” with the i. The i-less bwscomputerservce.com is a different string that is not registered and does not resolve; don’t point tooling at it.

Verified baseline (captured 2026-07-12 from live recon)

Aspect Value
DNS / hosting Cloudflare (NS maciej/nora.ns.cloudflare.com, A 104.21.64.100 / 172.67.181.21)
Registration paid 10 years
TLS cert Google Trust Services (Cloudflare), auto-renewed; ~90-day validity windows
Email MX ProtonMail (mail.protonmail.ch, mailsec.protonmail.ch)
SPF v=spf1 include:_spf.protonmail.ch ~all
DMARC v=DMARC1; p=quarantine
Site HTTPS 200 via Cloudflare
Security headers HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy all present

Daily health monitor (domain-monitor.sh, added 2026-07-12)

READ-ONLY external probe of the domain — never changes anything, only reports. Because the domain is paid 10 years and the cert auto-renews, this is a “verify the automation is still working” net rather than a calendar reminder. Each run checks, and alerts to Discord only on drift:

  1. Site up — HTTPS returns 2xx/3xx (else “unreachable” / bad status).
  2. Cert health — reads the live cert; alerts if expired or under 21 days left (Cloudflare renews ~30d out, so under 21 means auto-renewal likely stalled).
  3. Email-auth DNS — MX still ProtonMail, SPF still includes _spf.protonmail.ch, DMARC still present. Catches both disappearance and malicious change (e.g. a DNS hijack repointing mail).
  4. Security headers — the four required headers are still being sent; catches a Cloudflare config regression.

Success is silent (so no daily noise); any failure sends one red Discord embed listing every issue found. --always-notify forces a green confirmation for testing.

  • Script: /home/aztechguy/.local/bin/domain-monitor.sh
  • Log: /home/aztechguy/domain-monitor.log
  • Webhook: ~/.config/discord-webhooks/domain.txt (currently seeded with the stocks webhook as a placeholder — create a dedicated domain/infra channel and paste its URL here to segregate)
  • Schedule: daily at 5:40 AM via user crontab (5 min before the morning briefing, which surfaces this log’s last line in its 🌐 Domain section)
  • Manual run: domain-monitor.sh --always-notify

Known failure mode: VPN/network blip = FALSE “records missing” alarm (2026-07-19)

The script’s dig queries go straight to 1.1.1.1 (Cloudflare DNS). If the box’s network is down or mid-VPN-reconnect at 5:40 AM, every query times out and the check misreads “no DNS answer” as “record GONE” — the log fills with:

;; communications error to 1.1.1.1#53: timed out
;; no servers could be reached
SPF record missing or changed (expected '_spf.protonmail.ch'; got: none).
DMARC record missing or changed ...

…and the morning briefing’s 🌐 Domain line shows the tail of that wreckage. The domain is fine — the checker was blind. First observed 2026-07-19 after an overnight VPN blip (the same blip that stalled the 5:45 briefing); the three prior mornings all PASSed, and a manual re-check that same morning resolved instantly with the site at HTTP 200.

How to tell false alarm from real problem: communications error / no servers could be reached in the log = network-side (false alarm). A real record change shows a clean dig answer with the wrong value. To confirm, re-run by hand once the network is up:

dig +short bwscomputerservice.com A          # expect the two Cloudflare IPs
curl -s -o /dev/null -w "%{http_code}\n" https://bwscomputerservice.com   # expect 200
/home/aztechguy/.local/bin/domain-monitor.sh --always-notify              # full re-check

Guard added same day (2026-07-19): the script now runs a network preflight before any checks — it resolves a known-good name first. Outcomes:

  • Box offline (preflight DNS and two independent HTTPS probes all fail) → logs SKIP: network/DNS down -- domain check inconclusive, not alerting and exits 0. No red Discord embed, no false “SPF missing.” The briefing shows the SKIP line.
  • Only 1.1.1.1 blocked but network up → logs a NOTE and falls back to the system resolver, so the real checks still run that morning.
  • Network fine → behaves exactly as before.

All three branches were force-tested on 2026-07-19 (normal PASS; simulated dead probe → NOTE + PASS via system resolver; simulated full outage → SKIP exit 0). Related quirk found while testing: the box’s VPN intercepts all DNS (queries to any resolver IP get answered while the tunnel is up) — so when the tunnel blips, DNS dies completely at once, which is exactly the mode this guard covers.

If you intentionally change providers (e.g. move email off ProtonMail, or adjust headers), update the EXPECT_MX / EXPECT_SPF / EXPECT_DMARC / REQUIRED_HEADERS baseline values at the top of the script, or it will (correctly) alert that the live config no longer matches the recorded baseline.