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

Nicholas Weaver <nweaver@icsi.berkeley.edu> Tue, 08 March 2011 21:34 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 E0E823A659B for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 13:34:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 hF1KZj5qxm4u for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 13:34:55 -0800 (PST)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id B9B263A6405 for <dnsext@ietf.org>; Tue, 8 Mar 2011 13:34:55 -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 3908536A413; Tue, 8 Mar 2011 13:36:11 -0800 (PST)
References: <4D76A01E.5000005@dougbarton.us>
In-Reply-To: <4D76A01E.5000005@dougbarton.us>
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
Message-Id: <3065CCAA-2396-4D13-956D-4FBE1F89D36E@icsi.berkeley.edu>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Date: Tue, 8 Mar 2011 13:36:10 -0800
To: Doug Barton <dougb@dougbarton.us>
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:34:57 -0000

On Mar 8, 2011, at 1:31 PM, Doug Barton 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?
> 
> Imagine the following scenario:
> 
> 1. stub requests clone1.example.org A
> 2. Old resolving name server (RNS) which doesn't understand the CLONE RR does it's thing, and gets back the A record, plus "clone1.example.org CLONE preferred.example.org" in the ANSWER section.
> 
> Does the RNS pass the unknown RR back to the stub? And sorry for my ignorance, but are there references to this that I can dig into?

I do NOT know about:

request clone.examlple.org A
return clone1.example.org CLONE preferred.example.org.


I DO know that

request clone.examlple.org CLONE
return clone1.example.org CLONE preferred.example.org.

Actually does work, well mostly.  

Some clients are behind seriously broken resolvers (usually NATs) that basically barf on anything thats not an A record.  

But if the client can get a TXT record, they can probably get an unknown record.  (only ~1% can't do TXT XOR UNKNOWN, its almost always you can do both or you can do neither, and packet loss can inflate that value).  

And most of THOSE clients can just bypass the borken recursive resolver and do a direct fetch to the network.