Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt

[Danny McPherson <danny at tcb.net>]

On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote:

> > Note that in real deployments just this behavior has broken things
> > on occasion, as many firewall and other such policy application  
> > points
> > assume things like DNS resolution will only be UDP/53 transactions.
>
> 	That assumption has always been wrong.

Not in my experience.

Actually, there are two separate things here.  One, is implementation/
product, the other is configuration and device administration.  I'm not
sure how your average user would separate the two from a practical
standpoint, and it really doesn't matter.

I'm aware of at two products in the last few months that, in production
deployment forced TCP switch-over, only to find that this broke name
resolution completely for a large pool of subscribers.

In addition, in my own experience, more often than not when folks
clamp down firewall policies, in particular in enterprise or  
"restricted"
space, they often deny all TCP/53 to address spaces (in one case the
culprit for the brokenness above).

Another common place to see policies that block TCP/53 is roaming
access points captive user environments.  E.g., SSH tunneling over
DNS was easy enough over UDP.

To further support my statement, just google for +"firewall policy"
+TCP/53 +DNS, here are a few examples:

http://www.whitehats.ca/downloads/cerberus/Rick_Wanner_GCFW.pdf

Service: The enabled service is DNS (domain-udp, port 53/udp).   
Firewall-1’s DNS service by
default contains both domain-udp (53/udp) and domain-tcp (53/tcp).   
We have removed domain-
tcp from the object definition, on the grounds that we will not be  
permitting zone transfers.  It will
be necessary to watch carefully since removing domain-tcp From ietf-bounces at ietf.org Tue Oct 02 03:16:59 2007
Return-path: <ietf-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Icbrh-0001WN-79; Tue, 02 Oct 2007 03:08:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Icbrf-0001M1-BC; Tue, 02 Oct 2007 03:08:19 -0400
Received: from dog.tcb.net ([64.78.150.133])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IcbrO-0007rb-A6; Tue, 02 Oct 2007 03:08:08 -0400
Received: by dog.tcb.net (Postfix, from userid 0)
	id D0C77268722; Tue,  2 Oct 2007 01:07:46 -0600 (MDT)
Received: from [166.128.166.36] (166.128.166.36 [166.128.166.36])
	(authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128)
	by dog.tcb.net with SMTP; Tue, 02 Oct 2007 01:07:42 -0600 (MDT)
	(envelope-from danny at tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip6.128.166.36;
	client-portP280; client-dnsfail6.128.166.36: name server failure;
	syn-fingerprinte535:53:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8;
	data-bytes=0
In-Reply-To: <200710020324.l923OrwQ023453 at drugs.dv.isc.org>
References: <200710020324.l923OrwQ023453 at drugs.dv.isc.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: <D3BBB2BE-7E0C-461C-BD48-541045E6C873 at tcb.net>
Content-Transfer-Encoding: quoted-printable
From: Danny McPherson <danny at tcb.net>
Date: Tue, 2 Oct 2007 01:05:39 -0600
To: Mark Andrews <Mark_Andrews at isc.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: dnsop-chairs at ietf.org, ietf at ietf.org, secdir at mit.edu, fneves at registro.br,
	iesg at ietf.org, joao_damas at isc.org, Jeffrey Hutzelman <jhutz at cmu.edu>
Subject: Re: [secdir] secdir review of
	draft-ietf-dnsop-reflectors-are-evil-04.txt
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org


On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote:

> > Note that in real deployments just this behavior has broken things
> > on occasion, as many firewall and other such policy application  
> > points
> > assume things like DNS resolution will only be UDP/53 transactions.
>
> 	That assumption has always been wrong.

Not in my experience.

Actually, there are two separate things here.  One, is implementation/
product, the other is configuration and device administration.  I'm not
sure how your average user would separate the two from a practical
standpoint, and it really doesn't matter.

I'm aware of at two products in the last few months that, in production
deployment forced TCP switch-over, only to find that this broke name
resolution completely for a large pool of subscribers.

In addition, in my own experience, more often than not when folks
clamp down firewall policies, in particular in enterprise or  
"restricted"
space, they often deny all TCP/53 to address spaces (in one case the
culprit for the brokenness above).

Another common place to see policies that block TCP/53 is roaming
access points captive user environments.  E.g., SSH tunneling over
DNS was easy enough over UDP.

To further support my statement, just google for +"firewall policy"
+TCP/53 +DNS, here are a few examples:

http://www.whitehats.ca/downloads/cerberus/Rick_Wanner_GCFW.pdf

Service: The enabled service is DNS (domain-udp, port 53/udp).   
Firewall-1’s DNS service by
default contains both domain-udp (53/udp) and domain-tcp (53/tcp).   
We have removed domain-
tcp from the object definition, on the grounds that we will not be  
permitting zone transfers.  It will
be necessary to watch carefully since removing domain-tcp also means  
that long dns-queries will
not be supported.   It is important to note that this will not work  
unless “Accept UDP replies” is
enabled on the Firewall-1 Security Properties screen.  Without  
“Accept UDP replies” enabled, the
queries will still be allowed through the firewall, but the replies  
will be dropped on the firewall.

http://security.ucdavis.edu/basic_firewall_rules.pdf:

Allow DNS (UDP 53) to internal DNS server – If the unit runs internal  
DNS servers this
rule is recommended. The rule is needed if a Windows Active Directory  
server is hosted
on the internal network.  You must permit TCP 53 for zone transfer  
capability, however
this permission should not be applied by default.

Right or wrong, it's quite common.

> 	I would also dispute the "many" above.   Most firewalls
> 	actually handle the transition to TCP perfectly fine.  There
> 	are the odd few that are misconfigured.  When that happens
> 	people complain because nameservers resolution fails.  Either
> 	the dataset is "fixed" or the firewall is fixed.

I'd be quite interested in any pointers you might have to empirical
evidence supporting this position.  I don't believe it's an odd few
that are misconfigured, I believe it's often done as a conscious
effort.

-danny
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf