[DNSOP] order of records in DNAME responses

Evan Hunt <each@isc.org> Thu, 23 February 2017 23:24 UTC

Return-Path: <each@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 518B71296A2 for <dnsop@ietfa.amsl.com>; Thu, 23 Feb 2017 15:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iCFwTjxZZj2P for <dnsop@ietfa.amsl.com>; Thu, 23 Feb 2017 15:24:37 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67A7129B08 for <dnsop@ietf.org>; Thu, 23 Feb 2017 15:24:35 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 139683493CF for <dnsop@ietf.org>; Thu, 23 Feb 2017 23:24:33 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 032E2216C1C; Thu, 23 Feb 2017 23:24:33 +0000 (UTC)
Date: Thu, 23 Feb 2017 23:24:32 +0000
From: Evan Hunt <each@isc.org>
To: dnsop@ietf.org
Message-ID: <20170223232432.GA41294@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UfSZmyc94kowRG5uAri0Oqto4nU>
Subject: [DNSOP] order of records in DNAME responses
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Feb 2017 23:24:38 -0000

RFC 6672 saith:

    A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME
    RR is synthesized and included in the answer section when the DNAME
    is employed as a substitution instruction. The DNSSEC specification
    ([RFC4033] [RFC4034] [RFC4035]) says that the synthesized CNAME does
    not have to be signed.  The signed DNAME has an RRSIG, and a validating
    resolver can check the CNAME against the DNAME record and validate the
    signature over the DNAME RR.

The phrase "included in", as opposed to "appended to", provides no guidance
about the order in which records appear, so presumably it's legal to have
the synthesized CNAME appear first and the DNAME from which it was
synthesized afterward.

Most implementations, however, do send the DNAME first.  We had a problem
with BIND a while back when we encountered a server that didn't.  BIND
processes the RRsets in an answer in the order they're received (I suspect
nearly all resolvers do this).  In this case, the decisions about how to
validate and cache the CNAME went wrong because we didn't have the flag set
saying we'd previously seen a DNAME.

We rejiggered the code so it wouldn't care about the order of records
anymore (incidentally, and embarrassingly, introducing another bug in the
process, but that's another story).  It would have been simpler and more
painless if we could have just treated this condition as a FORMERR.

I'd like to start a discussion of that now.  Does anyone have a problem
with the idea of clarifying the protocol here, saying that the order of
records in the answer section of a chaining response is significant, and in
particular, that a DNAME MUST precede the corresponding synthesized CNAME?

Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.