The entire technology world has, for decades, treated the IP address as a shorthand host identifier. This is clearly not the way IP was designed, but what are our other choices? In this episode of the Hedge, Scott Robohn joins Russ And Tom to discuss a recent paper arguing cryptographic keys should be the primary host identifier, and another article on the centrality of DNS to the Internet.
My CCDE Journey This post is the third in a series about the CCDE certification journey. The first post covers exam-day tips and tricks for the practical. The second post…
The post My CCDE Journey — Background, Preparation, Study Strategy, Courses, and Practice Exams appeared first on JTnetwork.io.
RPKI was supposed to be the fix for one of BGP’s oldest problems: nothing stops a network from announcing someone else’s IP addresses, on purpose or by accident. More than a decade into the project, adoption numbers finally look good, and yet RPKI invalid routes haven’t gone away. Route hijacks still happen, leaks still happen, and (this is the part that surprised me when I dug into the research) the tools built to catch all this still cry wolf constantly.
Here’s the short version: RPKI did its job. It just wasn’t as big a job as everyone hoped, and thousands of invalid routes a day are proof that the story doesn’t end at “deployed.”
A Route Origin Authorization (ROA) is a cryptographic statement from an IP address holder saying, “this AS, and only this AS, is allowed to originate this prefix.” Routers that check incoming announcements against ROAs sort them into three buckets (Valid, Invalid, or Not Found) through a process called Route Origin Validation (ROV).
That’s the whole mechanism. Simple in concept, it took the industry years to actually roll it out at scale. It’s happened now: a majority of Continue reading
In short: At GTC 2026, NVIDIA released OpenShell, an open source runtime that sandboxes autonomous AI agents with kernel-level policy: what files they can touch, what processes they can spawn, where their traffic can go. It is a serious piece of engineering and it validates something we have argued all year: agent security belongs in the environment, not in the prompt. But agent identity, agent-to-agent governance, and cross-sandbox communication all sit outside its scope today. This post covers what OpenShell does, where it stops by design, and three integration patterns that close the gap with Tigera Lynx.
Most attempts to control AI agents work at the model layer (alignment, system prompts) or the application layer (guardrail libraries, output filters). Both share a flaw: the thing being secured is also the thing doing the securing. A sufficiently confused or sufficiently compromised agent can talk its way past its own instructions.
OpenShell takes a different position, and it is the right one. Put the controls in the environment, where the agent cannot negotiate with them. An agent inside an OpenShell sandbox cannot leak a credential it never received, and cannot call an endpoint the kernel refuses to route.
If that argument sounds Continue reading
Last December, I wrote a pretty ranty post explaining how Ansible release 12 broke (some?) network device configuration playbooks. The inevitable anonymous troll (why are they always anonymous?) couldn’t resist asking whether I opened an issue on GitHub. I didn’t (more about that later), but when the solution to that rant was “we’re deprecating using templates in src” parameter, I opened an issue arguing why that’s not a good idea.
On July 3, 2026, the Albanian communications authority (AKEP), the operator of the .al country-code top-level domain (TLD) of Albania, attempted a DNSSEC key rollover. Something went wrong, resulting in DNSSEC validation failures. Any validating DNS resolver receiving these signatures was required by the DNSSEC specification to reject them and return errors to clients. That includes 1.1.1.1, the public DNS resolver operated by Cloudflare.
The .al TLD is the online home of Albanian government services, banks, and media; it ranks #191 on Cloudflare Radar's TLD ranking. Anyone trying to visit those sites, using a validating resolver, found them unreachable during the incident. The failure had the potential to affect every .al domain, regardless of where it was hosted or which authoritative nameservers served it.
Just two months earlier, a similar incident struck .de, the TLD of Germany. As we described in our blog post on the incident, our response was to install a Negative Trust Anchor (NTA) for .de, temporarily suspending DNSSEC validation in 1.1.1.1 to keep domains reachable while the registry resolved the issue. We did the same for .al.
NTAs restore resolution, but silently. A client receiving a Continue reading
Tony Mattke published a blog post I wish I’d read 10 years ago. His Oh-Shit Toolkit includes several tools one can use after messing up Git branches or commit history.
Definitely worth reading, even if you’ve been working with Git for ages.
In this post, we will look at Source Specific Multicast, or SSM. This is a different approach to multicast that simplifies the overall architecture by removing the need for an RP entirely.
In the previous posts, we covered PIM Sparse Mode, where receivers join a shared tree rooted at the RP and then optionally switch to the shortest path tree toward the source. We also looked at Auto-RP and BSR, which solve the problem of dynamically distributing RP information to all routers. SSM takes a different approach by eliminating the shared tree concept altogether.
Before we look at SSM, let's briefly talk about Any Source Multicast, or ASM. This is the traditional multicast model we have been using throughout this series.
With ASM, receivers join a multicast group without specifying a source. They simply say 'I want traffic for group 239.1.1.1' and the network figures out how to deliver traffic from any source sending to that group. This is why it is called Any Source Multicast.