Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

Matthew Pounsett <matt@conundrum.com> Tue, 28 March 2023 12:50 UTC

Return-Path: <matt@conundrum.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FF0C14CF1F for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2023 05:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW_-CwU3nHzQ for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2023 05:50:55 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 47089C14CF0D for <dnsop@ietf.org>; Tue, 28 Mar 2023 05:50:52 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id cm5so2064573pfb.0 for <dnsop@ietf.org>; Tue, 28 Mar 2023 05:50:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20210112.gappssmtp.com; s=20210112; t=1680007852; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0x/ODXzVBKeWf+TQP5x64GiNJJKp8owHUxALpteyar0=; b=VI9xrL4+W8oKIgj9Ja77CHXaMP+EBVzjDYQ2H/NutMfN3Q6zbpEZW1UQC3bB7Fygwv fhBpniMx6OwmeKGok+NNLQQV1MJ8zkfAWc7xkRWq7BnqULvCVlYaLL7BYO/KNVXBSRhj +tyCGexAdBFe/JVQ2okcJLv2MArMf5PDAo0pEIdZQkdovqy2s+iztJX9pqfo+XP3qlSG 3Pf8jLFkiXHleW2vJQuAeNRzvnjs8FYGhpx4YLJmJbX8DzQG/B6mv/Cx4j42PlTXgZEa XWOWVBJOKScPPyzpbGQkZ4E0RUk/5KbglfNLLKOWxQMlCBxmpYToUzHsZ2/76xsiBLIi wWWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680007852; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0x/ODXzVBKeWf+TQP5x64GiNJJKp8owHUxALpteyar0=; b=SEN1jkEZhFcPhDN7vFwheQ3AyK68qs+B8i3EOl3XgegdOtNqDaMIoJhsQs7YUYS2m5 Ya5p7aZdac6Xppx1EjPDxGXwGmnKr5K4evvDC2WI/YwfaxJ+P0y128+w+Yr0Xbgt44TY Cc94x87csh8LbeCNIIn0FYNx4wu1CGPkuJ7pYlMl0WaTvUFGEJLWoj5NaRJ4E++0zgDL Q9sG9EI37sky8CN2SmeoAL5ojib5Lyujxa2jiNjjmKbxRGaEPyWhvLnPo1mXoNi0hO2E 11egFoxQJCXABZ6yLWoeZFUNqMIAA3xtv7MK2XsX9zdRhR+yMSPmmAH7finAimSzXFqD nffw==
X-Gm-Message-State: AAQBX9eHuK2A3MTt5ylWIJ7K/J7ydLFCBNfxSH/H3vgj8w1gGOKgjZAK IUNotzM5NpVeEjwKvrIZ9piTSeicoRO2va1wkjzl2QNEv5qWlXCtR8I=
X-Google-Smtp-Source: AKy350ZbMFGNnW96yCDdnbDNAo2YYcdOfnhKtOhd39d2qZHGzi4k+KENREvWB5Y0t5Qj7a5i7JzyQop3PyVQRCryyLs=
X-Received: by 2002:a05:6a00:1488:b0:623:8a88:1bba with SMTP id v8-20020a056a00148800b006238a881bbamr8376709pfu.2.1680007851678; Tue, 28 Mar 2023 05:50:51 -0700 (PDT)
MIME-Version: 1.0
References: <166433321065.7033.7906557321120388211@ietfa.amsl.com> <a124badc-7723-904f-3716-6be2a121360@nohats.ca> <Y+7jR1ouKD6w8V49@straasha.imrryr.org> <Y/RXcLmPouKn5DJW@straasha.imrryr.org> <920A70B5-EF6F-463D-B62B-BC29C4C0210D@fl1ger.de> <CAHPuVdW-mA=M+zh1nvRKr12w5wnxG2+bL0Vbc52DwRykare+Ng@mail.gmail.com> <ZCHkFGDj0CrEx3o1@straasha.imrryr.org> <CAHPuVdUY+eUmeWw8x+yfbTSxr4aavzxtuEqKGEoB=gpVhLR1gg@mail.gmail.com> <9743fe5f-dc3b-1241-cd2d-96649939adf6@desec.io>
In-Reply-To: <9743fe5f-dc3b-1241-cd2d-96649939adf6@desec.io>
From: Matthew Pounsett <matt@conundrum.com>
Date: Tue, 28 Mar 2023 08:50:39 -0400
Message-ID: <CAAiTEH-7erdiQrxW1FXcy_zhWxsf60XhPp66yyfWnzhOKPDJmA@mail.gmail.com>
To: Peter Thomassen <peter@desec.io>
Cc: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="00000000000038332c05f7f54f57"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QKs6IH2c74b3ouLJqILWPpOs3bE>
Subject: Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2023 12:50:58 -0000

On Tue, Mar 28, 2023 at 8:24 AM Peter Thomassen <peter@desec.io> wrote:

>
>
> On 3/28/23 03:14, Shumon Huque wrote:
> > On Tue, Mar 28, 2023 at 3:45 AM Viktor Dukhovni <ietf-dane@dukhovni.org
> <mailto:ietf-dane@dukhovni.org>> wrote:
> >
> >     On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:
> >     Can we at least state that domains with cyclic dependencies are a bad
> >     idea, and may not be supported by all resolvers.  In other words,
> that
> >     the domain owner can't **rely** on the sibling glue recommended to be
> >     sent in this draft to save the day.
> >
> >     My strong preference is still to delete all reference in the draft to
> >     cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
> >     sibling glue primarily as a performance optimisation, and secondarily
> >     as a last resort when the nameserver IP addresses are wrong or gone
> >     from the authoritative zone (another bad practice).
> >
> >
> > Viktor - I've so far not seen many other people speak up in support of
> your
> > position. I suspect this is because this draft was discussed to death
> many
> > months ago during long discussion threads on the list, and there is
> likely
> > already rough consensus for the current content. Personally, I would be
> ok
> > with adding a statement that configurations involving cyclic dependencies
> > are not recommended, but others will likely have to also speak up in
> support
> > of this too.
>
> I support adding such a statement about cyclic dependencies.
>

As do I.


>
> In addition, I would support saying that data suggests that, while
> (non-cyclic) glue records may have a benefit in certain cases, they
> frequently are a source of harm (time-outs), and the trade-off remains
> unclear.
>

I would support this as well.

In my anecdotal experience as an operator, I routinely encounter mismatches
in sibling glue and child zone NS sets that appear to be due to the glue
being forgotten.  My assumption is that, because it's not necessary to
operate, when operators fail to update it they don't receive any kind of
signal that something is wrong.

Viktor's numbers are pretty clear data, though, so nobody should need my
anecdotes to be convinced.  While sibling glue may be a useful optimisation
in some cases, given how poorly maintained it is it seems to cause more
problems than it solves.