<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:admin="http://webns.net/mvcb/"
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:content="http://purl.org/rss/1.0/modules/content/">

	<channel>

	<title>&#45; CircleID</title>
	<link>https://www.circleid.com/blogs/</link>
	<description>Postings from  on CircleID</description>
	<dc:language>en</dc:language>
	<dc:rights>Copyright 2026, unless where otherwise noted.</dc:rights>
	<dc:date>2026-04-06T20:04:00+00:00</dc:date>

	
	<item>
		<title> Getting On Board With DNSSEC - A Personal Recount (Featured Blog)</title>
		<guid isPermaLink="true">https://circleid.com/posts20120423_getting_on_board_with_dnssec_a_personal_recount</guid>
		<link>https://circleid.com/posts20120423_getting_on_board_with_dnssec_a_personal_recount</link>
		<description><![CDATA[I first became familiar with DNSSEC around 2002 when it was a feature of the Bind9 server, which I was using to setup a new authoritative DNS platform for customers of the ISP I was working for. I looked at it briefly, decided it was too complex and not worth investigating. A couple of years later a domain of a customer got poisoned in another ISPs network. And while the DNS service we provided was working properly, the customers impression was we hadn't protected them. <a href="https://circleid.com/posts20120423_getting_on_board_with_dnssec_a_personal_recount">More...</a>]]></description>
		<dc:date>2026-04-06T13:04:00-07:00</dc:date>
	</item>
	

	</channel>
</rss>