<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: DNS cache poisoning</title>
	<atom:link href="http://angelsofsecurity.com/blog/2008/07/25/dns-cache-poisoning/feed/" rel="self" type="application/rss+xml" />
	<link>http://angelsofsecurity.com/blog/2008/07/25/dns-cache-poisoning/</link>
	<description>Musings of an infosec renegade</description>
	<lastBuildDate>Tue, 19 Jul 2011 19:43:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: admin</title>
		<link>http://angelsofsecurity.com/blog/2008/07/25/dns-cache-poisoning/comment-page-1/#comment-896</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Thu, 28 Aug 2008 19:43:47 +0000</pubDate>
		<guid isPermaLink="false">http://angelsofsecurity.com/blog/2008/07/25/dns-cache-poisoning/#comment-896</guid>
		<description>DNS is one of the older protocols around, and it is somewhat fatally flawed (the first response wins is just not a good idea). I agree that it will probably need an overhaul eventually. 

As for turning off recursive queries, most DNS requests and responses should generate IP packets that aren&#039;t much more than 100 bytes. Even if you throw on a little more space for the lower level headers (Ethernet, 802.11, or whatever you&#039;re using), and it&#039;s still not very much traffic. Yes there will be a slight delay as the functionality is being moved from the (theoretically faster) DNS server to the end-user, but it will most likely be measured in nanoseconds, if that.</description>
		<content:encoded><![CDATA[<p>DNS is one of the older protocols around, and it is somewhat fatally flawed (the first response wins is just not a good idea). I agree that it will probably need an overhaul eventually. </p>
<p>As for turning off recursive queries, most DNS requests and responses should generate IP packets that aren&#8217;t much more than 100 bytes. Even if you throw on a little more space for the lower level headers (Ethernet, 802.11, or whatever you&#8217;re using), and it&#8217;s still not very much traffic. Yes there will be a slight delay as the functionality is being moved from the (theoretically faster) DNS server to the end-user, but it will most likely be measured in nanoseconds, if that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt W.</title>
		<link>http://angelsofsecurity.com/blog/2008/07/25/dns-cache-poisoning/comment-page-1/#comment-891</link>
		<dc:creator>Matt W.</dc:creator>
		<pubDate>Thu, 28 Aug 2008 03:16:14 +0000</pubDate>
		<guid isPermaLink="false">http://angelsofsecurity.com/blog/2008/07/25/dns-cache-poisoning/#comment-891</guid>
		<description>While turning off recursive queries within an organization (really, their name servers) may resolve a piece of the issue - this flaw exists in the foundations of DNS (your query ID for a lookup is effectively your password and it&#039;s a race to respond with the proper query ID... between the proper authoritative name server and the attacker &quot;name&quot; server).  Plus, how will you disable recursive queries for ISP name servers (Comcast, Verizon, etc.) - I would suppose this would require the client to perform each lookup (as in, everyones PC) - since the ISP name server wouldn&#039;t be doing the heavy lifting.  With home user&#039;s performing all the lookups directly, network utilization would increase by a non-trivial amount due to the additional DNS traffic overhead (at least, I would think so... otherwise, why have recursion and caching in the first place).  I think the patches solve this issue in the near term, in the long run DNS probably needs an overhaul (much like IPv4 did), but judging by the adoption rate of IPv6, I wouldn&#039;t hold my breath.  Now get ready for this BGP issue to take off like wild fire...</description>
		<content:encoded><![CDATA[<p>While turning off recursive queries within an organization (really, their name servers) may resolve a piece of the issue &#8211; this flaw exists in the foundations of DNS (your query ID for a lookup is effectively your password and it&#8217;s a race to respond with the proper query ID&#8230; between the proper authoritative name server and the attacker &#8220;name&#8221; server).  Plus, how will you disable recursive queries for ISP name servers (Comcast, Verizon, etc.) &#8211; I would suppose this would require the client to perform each lookup (as in, everyones PC) &#8211; since the ISP name server wouldn&#8217;t be doing the heavy lifting.  With home user&#8217;s performing all the lookups directly, network utilization would increase by a non-trivial amount due to the additional DNS traffic overhead (at least, I would think so&#8230; otherwise, why have recursion and caching in the first place).  I think the patches solve this issue in the near term, in the long run DNS probably needs an overhaul (much like IPv4 did), but judging by the adoption rate of IPv6, I wouldn&#8217;t hold my breath.  Now get ready for this BGP issue to take off like wild fire&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

