[dnsext] Practical question about backwards compatibility and new proposals

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 16 September 2010 04:08 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 199F83A68F1; Wed, 15 Sep 2010 21:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.893
X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[AWL=1.705, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id QNfKWRx9xKBT; Wed, 15 Sep 2010 21:08:05 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D3123A67FA; Wed, 15 Sep 2010 21:08:04 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Ow5eU-0000YX-QI for namedroppers-data0@psg.com; Thu, 16 Sep 2010 04:00:50 +0000
Received: from mail-bw0-f52.google.com ([]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <brian.peter.dickson@gmail.com>) id 1Ow5eQ-0000YA-It for namedroppers@ops.ietf.org; Thu, 16 Sep 2010 04:00:47 +0000
Received: by bwz3 with SMTP id 3so1190462bwz.11 for <namedroppers@ops.ietf.org>; Wed, 15 Sep 2010 21:00:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=mZ39YIXVH9pK4tZbvEx+Y3F41pggLhpAl7XVMmFfHIg=; b=MO726FQzRo9k87M3b+b4ECyuF7sunF68unEvEiFESuLCchpiUoUituR8KRo52km1GG zEKjMjhGsovLWZZ7WaeWMnjIaUm02yvVBWxPn2S6/Wflp3XPC+qRVVcYVZq92y6qCLcC 7j1EJHcVaEINjILQ+HWDj5ataBsi55buuxiWg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vmcnGSFBlQhhElr1yIp9cilQ+raoyZ9L7olmlGftD3M9P/xgmZaglE6YEQVPGRhgcq j7DDm1hcyyt+Ma/UFxE0N7oODrlxIsiCIoBZrpMfpdddkbEtGUWqRH5XiokoxDxJG+aw k+XOBaaV7517hHpr8expyENPMIgijHQo1a8Xw=
MIME-Version: 1.0
Received: by with SMTP id s18mr1041243fao.77.1284609644484; Wed, 15 Sep 2010 21:00:44 -0700 (PDT)
Received: by with HTTP; Wed, 15 Sep 2010 21:00:44 -0700 (PDT)
Date: Thu, 16 Sep 2010 01:00:44 -0300
Message-ID: <AANLkTi=8Q-QZJo4Js_tUEg_WK0wDPv2rEumvMp+QfTeG@mail.gmail.com>
Subject: [dnsext] Practical question about backwards compatibility and new proposals
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: namedroppers@ops.ietf.org
Content-Type: multipart/alternative; boundary=0016e6d3854088d9e10490587d00
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

I'll try to keep this one brief...

In any proposal to modify some parts of the DNS, it may be desirable or even
necessary to introduce some new ways to answer old questions.

(E.g. DNAME causing answers with synthesized CNAMEs in addition to the DNAME
and post-rewrite answer. Extrapolate to other kinds of multi-answers, which
might included similarly synthesized CNAMEs.)

One issue is how to "propagate" answers involving combinations of known and
unknown types, through caches (and possibly other middle-boxes), to
new-type-aware clients.

RFC 3597 is about "handling" unknown RR types, but I presume that to be
rather narrow, in that the new RR type/class is the qtype/class, not
something that shows up in an answer as "extra stuff" in the answer, or in
the "additional" section.

Is this (caching of new RR types in answer to questions that *aren't* the
new RR type) something that is specified, one way or the other, anywhere

If not, it seems to be a show-stopper to backward compatibility as a general
thing, as opposed to very narrow built-in compatibility solutions. And thus
to forward compatibility, i.e. new RR types other than those of very narrow

In an ideal world, when a cache receives a bunch of RRsets that get returned
from an authority server, with suitable owner name(s), even if their type is
unknown, should be cached with the answer, and returned in answer to client
queries that match the original query that caused the cache to get populated
in the first place.

Then, largely, caches would be nearly completely future-proof, and it would
be feasible to introduce new RR types, sets of types, and even logic,
without having to worry as much about the caches.

I.e., if a query for qname "example.com" of type FOO, returns answers with
name "example.com", for type FOO, plus type BAR, and maybe an existing type,
and matching RRSIGs for the new types, caching the results as a "set of
sets" means subsequent queries for FOO/example.com can be answered from the
cache, just as if the query had been sent directly to the authority server.
So, without knowing the rules, a query for FOO, can return
FOO+BAR+stuff+RRSIGs, both the first time, primed by the authority server,
and subsequent times, based on cache look-up.

Obviously there are security considerations, e.g. bailiwick, but if the
records are not cached in the general cache, but rather only underneath the
specific name/qclass/qtype tuple, I think the security issues are largely

Pointers? Thoughts? Suggestions?