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

Brian Dickson <> Thu, 13 May 2021 02:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A30C3A13E0 for <>; Wed, 12 May 2021 19:14:08 -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 bse-FLlW-p1c for <>; Wed, 12 May 2021 19:14:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AC833A13DA for <>; Wed, 12 May 2021 19:14:03 -0700 (PDT)
Received: by with SMTP id a2so15517019lfc.9 for <>; Wed, 12 May 2021 19:14:03 -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=50Q80G822LdyBQ65mRqdnX3UFzZAJeqXe0WNUFQttQA=; b=quYaqWeegWEGG3e23/rd4ZNOWPjQGMzdgW6SBeMJGq6ZmZXjK/4dvlvKILPxtVRAcW hWJkhGt30QS6M3eJu3X1oHDa828FGIcasxn/xKy1rP4jHnbZO6tPcNjZh/AiNY9pKcZ2 kfSKyT6VFZLMg1ATCeR/dpC7rvlDIcxhQBy+aCNqHj7yzNeNnKLVu9DEJKWRt02WkFGA XDx3tgU3EWDHKquGGyNhPh6/L0G73A+1feZcg9PkipqnMHvbVpTC36bh3A+OPPfhZUtO wrM/SEfm/5bQP/TT6HwcdSL6Hr9eXnPweye1PQGGPcCfPb9Cr0HLZ9Qh/ck6XrBGMvgO EKGg==
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=50Q80G822LdyBQ65mRqdnX3UFzZAJeqXe0WNUFQttQA=; b=Ytje5IxcnT1eGlrd7QzGvXLFNcKJZ968ewu0/MhAexQk5pGeyVj4UbF0xl/+hGgkpN EB+nEO7Uxo5lFKmgS9YFU9dD+rwJRV6g94pZ3ShTan2M7RUzmQ1uRKWpcvnbt2upjzdM qw1zCjhI7YCu1RINkYQ2oFE+M6x7LaYF9lT3c8VHWMm42EfsF5XwNonoSYf65AdFJOJx nJqomRXziG6IWZU9HAwRoNh4I1xq2cTLTvgyCU8xb9x7p+A2JKH3FLzsb3s26kexLKdD HHrN0WcLlkPg7vpD6eviXL447rQYo9Cl52aOZ6U14+Cz0xPKgVA6X+Va/hygcv8lAM6b 0Yuw==
X-Gm-Message-State: AOAM530Pnouqj6o5w1G3pnBaq7bLwivQumNLNNdmOCQIq5wOnCEgbsjA GNIhRcSdogEIXSr44aUIu/OiTBR9h9FeRdMEtN/rAACMdzQzGA==
X-Google-Smtp-Source: ABdhPJyuiGwWs2r5abA5GGQlp3k243opbVSdQp0cPfTzS7uduwV7Fj8LocGWhzpt0aH2/4eR2JB9T2sz5iLHkqm4OCs=
X-Received: by 2002:a05:6512:3f04:: with SMTP id y4mr27836240lfa.458.1620872040108; Wed, 12 May 2021 19:14:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 12 May 2021 19:13:48 -0700
Message-ID: <>
To: Eric Orth <>
Cc: John Levine <>, dnsop <>, Joe Abley <>
Content-Type: multipart/alternative; boundary="0000000000002d577105c22caef5"
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: Thu, 13 May 2021 02:14:08 -0000

On Wed, May 12, 2021 at 3:32 PM Eric Orth <ericorth=> wrote:

> On Wed, May 12, 2021 at 6:21 PM John Levine <> wrote:
>> It appears that Joe Abley  <> said:
>> >> Agreed that there is no such issue with either wire format if all
>> parties in the ecosystem are bug-free and RFC-compliant.
>> >
>> >Do you know of an example of a DNS authoritative or recursive server
>> that does return truncated RRSets in the ANSWER section?
> Honestly, those aren't the caches I'm worried about.  What worries me the
> most is the caching layers between the recursive and the client (e.g.
> forwarders and various libraries on the enduser machine, including caching
> in various clients themselves).  While I don't have any examples in mind
> specifically of these layers messing up RRSet cohesion, there are many
> examples of various bugs in these layers (e.g. see all the recent
> "name:wreck" fun), and there are a million implementations (hyperbolic) to
> worry about.
> And given that these layers are typically past the last DNSSEC validation,
> there is not a lot here to historically depend on fully correct behavior.
> Who would have noticed if some bug in a client means that every once in a
> while it's only attempting connections on 4 out of the 5 addresses it's
> supposed to have received?
> My overall point is that I'm strongly in favor of the wire format with
> less potential points of failure in correctly transmitting and stitching
> together the individual components of endpoint information that really need
> to stay cohesive.

 Unless you have a guarantee that the client can always obtain the full and
complete RRset from the resolver in non-attack situations, you already have
a major problem (i.e. even assuming each SVCB plus SvcParameters is a
single RR, but where more than one SVCB are published in an RRset).

There are multiple problems, if you cannot guarantee the RRset being
delivered to the client:

   1. If an RRset contains both an AliasMode and a ServiceMode record, the
   client MUST ignore all ServiceMode records (per 2.4.1 of the draft). If the
   complete RRset is not returned, the client cannot be guaranteed to pick the
   right record.
   2. If an RRset contains multiple ServiceMode records, the client SHOULD
   start making connection attempts with the highest priority record. If the
   complete RRset is not returned, the client cannot be guaranteed to pick the
   right record(s) in the right order. Note that if the client API to DNS only
   returns a single RR from an RRset, this will not in any way depend on the
   SvcPriority value, as that is an opaque value within the randomly-ordered

So, either the client is guaranteed to get all the RRset members (and the
draft is a viable approach to the intended goal), or it isn't (and it
If the guarantee is present and applicable to the existing parts of the
draft, it also absolutely guarantees the necessary preconditions for
combining the key/value elements if they are split into different RRs in
the RRset (rather than one combined entity).

The entire path from resolver to client has to work for the existing draft
to function as intended.
And if it does, it is mathematically impossible for the split key/value
mechanism to not also work.

It is demonstrably more likely that a complex parser will have problems,
than something that combines data from simple RRs in simple RRsets will
have problems.
(The history of SMTP is, I think, a good poster child for this, with MX, A,
AAAA, plus DNSSEC and TLSA support in the clients, which are email
transport things, not merely DNS things.)