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

Doug Barton <dougb@dougbarton.us> Tue, 08 March 2011 22:21 UTC

Return-Path: <dougb@dougbarton.us>
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 7CC023A67AB for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 14:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 WRg0Ux0gYJDH for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 14:20:53 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 436753A676A for <dnsext@ietf.org>; Tue, 8 Mar 2011 14:20:10 -0800 (PST)
Received: (qmail 6723 invoked by uid 399); 8 Mar 2011 22:21:13 -0000
Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 8 Mar 2011 22:21:13 -0000
X-Originating-IP: 75.60.237.91
X-Sender: dougb@dougbarton.us
Message-ID: <4D76ABD7.2030608@dougbarton.us>
Date: Tue, 08 Mar 2011 14:21:11 -0800
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9
MIME-Version: 1.0
To: Alex Bligh <alex@alex.org.uk>
References: <4D76A01E.5000005@dougbarton.us> <B5393963B7B95CA5927105FE@nimrod.local>
In-Reply-To: <B5393963B7B95CA5927105FE@nimrod.local>
X-Enigmail-Version: 1.1.2
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 22:22:26 -0000

On 03/08/2011 13:41, 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.

Yeah, "middleboxes are a hard problem" is one of the reasons that I 
heavily focused on the resolver for the DNSSEC part of the solution for 
CLONE, and (admittedly) ignored the stub part of the equation. OTOH, if 
we're going to get DNSSEC validation pushed down into the stub the 
middlebox problem really has to be solved.

So what are the chances that we're going to be able to reliably deal 
with stubs passing EDNS _options_ (I'm not talking about just the size 
of the packet, I'm talking about actually having the stub say "I'd like 
EDNS option foo please").


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/