Re: [Add] ddr - SPKI question and comment on SNI section

Ben Schwartz <> Fri, 10 June 2022 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 332EEC13A2B8 for <>; Fri, 10 Jun 2022 12:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.61
X-Spam-Status: No, score=-17.61 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, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uMwyg0U_gXE5 for <>; Fri, 10 Jun 2022 12:27:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 4E0B9C13A2B7 for <>; Fri, 10 Jun 2022 12:27:19 -0700 (PDT)
Received: by with SMTP id x187so216126vsb.0 for <>; Fri, 10 Jun 2022 12:27:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2RaG/HQQdUMSgj0WIR4hqnQBe3F7hb/d7U3henQBE9g=; b=Db/V5wceRVGARrknxuIM00RKb3GxKcftTiNCGl6hDU+j9z8eqxzMH41QdRZ9hjjbd8 +WqmgrPkEhc1x1Mm+S3F4zH0blcZpM2i+cTMBjLEYGzYvh2AY6kCfLOvtfBjrtM4ejzw FGaieH78Xx+nBNzkwl/hpLjPMG8OOaH2pydHV6m81KHKVJbr/8BcSOrczypJzkMqSoQx FzRRIpFmqX9ZOXIoMNzGo9GOcJXVLZh3vgp69yPcdEprLZt/s3FXwOllbTpU3QHqZ1AX 1udGnpQosD4k7sUbpjyAb4mjv+RKrMRSk7heXlnVg2tEYD853Yk3zgEehHixFN+MGIMH BuVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2RaG/HQQdUMSgj0WIR4hqnQBe3F7hb/d7U3henQBE9g=; b=jy7HM7YfuuP9bJDKIHkW2Dr6x6yZk27sQUx4SbIEOKYMgIL5pvkLxV1O/V3XyP9CtN EawdjUSpIwIWvpTxMMYXnh0w5SMv49OOLD5l9TW3Yrlaim7UNzjiM3+Blh4cQ6hF/Som 7T/o3qUdtUshTEBy7jh4AfKeanP7o5znV/A3WrvtRXMe55OU1i4bjNFGZzbZ54T/v86a uwmmQJv7KGj3NtPN3SbjdDNjZRxwEBSqUVurOiiTAAH6UZzyuDF4zOrqJxmEq4LzIZZ8 wAAV+aIjz+wLBYWGkpVLvQ/dx6RF0Nn3+m/ptsc0IplrNRymRn+w1NmIylGr5IZqjto0 h0ZA==
X-Gm-Message-State: AOAM533SCDRNYBkB36XHmp/voVk8/M2jFI7hqRdQ2/H0CBixWaC4dRaJ 54Fyh0kvBT+v/Vu7beAuavkWpnxzWgUj/3aohoAHUdXCLeI=
X-Google-Smtp-Source: ABdhPJyLlr2RNmzIQo6eqn4g4muo/aAv0uvyd0/kuMVeDGrALVdZYiyWrGH6d8ub3FcHGDWwGiIi9cayyyszuAJzxfE=
X-Received: by 2002:a67:df10:0:b0:32d:ba4:8f73 with SMTP id s16-20020a67df10000000b0032d0ba48f73mr48445499vsk.74.1654889237814; Fri, 10 Jun 2022 12:27:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Fri, 10 Jun 2022 15:27:06 -0400
Message-ID: <>
To: Tommy Pauly <>
Cc: Daniel Migault <>, ADD Mailing list <>
Content-Type: multipart/alternative; boundary="0000000000002a061b05e11ced73"
Archived-At: <>
Subject: Re: [Add] ddr - SPKI question and comment on SNI section
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications Doing DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jun 2022 19:27:20 -0000

Focusing on one interesting point...

On Fri, Jun 10, 2022 at 2:51 PM Tommy Pauly <tpauly=> wrote:

> Discovery in DDR, in either method, assumes you are starting with *some* DNS
> configuration that you are willing to use. This is unencrypted or encrypted
> — that doesn’t matter. You can certainly send DDR queries over an encrypted
> resolver, but those aren’t about validating that you can use that encrypted
> resolver — you should only send those if you already trust that encrypted
> resolver.

DDR is very clear about what to do if your initial resolver is identified
by an IP address (Section 4) or a hostname (Section 5).  I'm not sure what
DDR would mean, though, if your initial resolver is identified by a DoH URI
template.  I think we might want to declare that DDR does not support that