<?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: What Dan&#8217;s DNS Checker Doesn&#8217;t Do</title>
	<atom:link href="http://www.veracode.com/blog/2008/07/what-dans-dns-checker-doesnt-do/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.veracode.com/blog/2008/07/what-dans-dns-checker-doesnt-do/</link>
	<description>Application security testing, analysis, and metrics</description>
	<lastBuildDate>Tue, 15 May 2012 22:16:53 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Jesse Cantu</title>
		<link>http://www.veracode.com/blog/2008/07/what-dans-dns-checker-doesnt-do/comment-page-1/#comment-1959</link>
		<dc:creator>Jesse Cantu</dc:creator>
		<pubDate>Sun, 20 Jul 2008 16:51:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.veracode.com/blog/?p=120#comment-1959</guid>
		<description>@Chris Eng
This is a pretty interesting take on it. I hadn&#039;t even thought about it before, but you&#039;re right... regarding the NAT issue, that has huge implications across the Internet and deep within the consumer-base itself.

Incidentally, theReformed was running a poll on Dan&#039;s find posted the other day, so far Dan seems to be coming out on top with the people http://thereformed.org/2008/07/19/poll-dan-kaminskys-dns-poisoning-bug/ .

@Dan Kaminsky
How does this not effect DJBDNS? I know DJB has campaigned for years against BIND&#039;s flawed existence, why hasn&#039;t his product received wider adoption?</description>
		<content:encoded><![CDATA[<p>@Chris Eng<br />
This is a pretty interesting take on it. I hadn&#8217;t even thought about it before, but you&#8217;re right&#8230; regarding the NAT issue, that has huge implications across the Internet and deep within the consumer-base itself.</p>
<p>Incidentally, theReformed was running a poll on Dan&#8217;s find posted the other day, so far Dan seems to be coming out on top with the people <a href="http://thereformed.org/2008/07/19/poll-dan-kaminskys-dns-poisoning-bug/" rel="nofollow">http://thereformed.org/2008/07/19/poll-dan-kaminskys-dns-poisoning-bug/</a> .</p>
<p>@Dan Kaminsky<br />
How does this not effect DJBDNS? I know DJB has campaigned for years against BIND&#8217;s flawed existence, why hasn&#8217;t his product received wider adoption?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Kaminsky</title>
		<link>http://www.veracode.com/blog/2008/07/what-dans-dns-checker-doesnt-do/comment-page-1/#comment-1942</link>
		<dc:creator>Dan Kaminsky</dc:creator>
		<pubDate>Sat, 19 Jul 2008 00:18:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.veracode.com/blog/?p=120#comment-1942</guid>
		<description>Information about working around the NAT issue just hit my website.</description>
		<content:encoded><![CDATA[<p>Information about working around the NAT issue just hit my website.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Eng</title>
		<link>http://www.veracode.com/blog/2008/07/what-dans-dns-checker-doesnt-do/comment-page-1/#comment-1923</link>
		<dc:creator>Chris Eng</dc:creator>
		<pubDate>Wed, 16 Jul 2008 01:41:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.veracode.com/blog/?p=120#comment-1923</guid>
		<description>@Hoff:

I&#039;ve been waiting for someone to respond in an official capacity to the question you and Tom Cross raised.

I guess this is the closest thing so far:
http://www.circleid.com/posts/87143_dns_not_a_guessing_game/</description>
		<content:encoded><![CDATA[<p>@Hoff:</p>
<p>I&#8217;ve been waiting for someone to respond in an official capacity to the question you and Tom Cross raised.</p>
<p>I guess this is the closest thing so far:<br />
<a href="http://www.circleid.com/posts/87143_dns_not_a_guessing_game/" rel="nofollow">http://www.circleid.com/posts/87143_dns_not_a_guessing_game/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Christofer Hoff</title>
		<link>http://www.veracode.com/blog/2008/07/what-dans-dns-checker-doesnt-do/comment-page-1/#comment-1593</link>
		<dc:creator>Christofer Hoff</dc:creator>
		<pubDate>Fri, 11 Jul 2008 02:24:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.veracode.com/blog/?p=120#comment-1593</guid>
		<description>I&#039;m also interested in the comments highlighted by Tom Cross from IBM/ISS X-force reiterating a comment sent to FD regarding DNS and NAT devices.  You can find Tom&#039;s post here: http://blogs.iss.net/archive/dnsnat.html

&quot;  I’m writing this blog post in order to draw more attention to that observation, as I’m not sure that the security industry has realized its full implications. As far as we know, this observation applies to any NAT device, not just the firewall imipack tested, and we think it has significant implications for network architecture. 

     When a host on a computer network selects a source port for a UDP request, it selects a port that is unique for that host. When a one-to-many hiding NAT device receives that request and translates it, it has to assign a new source port, because the NAT device has to assign unique ports for all of the hosts on the internal network. X-Force is not aware of any NAT device on the market that randomly selects UDP source ports. Therefore, when patched DNS clients and servers are used behind NAT, they are still vulnerable to attack. The source port entropy introduced by the recent patches is cancelled out by the NAT device.

     It is our opinion that network administrators who have caching internal DNS servers behind NAT should plan to move those servers into a DMZ where they can be directly assigned a unique Internet IP address. Any servers that remain behind NAT devices will remain vulnerable after patches have been applied, and X-Force suspects that given the amount of media attention DNS Cache Poisoning has received this week that an increased frequency of attack is likely in the coming months.&quot;

What say thee to that?  Patching may not be enough if you physically have to move DNS servers to what amounts to DMZ&#039;s and then expose them with 1-to-1 NAT&#039;s instead of hides...oh the fun.

/Hoff</description>
		<content:encoded><![CDATA[<p>I&#8217;m also interested in the comments highlighted by Tom Cross from IBM/ISS X-force reiterating a comment sent to FD regarding DNS and NAT devices.  You can find Tom&#8217;s post here: <a href="http://blogs.iss.net/archive/dnsnat.html" rel="nofollow">http://blogs.iss.net/archive/dnsnat.html</a></p>
<p>&#8221;  I’m writing this blog post in order to draw more attention to that observation, as I’m not sure that the security industry has realized its full implications. As far as we know, this observation applies to any NAT device, not just the firewall imipack tested, and we think it has significant implications for network architecture. </p>
<p>     When a host on a computer network selects a source port for a UDP request, it selects a port that is unique for that host. When a one-to-many hiding NAT device receives that request and translates it, it has to assign a new source port, because the NAT device has to assign unique ports for all of the hosts on the internal network. X-Force is not aware of any NAT device on the market that randomly selects UDP source ports. Therefore, when patched DNS clients and servers are used behind NAT, they are still vulnerable to attack. The source port entropy introduced by the recent patches is cancelled out by the NAT device.</p>
<p>     It is our opinion that network administrators who have caching internal DNS servers behind NAT should plan to move those servers into a DMZ where they can be directly assigned a unique Internet IP address. Any servers that remain behind NAT devices will remain vulnerable after patches have been applied, and X-Force suspects that given the amount of media attention DNS Cache Poisoning has received this week that an increased frequency of attack is likely in the coming months.&#8221;</p>
<p>What say thee to that?  Patching may not be enough if you physically have to move DNS servers to what amounts to DMZ&#8217;s and then expose them with 1-to-1 NAT&#8217;s instead of hides&#8230;oh the fun.</p>
<p>/Hoff</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Eng</title>
		<link>http://www.veracode.com/blog/2008/07/what-dans-dns-checker-doesnt-do/comment-page-1/#comment-1586</link>
		<dc:creator>Chris Eng</dc:creator>
		<pubDate>Fri, 11 Jul 2008 02:02:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.veracode.com/blog/?p=120#comment-1586</guid>
		<description>@Dan:

Ah, so I&#039;m not going crazy then.  Thought that looked suspect.</description>
		<content:encoded><![CDATA[<p>@Dan:</p>
<p>Ah, so I&#8217;m not going crazy then.  Thought that looked suspect.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Kaminsky</title>
		<link>http://www.veracode.com/blog/2008/07/what-dans-dns-checker-doesnt-do/comment-page-1/#comment-1567</link>
		<dc:creator>Dan Kaminsky</dc:creator>
		<pubDate>Thu, 10 Jul 2008 23:23:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.veracode.com/blog/?p=120#comment-1567</guid>
		<description>*sighs*

There&#039;s a bug in the code.  Note that&#039;s not very random.</description>
		<content:encoded><![CDATA[<p>*sighs*</p>
<p>There&#8217;s a bug in the code.  Note that&#8217;s not very random.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

