IETF Logo Mail Archive

Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

John Kristoff <jtk@cymru.com> Thu, 12 November 2015 16:43 UTC

Return-Path: <jtk@cymru.com>
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 1BC531B3013 for <dnsop@ietfa.amsl.com>; Thu, 12 Nov 2015 08:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 sXfYrUO8UhlO for <dnsop@ietfa.amsl.com>; Thu, 12 Nov 2015 08:43:40 -0800 (PST)
Received: from mailout.cymru.com (mailout.cymru.com [38.229.36.8]) by ietfa.amsl.com (Postfix) with ESMTP id B69D51B3012 for <dnsop@ietf.org>; Thu, 12 Nov 2015 08:43:40 -0800 (PST)
Received: from localhost (vpn-72-47.svcs.ord07.cymru.com [172.16.72.47]) by mailout.cymru.com (Postfix) with ESMTP id 6FFFE46EEE6; Thu, 12 Nov 2015 16:43:42 +0000 (GMT)
Date: Thu, 12 Nov 2015 10:43:40 -0600
From: John Kristoff <jtk@cymru.com>
To: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Message-ID: <20151112104340.4ebb742a@localhost>
In-Reply-To: <B66E268E-866C-4C47-BB93-7D2D41FDC8D1@icsi.berkeley.edu>
References: <D26A217F.1E6DC%gwiley@verisign.com> <B66E268E-866C-4C47-BB93-7D2D41FDC8D1@icsi.berkeley.edu>
User-Agent: Claws Mail
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/CV0fyfzxwkGNgVWP6lO9RKl_ttU>
Cc: "Wiley, Glen" <gwiley@verisign.com>, "dnsop@ietf.org" <dnsop@ietf.org>
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 16:43:42 -0000

On Thu, 12 Nov 2015 08:00:50 -0800
Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:

> We've done some of this in Netalyzr.  Captive portals in particular
> are a problem, with about 1% of systems measured in Netalyzr unable
> to use EDNS0 to get DNSSEC information either from the recursive
> resolver OR directly from the roots.

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

This contradicts what IETF RFC 6891 (EDNS0, April 2013) now says:

   6.2.6.  Support in Middleboxes
   [...]
   Conformant middleboxes MUST NOT limit DNS messages over UDP to 512
   bytes.

John

v2.23.0 | Report a Bug | By Email