Re: [dnsext] Practical question about backwards compatibility and new proposals

Brian Dickson <> Fri, 17 September 2010 03:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 617483A6ADD; Thu, 16 Sep 2010 20:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.959
X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=1.639, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YXnrgXl-qaQL; Thu, 16 Sep 2010 20:13:26 -0700 (PDT)
Received: from ( [IPv6:2001:418:1::62]) by (Postfix) with ESMTP id 118863A6BA4; Thu, 16 Sep 2010 20:13:21 -0700 (PDT)
Received: from majordom by with local (Exim 4.72 (FreeBSD)) (envelope-from <>) id 1OwRHw-000Fb9-Ro for; Fri, 17 Sep 2010 03:07:00 +0000
Received: from ([]) by with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <>) id 1OwRHs-000Fah-Rd for; Fri, 17 Sep 2010 03:06:57 +0000
Received: by bwz3 with SMTP id 3so2709209bwz.11 for <>; Thu, 16 Sep 2010 20:06:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=F3rYikmZ57Qu+2TLHLiP4SlDCSYngQq/PZVsSSzgzbg=; b=c9JEWxASOVvjXsalUCb2oMpG/vrFReeVpTNxmM96RKX9VtsmoNvdb5AaA7GqNAinle qzUmisv1pkxL2rE8OJED8+ozF7ZlYwRRoIEKiGYUk6QbPopdsUaVkJTSs8ml8IzeuG2B t9zFPNJXoicnKu0nD6oOBZhbRzuRFWZOE/4VI=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VCX+mHNxfscDRRzBQ+mwwy2iAZsF2lfqP+Ix13jWQh4WIBGZZZH75B2MR3ItFlwYWl t58IZPGeTQOUaKni4aSYuzVFflvE6PRt9pYlweI4gXa99bRltJjz+aO9WjXvFo0hl45j 5+Hwy4M8WoRUjppLSa7pPJmEA5BcFu4Ct7Rzc=
MIME-Version: 1.0
Received: by with SMTP id g7mr772708fap.96.1284692815240; Thu, 16 Sep 2010 20:06:55 -0700 (PDT)
Received: by with HTTP; Thu, 16 Sep 2010 20:06:55 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 17 Sep 2010 00:06:55 -0300
Message-ID: <>
Subject: Re: [dnsext] Practical question about backwards compatibility and new proposals
From: Brian Dickson <>
To: Andras Gustafsson <>
Content-Type: multipart/alternative; boundary=001636c5a6dde5de1104906bda8a
Precedence: bulk
List-ID: <>
List-Unsubscribe: To unsubscribe send a message to with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <>

On Thu, Sep 16, 2010 at 4:19 AM, Andras Gustafsson <>; wrote:

> Brian Dickson wrote:
> > 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
> > yet?
> There was some discussion related to this last year, starting with
> To reiterate what I said then, I think the concepts of "RRs of unknown
> type" and "unexpected RRs appearing in some section of a message"
> should be treated as orthogonal.  For example, a type MX record
> occurring in the answer section of a response to a type A query is an
> unexpected RR, but it is not of unknown type.
> RFC 3597 deals with unknown types, but I don't think the treatment
> of unexpected RRs is currently specified anywhere.  Existing
> implementations tend to ignore them when they occur in the answer
> section of a response, and may or may not cache them when they occur
> in the additional section depending on spoofing defense strategy.
> If we end up specifying the treatment of unexpected/unsolicited RRs,
> I think whatever treatment we specify should be the same whether the
> type is known or unknown.
> --
> Andreas Gustafsson,

Excellent point.

This, and the discussion regarding DTLS in another thread, suggest that
(a) there is a problem with introducing new types, generally,
and (b) changing what should be expected is also a problem, particularly
for caches and middleboxes.

I think the gist of 3597-bis, and the discussion around it, is that changes
to what is "expected", introduce a potential security problem.

I think the answer comes from DNSSEC.

DNSSEC provides the means to validate RRsets, even if the type/class is not
The signature algorithm is well defined, as is the proof mechanism, for
from a known trust anchor.

This provides two paths through a middle box.

First is have the middle box validate the unexpected or unknown RR.

The second is to have the middle box not validate, but to only provide
RRs that are unknown/unexpected, if the CD bit is set. In this case, CD
not only does the client do validation, but the client may understand better
the middle box, what the unexpected stuff is and how to deal with it.

In both cases, the end-to-end path from the authority server to the client
is authenticated,
which means that the security issue is no worse than, and probably better
than, the case
where the RR types are known and expected.

What do folks think?