Re: [dnsext] How well supported are unknown RRs in modern resolvers?

Nicholas Weaver <nweaver@icsi.berkeley.edu> Tue, 08 March 2011 21:56 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C523A66B4 for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 13:56:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level:
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPROs6PMqp7A for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 13:56:32 -0800 (PST)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 7B2653A659B for <dnsext@ietf.org>; Tue, 8 Mar 2011 13:56:32 -0800 (PST)
Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2045F36A413; Tue, 8 Mar 2011 13:57:48 -0800 (PST)
References: <4D76A01E.5000005@dougbarton.us> <B5393963B7B95CA5927105FE@nimrod.local>
In-Reply-To: <B5393963B7B95CA5927105FE@nimrod.local>
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
Message-Id: <F7A0142E-EA2B-4A81-98D4-991C9619BAB0@icsi.berkeley.edu>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Date: Tue, 8 Mar 2011 13:57:47 -0800
To: Alex Bligh <alex@alex.org.uk>
X-Mailer: Apple Mail (2.1082)
Cc: dnsext@ietf.org
Subject: Re: [dnsext] How well supported are unknown RRs in modern resolvers?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2011 21:56:33 -0000

On Mar 8, 2011, at 1:41 PM, Alex Bligh wrote:

> 
> 
> --On 8 March 2011 13:31:10 -0800 Doug Barton <dougb@dougbarton.us> wrote:
> 
>> The point Nicholas made about moving the CLONE logic to the stub is
>> something I'm interested in pursuing, but my understanding is that "a
>> lot" of resolving name servers still have problems dealing with RR types
>> they don't understand. Is this still true?
> 
> I would expand your worry-space from resolvers to include middleboxen also.
> 
> Nick should have / could collect some good data on this. I think this is
> going to push us into EDNS if only for signalling reasons. Ray Bellis's
> report suggests that serious SOHO CPE problems will arise if the packets
> get larger than 512 bytes, but I don't think he explicitly tested unknown
> RRs.

We probe the NAT specifically, and its bad but not as bad as you think:

OFTEN you can bypass the NAT (we check direct over the wire as well).

And if you can get TXT, you can usually get unknown RRs.  (Its either 'get both or get neither', which means 'shove data into a TXT record' is a bad idea: it doesn't help)


We also test EDNS and large responses over the wire (but not all the way to the client, need to add that in).  The 512B limit is less terrifying, fragmentation is a bigger problem really.


(we have a paper in the polish stage, we'll post it here when its done).

We don't test unknown EDNS0 options however.