<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>lgkm.org field notes: Network and segmentation</title>
  <subtitle>The state of modern IT and security</subtitle>
  <link href="https://lgkm.org/topics/network/feed.xml" rel="self"/>
  <link href="https://lgkm.org/topics/network/"/>
  <id>https://lgkm.org/topics/network/</id>
  <updated>2026-10-27T00:00:00Z</updated>
  <author><name>Simon Bennett</name></author>
  <entry>
    <title>DNSSEC: why it exists, who uses it and what it has broken</title>
    <link href="https://lgkm.org/notes/dnssec-why-who-and-what-broke/"/>
    <id>https://lgkm.org/notes/dnssec-why-who-and-what-broke/</id>
    <updated>2026-10-27T00:00:00Z</updated>
    <category term="network"/>
    <summary>DNSSEC lets a resolver check that a DNS answer really came from the owner of the name. It was built to stop forged answers, it is switched on far more by resolvers than by domain owners, and when it fails it takes whole domains, and once a whole country's zone, offline.</summary>
  </entry>
  <entry>
    <title>Email was built to trust everyone: TLS, SPF, DKIM and DMARC, and what each one breaks</title>
    <link href="https://lgkm.org/notes/email-security-patches/"/>
    <id>https://lgkm.org/notes/email-security-patches/</id>
    <updated>2026-10-27T00:00:00Z</updated>
    <category term="network"/>
    <summary>Email still runs on a 1980s protocol that lets any server claim to be anyone and send in the clear. Opportunistic TLS, SPF, DKIM and DMARC were added on top, one problem at a time. Each fixes something real, each breaks something else, and none of them stops a lookalike domain.</summary>
  </entry>
  <entry>
    <title>IP address or identity: what should actually let someone in?</title>
    <link href="https://lgkm.org/notes/ip-address-or-identity/"/>
    <id>https://lgkm.org/notes/ip-address-or-identity/</id>
    <updated>2026-10-26T00:00:00Z</updated>
    <category term="network"/>
    <summary>An IP allowlist says where a request comes from. Identity says who or what is asking. Both still have a place, on the internet and inside the network, but each only works when certain things are in place, and each fails in its own way.</summary>
  </entry>
  <entry>
    <title>Blast radius belongs in the board pack</title>
    <link href="https://lgkm.org/notes/blast-radius-board-pack/"/>
    <id>https://lgkm.org/notes/blast-radius-board-pack/</id>
    <updated>2026-10-22T00:00:00Z</updated>
    <category term="network"/>
    <summary>Boards are told how many vulnerabilities were patched and how many people did the training. The question they actually need answered is how far one intruder could get. Blast radius can be measured, tested and reported in a line, and it belongs in the board pack.</summary>
  </entry>
  <entry>
    <title>Labels before rules: why microsegmentation projects stall</title>
    <link href="https://lgkm.org/notes/labels-before-rules/"/>
    <id>https://lgkm.org/notes/labels-before-rules/</id>
    <updated>2026-10-19T00:00:00Z</updated>
    <category term="network"/>
    <summary>Microsegmentation projects stall because nobody can say what each workload is. Label the estate first, by application, environment and role, and the rules almost write themselves.</summary>
  </entry>
</feed>
