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
NETLIFYrecord types that were present for bothlampscience.comandwww.lampscience.com. -
We set:
-
Apex: A →
75.2.60.5only (TTL 60)
(We intentionally did not publish99.83.190.102to 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”,
NXDOMAINor browserERR_SSL_PROTOCOL_ERROR. -
20:40–22:30: We isolate the issue to
99.83.190.102(TLS failure);75.2.60.5OK. -
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
-
Please check TLS termination / certificate mapping for SNI
lampscience.comwhen traffic is routed to99.83.190.102.
It looks like a misconfigured edge/accelerator or a broken cert chain on that path. -
Confirm if there’s a known incident on that PoP/edge IP and whether it’s safe to re-add it.
-
Guidance on whether we should keep using the
NETLIFYrecord type for apex andwww, or prefer explicitA(apex) andCNAME(www) records until the issue is resolved. -
(Optional) Validate our current apex setup with only
75.2.60.5(TTL 60) as a temporary workaround.
Current DNS (post-mitigation)
-
lampscience.com→ A75.2.60.5(TTL 60) -
www.lampscience.com→ CNAMElampscience.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.
