Re: [DNSOP] DNSSEC and ALIAS/ANAME apex record in PowerDNS

Paul Hoffman <paul.hoffman@vpnc.org> Mon, 22 September 2014 14:09 UTC

Return-Path: <paul.hoffman@vpnc.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 C79B61A1B37 for <dnsop@ietfa.amsl.com>; Mon, 22 Sep 2014 07:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level:
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 0i_wF5EipMZ6 for <dnsop@ietfa.amsl.com>; Mon, 22 Sep 2014 07:09:56 -0700 (PDT)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 E73101A6F51 for <dnsop@ietf.org>; Mon, 22 Sep 2014 06:58:04 -0700 (PDT)
Received: from [10.20.30.90] (50-1-50-250.dsl.dynamic.fusionbroadband.com [50.1.50.250]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s8MDw0oB063117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Sep 2014 06:58:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 50-1-50-250.dsl.dynamic.fusionbroadband.com [50.1.50.250] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20140921181433.GC16178@xs.powerdns.com>
Date: Mon, 22 Sep 2014 06:57:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC920AF7-FADB-492E-8A23-C5242EA80D0D@vpnc.org>
References: <20140921115222.GB16178@xs.powerdns.com> <412982B8-DBB4-475E-8A85-352AF35B579F@vpnc.org> <20140921181433.GC16178@xs.powerdns.com>
To: bert hubert <bert.hubert@netherlabs.nl>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/0AlA-5zFl0jzAzaYELewJHP75tY
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] DNSSEC and ALIAS/ANAME apex record in PowerDNS
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: <http://www.ietf.org/mail-archive/web/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: Mon, 22 Sep 2014 14:09:58 -0000

On Sep 21, 2014, at 11:14 AM, bert hubert <bert.hubert@netherlabs.nl> wrote:

> On Sun, Sep 21, 2014 at 08:13:46AM -0700, Paul Hoffman wrote:
>>> PS: the above is currently not yet supported for DNSSEC domains!
>> 
>> Can you say (much) more about that aside? Does it mean that the server
>> will fail to load the zone if there is DNSSEC records and ALIAS
>> pseudo-records?  Or that the DNSSEC gets broken?  Or that the ALIAS gets
>> broken?  Or...  ?
> 
> In the current branch, it will load the zone, but neglect to add signatures
> for the proxied records. In other words, if you do DNSSEC, it will load the
> zone but make you BOGUS. 

Far be it from me to tell you want to do with your UI, but that seems like a worse choice than refusing to load the zone and giving an error that indicates that the zone file is misconfigured. In specific, when the operator will discover that the zone is bogus because someone else tell them, they will stare at the zone file and see nothing wrong.

> This is not a fundamental problem as long as we have keys. If you don't have
> the keys, we can't sign any how. We'll add the signing code shortly, we just
> haven't typed it in yet.

I'm not sure what that paragraph means at all.

> An interesting opening is that we'd be signing potentially unsigned data
> this way. Potentially, we should check for the AD bit. But first let's see
> how this idea fits.

It is seeming to fit, so discussing the DNSSEC implications of it seems appropriate to do now.

--Paul Hoffman