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

Eric Orth <> Wed, 12 May 2021 22:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DED683A15F6 for <>; Wed, 12 May 2021 15:32:29 -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 k08J32zk5xNP for <>; Wed, 12 May 2021 15:32:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DD593A1925 for <>; Wed, 12 May 2021 15:25:05 -0700 (PDT)
Received: by with SMTP id i4so32638784ybe.2 for <>; Wed, 12 May 2021 15:25:05 -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=+xG1i3wCjf2pgSVVXKofzDvH7bCaOdnyfOQ3m3fYl/0=; b=iKcBGnnIkf8se62Xtt5cr89TgromOdK2/UKDchS5/Vyvk9jpZrALvJUcNf7ZmvDhcE lqsv2Giyj8RYdc9jxdxuHtUzkNQ66CMKZOaDdtQkjYYiSgc/uRSYx7phoe1NxbzzEg+U C0r1gmPBlGtOTvXBQGsVIuv8gLFKAP3+gqFTGAn8Im22VZ872MGDb/h7twWwCaneY6CP 9DzgP7iB7MWLddszGD7VALHcUkhTHWhxjlcEf8eiQF6eKwmBKRxjkLb5R6JuLzQtuD4m 2VqUGjgCZP39y8V5JI9k4afoZ1o117/HHmUl+w0SKg114HUdncGwizaTJJrRNAhV3s2c 5tbg==
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=+xG1i3wCjf2pgSVVXKofzDvH7bCaOdnyfOQ3m3fYl/0=; b=DTR5OcOJpGIYaBMse2AGSIJsEwavV3oR8+yUP6cW39dOgZkVESkxKxkBVaPYVhClqZ j45GXmZuFjijklwNCaiS6p8ObsqXlPcKqP0EKvv7WjQ5oqMWI8iskiahJuG55iEj1Ce6 mo+I4X6/M0WeliFXlyGN8hB9yxNWU9BZDR232+EpkF6H98OEotREt4dy8gI3839m+qh/ Tx2jy/rB0hTDE2yFpogWgmc856+yRxrWTJRWpUG7LiCv4kpr/LZN738S6LL/1McABru9 VCbIWPYqU73ZQKurHpa10tzkTIjMfb1rZ6zRV1Pl8ouBKu6R6eCHWy+awzQHBs9J55zb YxDQ==
X-Gm-Message-State: AOAM533azNEJ+/pTyTsQh+MPMUhBdygtT5RCpIw+mz4AKpCNDkuXFq6d QeoiDiIiddPmE446dTgAYLuz3xYLumFGu7hKCEQ5dA==
X-Google-Smtp-Source: ABdhPJxje7pX9mh3DUVAraMkjTiu8dwby6FqKvP3cXU578dsZcYJ7GNQcUCf2xcBDD78aNVyb2uZ7R1haQcJ6rXny9M=
X-Received: by 2002:a25:fc04:: with SMTP id v4mr53212258ybd.196.1620858303455; Wed, 12 May 2021 15:25:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <20210512213903.D5F1F7AA827@ary.qy>
In-Reply-To: <20210512213903.D5F1F7AA827@ary.qy>
From: Eric Orth <>
Date: Wed, 12 May 2021 18:24:51 -0400
Message-ID: <>
To: John Levine <>
Cc: dnsop <>,
Content-Type: multipart/alternative; boundary="00000000000069621c05c2297b25"
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: Wed, 12 May 2021 22:32:30 -0000

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.

> A lot return truncated glue in the ADDITIONAL section.  Are we sure that
> wouldn't be an issue with SVCB?
> I honestly don't know.

Current draft encourages recursives to put followup query results in
Additional.  So maybe truncated glue isn't precisely an issue, but it's
certainly an issue if similar logic leads to incomplete Additional RRSets
reaching the client.

> djbdns would return random subsets of A records if you had a lot of them,
> as a kind of poor man's load
> balancing, but I don't know of anyone who still uses it.
> R's,
> John
> _______________________________________________
> DNSOP mailing list