Blog
Longer answers to the questions a report cannot fit in a panel. What a record can settle, what it cannot, and where a signal that looks decisive is worth less than it appears.
No news and no announcements. Each piece is about a decision somebody is in the middle of, and it names the registries, feeds and prefixes involved rather than talking around them.
-
Vetting an IPv4 lessee: reading a tenant's ASN when no registry will check it for you
A lease does not rent out addresses on their own. It attaches your prefix to somebody else's autonomous system, and the lists that judge at that granularity reach everything inside it. What a network report proves about a tenant, the column on it that is a recent window rather than a history, and why nothing behind you checks any of it.
-
An IPv6 address in your logs: which block do you actually write down?
One address, and a boundary drawn around it in four places on one page: the block you typed, the one that is announced, the one that is registered and the layer above. Which width belongs to which act, and why the fifth boundary, the one that decides what a rule catches, is on no panel at all.
-
A report lands in abuse@: deciding whether the address is yours, whether the complaint is actionable and what you answer
One complaint, one source address and a claimed time. The two reads that settle whether the space is yours and what it is already known for, the four answers that follow from them and the boundary on what the reply can safely say.
-
Buying a block from a company the record does not name: what a public report can corroborate and what only the registry settles
The offer sheet names one entity and the registry names another, which is the ordinary condition of this market rather than a finding. The four free reads that narrow the distance between two names, and the branch where the deal stops being a negotiation and becomes the registry's.
-
Asked to allowlist an IP range: whether the requester holds it, who else is inside it and the width you can defend
A ticket names a range and asks for a bypass. A bystander inside a deny rule is inconvenienced; a stranger inside an allow rule is in. The holder, the announcement and the sample read with the risk inverted, and the three decisions each read sets up.
-
An IP you do not recognise in a DMARC report: vendor, forwarder or impersonator, narrowed by the holder and the alignment pair
An aggregate report hands you an address with nothing attached: no header, no bounce, no name. Its holder, its block and the network announcing it narrow the field, the SPF and DKIM alignment pair narrows most of the rest, and each answer forces a different action before the next report arrives.
-
Rehoming a prefix: moving your space to a new origin AS without a gap or a hijack alarm
The holder stays, the announcer changes. The ROA for the new origin before its first announcement, the route object and the paper the upstream checks, a short planned overlap that reads as handover rather than hijack, and the old origin's withdrawal confirmed in the origin history before its ROA goes.
-
Getting one IP address off a blocklist: the removal portals one by one, who is allowed to file, and the ticket you send your provider
The box is stopped and one address has to come off. Each rejection points at a different door: a form, a checker, a clock, or a request only the ISP in charge may make. The portals one by one as their pages read on the day, who each will hear from, the ticket to send your provider, and what a later lookup here can and cannot show.
-
Monitoring your own IP ranges: scheduled lookups through the API, the fields worth diffing between runs, and why a gap is not a zero
Nothing here watches your prefixes for you, and the archive has a dated point for your block only on the days somebody looked. A cron job against the keyless API, one prefix lookup per block, the fields worth diffing against yesterday's file, and what a difference between two runs can and cannot mean.
-
Entire IP range blocklisted: how a listing widens from one address to a /24 or a whole allocation, and who owns the fix
One customer's box started spamming, and now the whole range bounces. The published rules that widen a listing, rung by rung, the owner of the fix at each rung, and the containment that keeps the next incident one address wide.
-
When two ASNs announce the same prefix: hijack, anycast, or handover
A second origin on your prefix is an alarm with more than one explanation, and BGP will not tell you which. The measured shape of hijacks versus scrubbing contracts and handovers, how the overlap reads in a dated origin history, and the paperwork checks that separate them.
-
Preparing an IPv4 block for sale: the cleanup that happens before the listing
A problem the buyer discovers becomes a negotiation; a problem you disclose is just a fact about the block. The eligibility locks per registry, the tenant wind down that will not read as churn, the record sweep, and the reputation pass that takes months.