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

Tim Wicinski <> Thu, 13 May 2021 01:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 913023A1EFD for <>; Wed, 12 May 2021 18:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 KOPeDknG2gzk for <>; Wed, 12 May 2021 18:16:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B7693A1F06 for <>; Wed, 12 May 2021 18:16:18 -0700 (PDT)
Received: by with SMTP id j10so36336841lfb.12 for <>; Wed, 12 May 2021 18:16:18 -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=/MQB4JvDlnBjeM3iz7y4EptKQmdMkk+7lkxzt2cVVX8=; b=k0KZWu4XC9KQIY/kAW1VV/xe7AKzy3cEwr4M5vBx6tcqRFs8vI3r4Ofcpe01AI23It igoe4VpZKyYZ0JNcDDFmdJ9880qAk7XAP31oP/vtr8WQgO/K+qDiDd9eYaD9uxyZ2uQc lSQFa+esD2k0Kfz+fK34I54eZNAaCmE4rO0KZkkBFPQhHXgs/qMz0wA8buLYcSkrS8ig yCpP2J4xvFcauq8uNnFuHXrlSin4YJpVGnMnspSpJmKGG1SJIchb/J8sCq9PJj2PPrvP 10TcwBihvXeGgk55cF2XKpo5396l8d9czklAsO463y44hz0tRzKLQMMNCvZD9Wd4h9xN XVwg==
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=/MQB4JvDlnBjeM3iz7y4EptKQmdMkk+7lkxzt2cVVX8=; b=UtjISzU9MAZKRmPvLx39S+WCMlln5d0NYzBE6Nss1wKGifEklHjZ8NSvR2IoHzkgzy dpq9GHkCbTiXrV1nFccPi5fXtN0IQaAAqK0QHjY12GG41o6JqmjmRQKm1UuK2WEEfSfU ab+bKEb1rE64Jse3BlaPPD2Y/yZcNdRzJf7ENf6ALJ0Bjt1/6Jz4AOw7TP5wSpJWT3CL aQVxX9GPrcjZQWUqaBp6sA4B9KXGVaC3pjqDnlrAH8OmLh60bcCou6VMWDc/1YRbrZjs GFNvbsLikl9ubJuaBqKAnWCxVM/fYZODu2GTpLlEZoqPo1zSuLeGq01bU0Yh4M9h7jWe RCXw==
X-Gm-Message-State: AOAM533AcZeOTxgQ84OpL7+PHDVSuhK/ujDnyoVbhQqZPgw+dZg45/bR FNvODBcnipKtQqFakPzYGeUcMh7MFowTpickPNo=
X-Google-Smtp-Source: ABdhPJzhxtdKDvYjUk/q+vqrl7XcGXaE8Zobs49tHQsd7eFL4iTaASIBbCx+3beBV3Ik/CPClgKNcigGWZWS3s/vVn4=
X-Received: by 2002:a19:7dc4:: with SMTP id y187mr27079510lfc.525.1620868574899; Wed, 12 May 2021 18:16:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tim Wicinski <>
Date: Wed, 12 May 2021 21:16:03 -0400
Message-ID: <>
To: Paul Wouters <>
Cc: Eric Rescorla <>,
Content-Type: multipart/alternative; boundary="000000000000a270b605c22bdf5c"
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: Thu, 13 May 2021 01:16:33 -0000

To Paul's point, this is the ICANN Base Registry Agreement listing the
permitted "TLD Zone Contents".

This is only for gTLDs that have signed this agreement.  The ccTLDs
generally have their own contracts which will vary.

This idea could or should work for all authoritative domains that are not


On Tue, May 11, 2021 at 9:37 PM Paul Wouters <> wrote:

> On Tue, 11 May 2021, Eric Rescorla wrote:
> > From my perspective, the primary open question is the wisdom of having
> > some kind of record in the parent domain.
> > While I understand that there are people who have reservations about
> > whether it will be practical to popuate the parent
> This is not about some people having reservations. As I explained
> before, you are talking about:
> - Updating DNS resolvers understand a new DS-like record on the 'wrong'
>    end of the zone cut (incompatible with RFC 3597)
> - Updating DNS auth server code to serve a new DS-like on the 'wrong'
>    end of the zone cut (incompatible with RFC 3597)
> - Update all the DNS servers run these new DNS resolvers
> - Adding a new EPP extension to transport the new record to the
>    Registrar
> - Adding a new EPP extension to transport the new record from the
>    Registrar to the Registry
> - Registrars updating their code (libraries and webgui)
> - Registries updating their code (libraries)
> - Updating ICANN contracts about allowed RR types
> - Writing CDS/CDNSKEY style auto-updating for this new record
> - Updating zone file verification tools to not barf on record being
>    out of bailiwick
> Last time, I recommended you talk to people at the REGEXT working
> group, Registries/Registrars and DNS hosters, our ICANN liaison or SSAC.
> Did you contact any of these people to ask about the feasability of
> your proposal?
> > 2. Is this proposal a plausible starting point for that?
> No it is not. If a TLD that falls under ICANN policues would suggest
> running software that supports this proposed record, it would surely
> trigger an RSTEP review, and wearing my ICANN RSTEP reviewer hat, I
> would strongly advise not reject the TLDs technical proposal.
> This has nothing to do with what I want. I _want_ this record or similar
> solution to work, but it just realistically cannot work. That is also why
> people (including me) who are normally very strict against overloading
> have suggested the only way to signal something at the parent is via
> overloading the NS or DS record in some way. And using DS is better
> because it is signed and can be verified at the child.
> Paul
> _______________________________________________
> dns-privacy mailing list