Re: [DNSOP] draft-jabley-dnsop-ordered-answers

Mark Andrews <marka@isc.org> Thu, 05 November 2015 22:14 UTC

Return-Path: <marka@isc.org>
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 D00D51B3C41 for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2015 14:14:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 orEELQa6KDcM for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2015 14:14:02 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941721B3C3E for <dnsop@ietf.org>; Thu, 5 Nov 2015 14:14:02 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id BFFD83493C3; Thu, 5 Nov 2015 22:14:00 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B7B46160076; Thu, 5 Nov 2015 22:14:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9C4B6160031; Thu, 5 Nov 2015 22:14:03 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id j4uz3nI_MQ1T; Thu, 5 Nov 2015 22:14:03 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 57316160078; Thu, 5 Nov 2015 22:14:03 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DA9E83BF1AD0; Fri, 6 Nov 2015 09:13:57 +1100 (EST)
To: Ray Bellis <ray@bellis.me.uk>
From: Mark Andrews <marka@isc.org>
References: <1E5B644E-EA0D-4287-8AB5-1907EE06BE1C@hopcount.ca> <563B58FE.50905@bellis.me.uk> <m2mvusfnlq.wl-Niall.oReilly@ucd.ie> <563BC83C.3050808@bellis.me.uk>
In-reply-to: Your message of "Fri, 06 Nov 2015 06:21:00 +0900." <563BC83C.3050808@bellis.me.uk>
Date: Fri, 06 Nov 2015 09:13:57 +1100
Message-Id: <20151105221357.DA9E83BF1AD0@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/voMpjPbC1PbI4C2IJWKBrSyDeug>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] draft-jabley-dnsop-ordered-answers
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, 05 Nov 2015 22:14:04 -0000

In message <563BC83C.3050808@bellis.me.uk>, Ray Bellis writes:
> 
> 
> On 06/11/2015 00:54, Niall O'Reilly wrote:
> 
> >   Wouldn't it be a simpler clarification to say that a client MUST NOT
> >   depend on the order of the RRsets in an answer?
> 
> That's what I meant (blame jetlag).
> 
> Ray

The RFC 1034 actually says:

	    If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

	    Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

Now I fail to see how one can "copy the CNAME RR" on pass one and
then "copy all RRs which match QTYPE" on a later pass and end up
with the "second set of records before the CNAME".

This is not "add to a list to be later copied to the answer section".
This is do it right now.

Now I know that many implementations just add records to lists and
then render them all at once but if that does not produce the same
results as just copying them when instructed then the implementation
is broken.

I also know that resolver should be more robust.

I also know that there are a many magnitudes more resolvers than
servers and that fixing (or declaring the servers broken and then
fixing for Andrew) is the best thing to do.

Mark

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org