Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Joe Abley <> Mon, 10 May 2021 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DFCB3A2111 for <>; Mon, 10 May 2021 08:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GwQ6JURXdw0K for <>; Mon, 10 May 2021 08:35:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 487FC3A210E for <>; Mon, 10 May 2021 08:35:17 -0700 (PDT)
Received: by with SMTP id f8so8043414qth.6 for <>; Mon, 10 May 2021 08:35:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KOIYMLZgi+AxYYnuNpaU3U+MQxrtGbSqN6bhNX1VKz0=; b=DfAaAsKQ0O6pFXcoWMBVYpdG7s0UFBHOrLrd2FQVOXTq+s2iLY0Z8DqXjPBCmSZFji /7ORtz7Ysv58KAxUHqVKpUj7ZXvanSAOGSkJGzP0FEirf8HFnGnQtEjalKXpfpCi0fIo 6MS90rjuDQZi8dqHQmX792ol5a/951XOlNypc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KOIYMLZgi+AxYYnuNpaU3U+MQxrtGbSqN6bhNX1VKz0=; b=kpLLnOj+lT3eP308LBkyXo4UPGuqTfHRY96mpbXFqVrG/RPPXHb0g/NiKPRBPTgPc9 2BqjpbSHxID2/SIFE31cGiVF26jUqu5zbxJdlqGYAJSqRBNV9zmXHUv5ot2/8nOZTeb5 0NR8WPY2/ue7sxloB1PNhTXINoEcjKz3ENTW3ubbBtWuCzzqk5ye/fpm3HVoDzD7ykfs +dNoM45xZk85mN0dUbTVlKT8C23BJ4Brb+21tdR3x7z8HC4uClgbfxxqu/OdKKrERq2J HyUgpWKWQ3q7EFT1qIQJ193zfuVJwOe5pcAY9gQvftLNGyMN4ag8RZN6iclHiY98olCd 7mTA==
X-Gm-Message-State: AOAM531RcupmcAYjlxqwsIxZdRKDU3XDlj9uPgUzh24aaNWrIxdFhs7+ vhnG64PXGGnCW7w+GyYbdvOe9xK4BQH2GsvleXs=
X-Google-Smtp-Source: ABdhPJwV1jcuVEhfYtqXApsNH+xICcsKpykqDLVIlceEZ8/BYqPiQop4XFtiHFariNoqhIJhEshFlg==
X-Received: by 2002:ac8:720e:: with SMTP id a14mr10644483qtp.213.1620660915148; Mon, 10 May 2021 08:35:15 -0700 (PDT)
Received: from ([2607:f2c0:e784:c7:f88a:8f71:955b:ab3]) by with ESMTPSA id v10sm11713792qtf.39.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 May 2021 08:35:14 -0700 (PDT)
From: Joe Abley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DF84D8E0-5CF7-482C-8692-1C4BE4558EB7"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Mon, 10 May 2021 11:35:13 -0400
In-Reply-To: <>
To: Pieter Lexis <>
References: <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 May 2021 15:35:22 -0000

Hi Pieter,

On 10 May 2021, at 11:23, Pieter Lexis <> wrote:

> You then invite the following issues:
> Clients need to match the tuple (ownername + prio + target) and get all
> data from all matched rrsets, whereas now you get all that data in one
> piece of rdata.

Inviting that issue is also a potential benefit, but I agree that the implication exists. For example, the ability to publish sets of SvcParams with long TTLs ought to increase the probability of cache hits for that data and reduce SVCB response sizes.

> A client also can't figure out (if not doing DNSSEC valdiation
> themselves) if you have received all the SVC data for a certain name.

A client can't figure out without DNSSEC whether anything they have received is correct in, in general. So setting aside that more general authentication problem, I don't think it's correct to say that a client cannot tell whether they have received a complete RRSet in the answer section of a response. It's either there and complete or it's absent (and perhaps TC=1 if the reason for its absence is message truncation).

There should be no response possible in an implementation that adheres to the protocol in which a truncated RRSet appears in the answer section. If we're widening the net to implementations that don't follow the rules then I agree anything is possible.