Member
KnownHost price is good but their network team is basically tickets to nowhere. I had a prefix issue last year, same response. "Contact your RIR."
If you are paying 50+ USD for managed VPS you expect them to at least have a looking glass with RPKI status. They don't.
Member
I run my own validator in Tallinn just to not trust RIR infrastructure. Routinator + RTR to bird. It is not hard, 2GB RAM, done.
The real question: did your traffic actually blackhole or did it go somewhere else? 20 minutes is long enough to sniff. Check your netflow for that window if you have it.
Chur me from before, but also: @lucgone you need to check if your ASN was the one leaking or if someone else originated it. Use RIPEstat or BGP.Tools history. If it was a Russian ASN or something in the "stans" that's a pattern, not random.
Also KnownHost Amsterdam: good latency to NZ, bad RPKI hygiene in my experience mate.
Member
This is not merely a technical failure. The ENISA report on RPKI readiness (2023) explicitly warned about single points of failure in publication infrastructure. RIPE NCC operates under Dutch law; I am examining whether the Telecommunications Act (Telecommunicatiewet) imposes availability requirements.
I will update if my FOIA-equivalent request yields anything. The regulatory angle is slow but it is the only one that produces structural change.
Member
I Have Run The Validation Again From Gdansk. The Manifest Is Now Populated. The Serial Number Has Incremented.
This Is Consistent With A Delayed Publication, Not A Missing Object. The Gap Was Approximately 48 Hours Based On Cache Timestamps I Have Preserved.
I Recommend You Set Up RPKI Monitoring. I Use Nagios With Custom Script Checking Manifest Serial Every 15 Minutes.
I'm in New York and I see this from my office ISP (Spectrum business): your prefix was reachable via two paths during the window, one valid one unknown. The hijack was more-specific, /27 inside your /24, so even with your ROA present, if providers don't reject RPKI-invalid *and* don't do prefix-length filtering, it wins.
Your ROA being /24 didn't help because they announced smaller. This is why max-length matters and why people argue about it.
Ah. I have understand now. My ROA is for /24, they announce /27. So RPKI say "this is not covered" not "this is invalid"? Or it is invalid? I need to make ROA for /24 with max length /24? Then nobody can announce more specific?
I have check BGP.Tools history, it was AS206728. Never see before. Origin in... Netherlands? But RIPE say the ASN belong to someone in Bulgaria? I don't know if this is useful.
Bulgarian-registered ASN, announced from a Dutch hoster probably. Common pattern: cheap ASN + VPS in NL or DE + automated hijack tool. They probe for dormant prefixes and announce more-specifics to catch traffic, usually for certificate transparency logging or BGP hijack research, sometimes worse.
Your /24 with max-length /24 would have made their /27 RPKI-invalid, but only if the receiving AS does strict RPKI validation. Many don't. Still worth doing. Also register your route in IRR with exact prefix, some providers filter on that instead.
File a report with your national CERT. France has CERT-FR. They aggregate these.
I am in Cologne and I work at a hoster (not KnownHost). We do RPKI strict mode since 2022. The pain was real: we dropped 3 legitimate prefixes in the first month because their ROAs were wrong. But now it is automatic.
My advice: move to a provider that does RPKI-ROV. KnownHost does not, they are cheap for a reason. Their Amsterdam is good latency but you are buying transit from 2018.
Member
São Paulo to Amsterdam is 180ms for me, but I would take the latency over this headache. My provider in Miami does not even know what RPKI is, I had to explain three times.
@lucgone at least you have RIPE, LACNIC interface is worse and ARIN charges for everything. Be grateful for small problems.
