<?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 Darwinism</title>
	<atom:link href="http://mcwresearch.com/archives/569/feed" rel="self" type="application/rss+xml" />
	<link>http://mcwresearch.com/archives/569</link>
	<description>Things I think I've thought about</description>
	<lastBuildDate>Wed, 06 Jan 2010 16:45:57 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: Michael</title>
		<link>http://mcwresearch.com/archives/569/comment-page-1#comment-4836</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Thu, 15 Nov 2007 16:15:39 +0000</pubDate>
		<guid isPermaLink="false">http://mcwresearch.com/archives/569#comment-4836</guid>
		<description>I&#039;d also like to add that DoS conditions are of little concern for our shop.  In six years working here I&#039;ve only once witnessed a DoS event impact us and it was indirect; one of our hosts was zombified and was trying to participate in a DDoS, which effectively DoS&#039;ed the local network.  The cause of that was a worm, which has been a realized threat to us, and one that we&#039;ve spent considerable time and money to combat (quite effectively I might add).  

The truth is that we would end up spending an equal amount of time and energy addressing DoS vectors as we have addressing worm vectors and the latter has proven to be a much more worthwhile venture.  Our publicly-accessible services are far more *expendable*, for lack of a better word,  than are our internal services.  

I&#039;ve read some of your information on DoS mitigation and it&#039;s impressive and certainly worth reading for shops who are concerned about DoS mitigation.</description>
		<content:encoded><![CDATA[<p>I&#8217;d also like to add that DoS conditions are of little concern for our shop.  In six years working here I&#8217;ve only once witnessed a DoS event impact us and it was indirect; one of our hosts was zombified and was trying to participate in a DDoS, which effectively DoS&#8217;ed the local network.  The cause of that was a worm, which has been a realized threat to us, and one that we&#8217;ve spent considerable time and money to combat (quite effectively I might add).  </p>
<p>The truth is that we would end up spending an equal amount of time and energy addressing DoS vectors as we have addressing worm vectors and the latter has proven to be a much more worthwhile venture.  Our publicly-accessible services are far more *expendable*, for lack of a better word,  than are our internal services.  </p>
<p>I&#8217;ve read some of your information on DoS mitigation and it&#8217;s impressive and certainly worth reading for shops who are concerned about DoS mitigation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael</title>
		<link>http://mcwresearch.com/archives/569/comment-page-1#comment-4835</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Thu, 15 Nov 2007 16:04:28 +0000</pubDate>
		<guid isPermaLink="false">http://mcwresearch.com/archives/569#comment-4835</guid>
		<description>By blocking TCP/53 from leaving my network, I prevent zone transfers from leaving my network at all.  In an Active Directory environment, if someone can transfer your zone out of your network they are able to gain an enormous amount of intelligence about your network, which would amount to a &#039;check&#039; situation, with only a few moves to &#039;check mate&#039;.

When I said that external DNS servers should be &#039;intentionally ignorant&#039;, I was implying a tiered solution, where externally, the DNS infrastructure does not maintain a copy of the internal zone.  

I&#039;ve blocked TCP/53 for years and have yet to see a problem arise because of it.

I&#039;m curious how its harmful in the extreme. 

You bring up an interesting point about state-full firewalls in front of DNS servers.   I would assume that would be a DoS vector for &lt;i&gt;any&lt;/i&gt; service, not just DNS.  Though I&#039;ll be the first to admit I&#039;m no DNS guru.</description>
		<content:encoded><![CDATA[<p>By blocking TCP/53 from leaving my network, I prevent zone transfers from leaving my network at all.  In an Active Directory environment, if someone can transfer your zone out of your network they are able to gain an enormous amount of intelligence about your network, which would amount to a &#8216;check&#8217; situation, with only a few moves to &#8216;check mate&#8217;.</p>
<p>When I said that external DNS servers should be &#8216;intentionally ignorant&#8217;, I was implying a tiered solution, where externally, the DNS infrastructure does not maintain a copy of the internal zone.  </p>
<p>I&#8217;ve blocked TCP/53 for years and have yet to see a problem arise because of it.</p>
<p>I&#8217;m curious how its harmful in the extreme. </p>
<p>You bring up an interesting point about state-full firewalls in front of DNS servers.   I would assume that would be a DoS vector for <i>any</i> service, not just DNS.  Though I&#8217;ll be the first to admit I&#8217;m no DNS guru.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roland Dobbins</title>
		<link>http://mcwresearch.com/archives/569/comment-page-1#comment-4834</link>
		<dc:creator>Roland Dobbins</dc:creator>
		<pubDate>Thu, 15 Nov 2007 03:11:44 +0000</pubDate>
		<guid isPermaLink="false">http://mcwresearch.com/archives/569#comment-4834</guid>
		<description>Your comment about blocking TCP/53 and &#039;long replies by damned&#039; is 100% incorrect and is harmful in the extreme.  Instead, DNS servers should be tiered, and public-facing DNS servers simply shouldn&#039;t allow zone transfers from hosts outside one&#039;s own network(s).

Also, firewalls should not be placed in front of public-facing DNS servers; the state of the firewall is a DoS vector.  Instead, stateless ACLs (hopefully on an ASIC-based router platform) coupled with tight sysadmin practices and other reaction/mitigation systems (S/RTBH, DDoS scrubbers, etc.) should be utilized as circumstances warrant.</description>
		<content:encoded><![CDATA[<p>Your comment about blocking TCP/53 and &#8216;long replies by damned&#8217; is 100% incorrect and is harmful in the extreme.  Instead, DNS servers should be tiered, and public-facing DNS servers simply shouldn&#8217;t allow zone transfers from hosts outside one&#8217;s own network(s).</p>
<p>Also, firewalls should not be placed in front of public-facing DNS servers; the state of the firewall is a DoS vector.  Instead, stateless ACLs (hopefully on an ASIC-based router platform) coupled with tight sysadmin practices and other reaction/mitigation systems (S/RTBH, DDoS scrubbers, etc.) should be utilized as circumstances warrant.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

