Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?
Robert Edmonds <edmonds@mycre.ws> Thu, 12 November 2015 17:35 UTC
Return-Path: <edmonds@mycre.ws>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011D41B2ABD for <dnsop@ietfa.amsl.com>; Thu, 12 Nov 2015 09:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1MujmI8b5mO for <dnsop@ietfa.amsl.com>; Thu, 12 Nov 2015 09:35:21 -0800 (PST)
Received: from chase.mycre.ws (chase.mycre.ws [70.89.251.89]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722771B2ABB for <dnsop@ietf.org>; Thu, 12 Nov 2015 09:35:21 -0800 (PST)
Received: by chase.mycre.ws (Postfix, from userid 1000) id 1102E1C441E7; Thu, 12 Nov 2015 12:35:19 -0500 (EST)
Date: Thu, 12 Nov 2015 12:35:19 -0500
From: Robert Edmonds <edmonds@mycre.ws>
To: John Kristoff <jtk@cymru.com>
Message-ID: <20151112173519.GA21365@mycre.ws>
References: <D26A217F.1E6DC%gwiley@verisign.com> <B66E268E-866C-4C47-BB93-7D2D41FDC8D1@icsi.berkeley.edu> <20151112104340.4ebb742a@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20151112104340.4ebb742a@localhost>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/jHIiVaVJ3GF6tPrPuk7QA4yg3E0>
Cc: "Wiley, Glen" <gwiley@verisign.com>, "dnsop@ietf.org" <dnsop@ietf.org>, Nicholas Weaver <nweaver@icsi.berkeley.edu>
Subject: Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2015 17:35:23 -0000
John Kristoff wrote: > After a DNS over TCP discussion a student of mine indicated that they > recently fixed a problem in their network where DNS messages over 512 > bytes were not being relayed. It appears the root cause has to do with > some defaults being set common gear that simply drops messages over 512 > bytes. For example: > > <http://www.cisco.com/web/about/security/intelligence/dns-bcp.html#5> > > !-- Enable a maximum message length to help defeat DNS > !-- amplification attacks. Note: This is the default > !-- configuration and value based on RFC 1035. > ! > message-length maximum 512 Ironically, elsewhere in that same document series: http://www.cisco.com/web/about/security/intelligence/dnssec.html Potential Networking Challenges with DNSSEC Deployment The networking-specific challenges from DNSSEC are largely the result of the differences mentioned previously: increased packet sizes, EDNS requirements and the more frequent use of TCP. Many firewall devices incorrectly limit DNS responses to 512 and prohibit DNS over TCP. [...] This is still wrong, though; "and" should be "or", as in "Many firewall devices incorrectly limit DNS responses to 512 *or* prohibit DNS over TCP." That document further states: Connectivity Over UDP and TCP port 53 Because most DNS traffic is sent over UDP port 53, any filtering of traffic that exists on the network is unlikely to impact future native DNS traffic that is traversing UDP port 53. However, if DNS traffic is not currently permitted to traverse TCP port 53, which is typically used for large DNS packets (that is, those greater than 512 bytes), any issues with DNS traffic over TCP port 53 will be exacerbated when DNSSEC packets begin arriving on the network, because many DNSSEC packets will be greater than 512 bytes due to the additional packet overhead of DNSSEC. If traffic using TCP port 53 is currently not permitted, or is being filtered to or from specific hosts or networks, then it may be necessary to account for new hosts and networks that could be sending DNSSEC traffic over TCP port 53. This seems to be implying that it's OK to block >512B UDP as long as you don't *also* block TCP/53 :-( -- Robert Edmonds
- [DNSOP] are there recent studies of client side/I… Wiley, Glen
- Re: [DNSOP] are there recent studies of client si… Nicholas Weaver
- Re: [DNSOP] are there recent studies of client si… John Kristoff
- Re: [DNSOP] are there recent studies of client si… Nicholas Weaver
- Re: [DNSOP] are there recent studies of client si… Robert Edmonds
- Re: [DNSOP] are there recent studies of client si… Mark Andrews