Re: [dns-privacy] Next steps for draft-rescorla-dprive-adox

Paul Wouters <paul@nohats.ca> Wed, 12 May 2021 02:27 UTC

Return-Path: <paul@nohats.ca>
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 0F4783A2FB2 for <dns-privacy@ietfa.amsl.com>; Tue, 11 May 2021 19:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 js7XtS7GhQYl for <dns-privacy@ietfa.amsl.com>; Tue, 11 May 2021 19:27:46 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 8D4D83A2FB1 for <dprive@ietf.org>; Tue, 11 May 2021 19:27:46 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FfzGQ6Jygz1Kk; Wed, 12 May 2021 04:27:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1620786462; bh=mj+oByxdG8Rj7mzmOVy5vlnePV5k6BjU6sULGSBKrvk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Jwu9CepEKopNoPhyp55/wXh8W1fekp3uM4GlmfVveUzQgZzHlJm93moeGipoJRL2Q T3AKsIsnn94GBdCceC/m5BPeIBmiKXKJk9G7lEg4VU3cnYORBVl+FDC3I+GVZDtyZn N4snksCgE8JYJJfjLQ/yO1/3fbCro0ipyajz5ToY=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FSCI6vlecgMK; Wed, 12 May 2021 04:27:41 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 12 May 2021 04:27:41 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id A26B157D0D; Tue, 11 May 2021 22:27:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9F75D57D0C; Tue, 11 May 2021 22:27:40 -0400 (EDT)
Date: Tue, 11 May 2021 22:27:40 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Eric Rescorla <ekr@rtfm.com>
cc: dprive@ietf.org
In-Reply-To: <CABcZeBOxusptu958tp6uQBTDecpk+EWaMZOvtTx96appkeoOgw@mail.gmail.com>
Message-ID: <cba9115c-c18-5086-a29-ec6bca5ec8c@nohats.ca>
References: <CABcZeBOKv66-SOqYZDG0=v=X6tQOAobz4DZx9sD3-ppTE+wGOg@mail.gmail.com> <b8e6cf4e-58d5-f173-f7cc-c41ca626c@nohats.ca> <CABcZeBOxusptu958tp6uQBTDecpk+EWaMZOvtTx96appkeoOgw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/JeHFM2KWfiFPpeqLG-dQm03x9Tc>
Subject: Re: [dns-privacy] Next steps for draft-rescorla-dprive-adox
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: Wed, 12 May 2021 02:27:52 -0000

On Tue, 11 May 2021, Eric Rescorla wrote:

> I'd like to make sure I understand your point. Is it simply that this information should
> be encoded in NS or DS? If so, I don't particularly object to that. I don't have a strong
> opinion about how this signal is spelled.

DS records and glue (NS,A,AAAA) are the only child records served by the parent.

So .ca will publish (redundancy removed for readability):

nohats.ca.		86400	IN	NS	ns0.nohats.ca.
ns0.nohats.ca.		86400	IN	A	193.110.157.102
ns0.nohats.ca.		86400	IN	AAAA	2a03:6000:1004:1::102
nohats.ca.		21599	IN	DS	1321 8 2 B7890A1E7B4CE1D671795D5FD46A71F229C58025587BEC4EEB70CCDA 9233011C
nohats.ca.		21599	IN	RRSIG	DS 8 2 86400 20210516110615 20210509013859 43854 ca. <blob>


If you define a new RRtype, say FOO, and .ca will add:

nohats.ca.              86400   IN      FOO      <data>

Then all DNS software will reject this record as out-of-zone data. It
will just never serve this record until you made software modifications.

That means changing all DNS authoritative servers on the planet.

Then you also need to DNSSEC sign this record or treat is as glue. That
behaviour/expectation has to be added to all DNS recursive/validating
software on the planet.

And then you need to update the mechanism how Registries and Registries
update this FOO record in the parent zone.

You won't be able to rely on these updated for many years to come.

Paul