Re: [dns-privacy] Some additional signalling ideas

"Ralf Weber" <dns@fl1ger.de> Fri, 05 April 2019 12:24 UTC

Return-Path: <dns@fl1ger.de>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58328120410 for <dns-privacy@ietfa.amsl.com>; Fri, 5 Apr 2019 05:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 OF8j38QG25Ij for <dns-privacy@ietfa.amsl.com>; Fri, 5 Apr 2019 05:24:20 -0700 (PDT)
Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 0595812040F for <dns-privacy@ietf.org>; Fri, 5 Apr 2019 05:24:20 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id CA3255F40930; Fri, 5 Apr 2019 14:24:18 +0200 (CEST)
Received: from [172.19.153.82] (a88-221-208-10.deploy.static.akamaitechnologies.com [88.221.208.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 054BD5F40423; Fri, 5 Apr 2019 14:24:16 +0200 (CEST)
From: Ralf Weber <dns@fl1ger.de>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: dns-privacy@ietf.org
Date: Fri, 05 Apr 2019 14:21:17 +0200
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <0832C5BB-23F6-4C30-8C66-9E273578113F@fl1ger.de>
In-Reply-To: <F7308B81-4FC5-4691-9AB2-5ECB00983258@powerdns.com>
References: <CACsn0ck-SNweieak5Fn7TOLLZTvsQNo6+w3nezxKuZPq0Z4QNA@mail.gmail.com> <20190331142202.GA2307@LK-Perkele-VII> <F7308B81-4FC5-4691-9AB2-5ECB00983258@powerdns.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/jJIRhV1vjAlhVkItRpjxkbxosMs>
Subject: Re: [dns-privacy] Some additional signalling ideas
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2019 12:24:22 -0000

Moin!

On 5 Apr 2019, at 10:50, Peter van Dijk wrote:

>> Adding records at child side of cut has its own issues, namely that
>> retroactive authentication can be annoying to implement, and it is
>> more difficult to make the thing work without full DNSSEC chain
>> (glue records, if parent supports that?).
>
> manu’s proposal explicitly targeted unsigned delegations, which I 
> also think is an important use case.
No it isn’t. Can we please just use the technology we have to secure 
data in the DNS instead of coming up with yet another solution for it. 
If people don’t want to DNSSEC sign their own/primary domains they 
should put the name server into different domains that can be signed and 
thus authenticated.

> Glue records are never signed.
Which isn’t a problem as one can easily validate the records in the 
child.

So long
-Ralf
—--
Ralf Weber