<?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-30T19:14:00+00:00</dc:date>

	
	<item>
		<title> How to Evaluate Performance of a DNS Resolver (Featured Blog)</title>
		<guid isPermaLink="true">https://circleid.com/posts201120801_how_to_evaluate_performance_of_a_dns_resolver</guid>
		<link>https://circleid.com/posts201120801_how_to_evaluate_performance_of_a_dns_resolver</link>
		<description><![CDATA[Ten years ago everyone evaluating DNS solutions was always concerned about performance. Broadband networks were getting faster, providers were serving more users, and web pages and applications increasingly stressed the DNS. Viruses were a factor too as they could rapidly become the straw that broke the camel's back of a large ISP's DNS servers. The last thing a provider needed was a bottleneck, so DNS resolution speed became more and more visible, and performance was everything. <a href="https://circleid.com/posts201120801_how_to_evaluate_performance_of_a_dns_resolver">More...</a>]]></description>
		<dc:date>2026-04-30T12:14:00-07:00</dc:date>
	</item>
	

	</channel>
</rss>