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

Ben Schwartz <> Wed, 12 May 2021 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E67933A1804 for <>; Wed, 12 May 2021 15:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T8nYbqxEjweo for <>; Wed, 12 May 2021 15:56:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F81C3A1800 for <>; Wed, 12 May 2021 15:56:40 -0700 (PDT)
Received: by with SMTP id a4so25208609wrr.2 for <>; Wed, 12 May 2021 15:56:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K6ugA3D49fDo8c/IOpEK0GZ0uX4y5bRcS7lPed3/ZzE=; b=P2phSyxLxId/eiF75vP6RvmWIy6vYOUYi9KEQ9dlIBrwT/ugHtpW+gWHgsjN+ygKVS gU4A9hRXg3/dEsHEgmCb6bAISGzY5j/tUirFsSMeeJ8JjGo0M0WVgoqaWrWWrx2Lsr6k hKvqChAMIMs0KWgK1ywO2JgJ8ZsP6D+fjBLDZJWtwNnH6djq950hievHts4gYuuMju7h Ba1XVMeNvxsc3oDGMeUbHihDpYL0xDjpnhFKV5efY7jlkZieA7wQeGXnl4X+qEt9kkKF lkSpGT12SVCAZISMl6GJt78q80ZQoIsdUNdY5zKqviGrTI4VZqvUHcmfD4228CMKlgRY 2WgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K6ugA3D49fDo8c/IOpEK0GZ0uX4y5bRcS7lPed3/ZzE=; b=QddUZSaoGcurWWrP4Pyi0ge91jqW1xQnSpbk5sVfAwa8lcx0muTdvCJ+LK9RitseyJ 6hgzBfK9UP0fQifsLKzyXcMXEE3GQ0AvuVrmY96Isxon64VWLl7u0KLDI5/a82KcPmE2 AlNkX2F9zuKvnwdz75eR2zi3ZTZ4RORLOtNB3VbOa/Xpx/IENMOHIKA2qqRml6cg6cWK m9qiv0KKoNib6RM75Rgp9KSYDngBEFI+/YoMQOXBB63z9yaeTYLiseR4Rl+NBnS3HKVv 2MUlomiMY9btwsCo1rURbdmXNcmxy1ZiXVx50tGs3T9bJMR7KYAmDWhwx3z5yl+v7AVW zRRA==
X-Gm-Message-State: AOAM531wk8tOSetgh/a7gw8d0VROE8aO5dLxkirgsGMleri6ATWnMjtO 64XEGJsjXnJWXeb/n7agfsIIoJQ0aBxtvAcjllXlgg==
X-Google-Smtp-Source: ABdhPJzPUEzEjqcqi7l9ttiNuoIQMYwsHuB9tZEN9ypeBSbTgHg0FPHE18ES3jrGUtgGGzjS/yCYowAXWF2YTtRKfQo=
X-Received: by 2002:a5d:4a81:: with SMTP id o1mr13457981wrq.177.1620860196881; Wed, 12 May 2021 15:56:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Wed, 12 May 2021 15:56:25 -0700
Message-ID: <>
To: Paul Wouters <>
Cc: Eric Rescorla <>,
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000058ec4d05c229ec31"
Archived-At: <>
Subject: Re: [dns-privacy] Next steps for draft-rescorla-dprive-adox
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 May 2021 22:56:45 -0000

On Tue, May 11, 2021 at 7:28 PM Paul Wouters <> wrote:

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

I agree, but I still think this draft represents a good approach, and we
should adopt it.

In my view, the WG has been stuck trying to choose between principled
long-term solutions that will take many years to implement, and ugly hacks
that can be deployed quickly.  In fact, I think we should develop both.
This draft is the former, and if we adopt it, we can and should follow with
interim solutions that can "upgrade gracefully" over time.

Adopting this draft, even if we are far from implementation, is important.
To choose good intermediate steps, we first need to know what the endpoint
looks like.  For example, with this draft in place, we could define a flag
in the DS record meaning "use encrypted DNS like in ADoX", with resolvers
querying for the SVCB record in the child if it isn't provided as glue from
the parent.