Joe Abley <> Fri, 07 February 2014 19:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 04A4F1ACCDE for <>; Fri, 7 Feb 2014 11:10:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DX2x5Z-hfcyO for <>; Fri, 7 Feb 2014 11:10:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::22d]) by (Postfix) with ESMTP id 774381A0601 for <>; Fri, 7 Feb 2014 11:10:33 -0800 (PST)
Received: by with SMTP id e14so1925084iej.4 for <>; Fri, 07 Feb 2014 11:10:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=U8OizpSxGOvM3xnPbQI5FEvy3c182UJe9HBLitXeKzU=; b=c84+YSmwxI2tMTw8rYBWqxs5QnoblI8RtQEpcJlUAvNXOpCbvi/3HSRxDDeLKMwjPl 6U9INY19TLi1qTPbUISKUrEeicDjG27tgxaz7dp/kHY6jiVjDEFWpY5MGn9hxfoZVqEb iJ4gYvmL24C3SxesAoTF4fKj5JgpyYzBWgXw0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=U8OizpSxGOvM3xnPbQI5FEvy3c182UJe9HBLitXeKzU=; b=IOLCxEcOVqUWOZNEaaPkBkrtTXFBzkxk3WNQdgzMwSCvomMVH4RZd5tjywetL9z/RG XaHO6llGCCXGJltJl+ESnJvoElNyTXYPqsIEl9B7o4HRyEopJmQivzW/qZAZeLPGO8q0 CPLvOkc5bRt9hwER3imOZWM7m3WOXpV4cMSBVo5MoSUV5cDWUzH5zLL3uMBvHQl+kBDe ZXrwyF3y7TJAU/OsP8g7LEob2gGcVnaKh7W9HRWrvw50jAlpGr3KREkYxaZHqouHiuR6 T5saLI6dJUowTV84+/55pN+6jpj1snQyJKqCSnB8ABmCdLnl8knALjlHzu4C7EWX2HR/ 8GEA==
X-Gm-Message-State: ALoCoQnIeb+SMwGSOqwUsfe6yf5Ms8NIuHHhpIxv/gH8BRPp1gBkvHEtXe1QnUKHQTfQZonwQOLd
X-Received: by with SMTP id yb19mr5043136icb.45.1391800233284; Fri, 07 Feb 2014 11:10:33 -0800 (PST)
Received: from ?IPv6:2001:4900:1042:1:94eb:1bb3:5e14:75f3? ([2001:4900:1042:1:94eb:1bb3:5e14:75f3]) by with ESMTPSA id h6sm12438206igy.8.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 11:10:31 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_18E48C83-CF9E-4EDF-8A25-6537F589DF26"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Joe Abley <>
In-Reply-To: <>
Date: Fri, 7 Feb 2014 14:10:30 -0500
Message-Id: <>
References: <> <> <> <> <>
To: Mukund Sivaraman <>
X-Mailer: Apple Mail (2.1827)
Cc: dnsop <>
Subject: Re: [DNSOP] DNSKEY Flags vs. CDS/CDNSKEY
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Feb 2014 19:10:39 -0000

On 2014-02-07, at 13:31, Mukund Sivaraman <> wrote:

> Did you see my reply to your email a few weeks ago where I asked why new
> CDS/CDNSKEY RR types are required instead of adding a new bit to the
> Flags field of the DNSKEY RR. Please can you look for my last email
> which lists some advantages? There may be a good reason for it, but I
> don't want you to miss considering it. :)

The apex of a signed child zone already contains a DNSKEY RRSet, and that whole RRSet is retrieved by validators who want to validate signatures within the child zone.

Adding extra RRs to that set would inflate the response sizes towards those validators with information that is of no practical benefit to them.

Putting those extra RRs in a different RRSet (CDNSKEY) means they can be explicitly retrieved by clients (provisioningware of parents, or parental agents) who need them, without sending them to other clients unnecessarily.

We are, I think, more comfortable with large responses in 2014 than we were in 2010 (at least, we are more comfortable that there are not hideous, fireball-type consequences) but I don't think we should be in the business of inflating responses for no reason.

Also, reflection attacks, amplification potential.