Intermittent apex outage and TLS failures on lampscience.com – bad edge IP 99.83.190.102? (Mitigated by forcing 75.2.60.5 only)

Subject

Intermittent apex outage and TLS failures on lampscience.com – bad edge IP 99.83.190.102? (Mitigated by forcing 75.2.60.5 only)

Account / site

  • Domain: lampscience.com (nameservers: dns1-4.p01.nsone.net / Netlify DNS)

  • Site: lampscience.netlify.app (please associate with our account/org)

  • Registrar: Hostinger (DNSSEC disabled at registrar)

Summary

Today (2025-09-08) our apex lampscience.com became intermittently unreachable for users across multiple networks/devices/browsers.
www.lampscience.com still resolved (and 301s to apex), but the apex either wouldn’t resolve or returned TLS handshake errors.

We traced it to one of the two anycast A IPs used for the Netlify apex: 99.83.190.102.
When traffic lands on that IP, TLS handshakes fail (Windows schannel errors).
The other IP 75.2.60.5 works consistently.

Mitigation we applied

  • We removed the NETLIFY record types that were present for both lampscience.com and www.lampscience.com.

  • We set:

    • Apex: A → 75.2.60.5 only (TTL 60)
      (We intentionally did not publish 99.83.190.102 to avoid breakage.)

    • www: CNAME → lampscience.netlify.app

  • After this change, the site has been stable.

Please investigate why the 99.83.190.102 path fails for SNI lampscience.com and advise when it’s safe to re-add it (or the NETLIFY record type) for redundancy.

Timeline (UTC, approximate)

  • 08:00–20:30: Users report “site down”, NXDOMAIN or browser ERR_SSL_PROTOCOL_ERROR.

  • 20:40–22:30: We isolate the issue to 99.83.190.102 (TLS failure); 75.2.60.5 OK.

  • 22:33: Mitigation: apex set to only 75.2.60.5. Service restored and stable.

Evidence / reproduction

We forced each IP with SNI and TLS1.2 (to avoid ALPN/QUIC confusion). On Windows:

# GOOD PATH (always OK)
curl.exe -vkI --http1.1 --tlsv1.2 --resolve "lampscience.com:443:75.2.60.5" https://lampscience.com
# => HTTP/1.1 200 OK
#    Server: Netlify
#    X-Nf-Request-Id: 01K4NQDNDRMV3KPGBZSD7PJWW1 (example)

# BAD PATH (reproducible failure)
curl.exe -vkI --http1.1 --tlsv1.2 --resolve "lampscience.com:443:99.83.190.102" https://lampscience.com
# => schannel: next InitializeSecurityContext failed:
#    SEC_E_INTERNAL_ERROR (0x80090304)
#    (Earlier we also saw SEC_E_ILLEGAL_MESSAGE 0x80090326)

Once we published only 75.2.60.5:

Resolve-DnsName lampscience.com
# lampscience.com  A  75.2.60.5  (TTL 60)

curl.exe -I https://lampscience.com
# HTTP/1.1 200 OK
# Cache-Status: "Netlify Edge"; hit
# X-Nf-Request-Id: 01K4NQGA9JP5GWT6PNE32ZAHP3

Representative response headers (good):

HTTP/1.1 200 OK
Server: Netlify
Etag: "9heivufzc10ll"
Strict-Transport-Security: max-age=31536000
X-Nf-Request-Id: 01K4NQGA9JP5GWT6PNE32ZAHP3

What we need from Netlify

  1. Please check TLS termination / certificate mapping for SNI lampscience.com when traffic is routed to 99.83.190.102.
    It looks like a misconfigured edge/accelerator or a broken cert chain on that path.

  2. Confirm if there’s a known incident on that PoP/edge IP and whether it’s safe to re-add it.

  3. Guidance on whether we should keep using the NETLIFY record type for apex and www, or prefer explicit A (apex) and CNAME (www) records until the issue is resolved.

  4. (Optional) Validate our current apex setup with only 75.2.60.5 (TTL 60) as a temporary workaround.

Current DNS (post-mitigation)

  • lampscience.comA 75.2.60.5 (TTL 60)

  • www.lampscience.comCNAME lampscience.netlify.app

  • Mail/TXT records unchanged.

Impact: practically no sessions for the day (analytics), users unable to access apex, while www kept resolving.

Thanks in advance. Happy to provide more X-Nf-Request-Id samples, packet captures, or to run tests you suggest.

@dhmerino It appears you’ve been misled by an “AI”.

What you have done is already correct, simply remove 99.83.190.102.

If you search the forum you will see many threads addressing this.

See:

The 99.83.190.102 address is never mentioned in the Netlify documentation.

Netlify’s own “AI” says: