IETF Logo Mail Archive

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

Eric Orth <ericorth@google.com> Tue, 05 January 2021 22:29 UTC

Return-Path: <ericorth@google.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 6C7923A0A2C for <dnsop@ietfa.amsl.com>; Tue, 5 Jan 2021 14:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.971
X-Spam-Level:
X-Spam-Status: No, score=-17.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, 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, RCVD_IN_DNSWL_NONE=-0.0001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oWY7x1glrqF for <dnsop@ietfa.amsl.com>; Tue, 5 Jan 2021 14:29:20 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AA53A0A26 for <dnsop@ietf.org>; Tue, 5 Jan 2021 14:29:20 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id o19so2275964lfo.1 for <dnsop@ietf.org>; Tue, 05 Jan 2021 14:29:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IeBSCDi5YOyTtABEZAyJc5ee9aW6c7W3ckUPTyiMxBI=; b=G3wQ5gM47gMr1Bbs7sXVDfmTV7gGlf+BqOtFWriPRCvcRzfgRMn7MsBPqG7FWFdMAg 4oLxASeEuQn5IUAOcRtqOh4SN4w4xP5z8eMmg9Ct/PR138ITWQ6odOoG7aGYd9V325qc Zscj2BC7sPhLs3hFUs82gIfUFW9T5bAcovIwFuK3+GYD5/MRWHX0ES9SXkxlnVEVbK7J IGlyg96ReSAP/cLcv8f10Hf9HhVsfriAq/pXjsnHDHrgoEp9TVzLOckcrdWlnNEXCT5m 4tbiH990zRr+McSwdzcc0X7ofpdWJ7Z1pw9rO0BImWmOWD0ke8giivEkngaYP4uvR2MW Hf4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IeBSCDi5YOyTtABEZAyJc5ee9aW6c7W3ckUPTyiMxBI=; b=jlxcUkJEzdw0BPTCXF5tyxD3QNVYAM/yiY2NFPzsk4Vgyqo6Haxhrtxylyt9a8dJlX hrt5Tqrij1itGb6vglmQhLT6WeTx0FJt/X0AUVg+0aZbDAaJvZNiTYzx+5qq+a2qFeMU H1j/NsJxIdwiqkEhiOEyVUViGJEvG1OztzUsBM6K7opYsq5okb9Wxfcj7PDjf5uhMhk+ jIPwKxKLxc57UBWI8hgj4P+4n1cZ2P/5YT6ifjDZtJhsr6JMpNJAxVLzs04wQYn/+uQ/ a3Y0rWU53R6/ZcYmh+6fa6vfOfQmA3jKpHnKzEJJZsk+hjKjUWygcsQgSeNXS4UkDNAR wCJQ==
X-Gm-Message-State: AOAM530RmWa2adO5Cm6IVFUnAM8OSoFVpn/t0PNV6wCodFGghkXuiWvE Dk8FGEuFiMmkUrVpdH/GncHUGQPqqbdW/opCwjE+7Q==
X-Google-Smtp-Source: ABdhPJwHRymYIA8GdnXVIuNt3+jsGPaQQzKOiz3qs9gabviLqMCqoc7ADhsoIn9mIxNYkrN6Azw6G7BBkbp3u9ChpEA=
X-Received: by 2002:a2e:9f53:: with SMTP id v19mr711315ljk.109.1609885757722; Tue, 05 Jan 2021 14:29:17 -0800 (PST)
MIME-Version: 1.0
References: <160435342340.5690.11246183519764836508@ietfa.amsl.com> <CAHbrMsCfxhv_fiSMuZNb+Rx=p_oa-Z682sAj8D4y7YkAf0=Lgg@mail.gmail.com> <500fe764-612b-a7d6-3d2c-efbf02d1b75c@nic.cz> <CAHbrMsDbYZ=JUGN8Cgy9Dhotzd=7Tg5iX6UyNBtEaLP-F6fF8g@mail.gmail.com> <b5334883-fed3-ce75-0ea2-faedd81a7e1b@redbarn.org> <CAHbrMsCMtr2cppFK3R_Z0Zu0GPyWHLGuByvadpL+TKx8hLm30g@mail.gmail.com>
In-Reply-To: <CAHbrMsCMtr2cppFK3R_Z0Zu0GPyWHLGuByvadpL+TKx8hLm30g@mail.gmail.com>
From: Eric Orth <ericorth@google.com>
Date: Tue, 05 Jan 2021 17:29:07 -0500
Message-ID: <CAMOjQcHtpTabvHV3pqRUgtdUOCsUgzOQWv_Zkj-BTwWxvVnjcw@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>, "libor.peltan" <libor.peltan@nic.cz>
Content-Type: multipart/alternative; boundary="000000000000b898b905b82ebcd7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NQzrGgmM-u8j49otEQsCHI9wYtQ>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 05 Jan 2021 22:29:22 -0000

Besides future-proofing for potential changes, I think the current rule
keeps us more flexible for handling obscure cornercases.  If there's any
reasonable chance that some obscure usecase in the future might make it
difficult for an authoritative to ensure only one alias is in place, it
seems to me better for the only-one-alias rule to stay a SHOULD-level rule
and keep the prescribed behavior for clients to reasonably handle it if
broken.

I wouldn't want to change to completely enforcing only-one-alias unless the
authoritative implementers are confident that they will always be able to
absolutely ensure that they are compliant.

On Tue, Jan 5, 2021 at 5:26 PM Ben Schwartz <bemasc=
40google.com@dmarc.ietf.org> wrote:

> On Tue, Jan 5, 2021 at 5:12 PM Paul Vixie <paul@redbarn.org> wrote:
>
>> a small matter.
>>
>> Ben Schwartz wrote on 2021-01-05 09:42:
>> >
>> >
>> > On Wed, Dec 30, 2020 at 4:39 AM libor.peltan <libor.peltan@nic.cz
>> > <mailto:libor.peltan@nic.cz>> wrote:
>> >
>> >     Hi Ben, all,
>> >     i'd like to ask for some clarification of expected Authoritative
>> >     server behaviour around Alias SVCB records:
>> >
>> >     1) when there are multiple Alias SVCB records for an owner name,
>> >
>> > As Section 2.4.2 says "SVCB RRSets SHOULD only have a single resource
>> > record in AliasMode".  So this "should" not happen.
>>
>> can you specify that if it does happen, the client behaviour should be
>> the same as if there are no matching records? otherwise clients will
>> have degrees of freedom, which i think would not end well.
>>
>
> The current draft says "If multiple are present, clients or recursive
> resolvers SHOULD pick one at random.".   I like that this leaves us the
> possibility of relaxing the single-Alias-RR rule in the future, if we find
> a use case for it.  Do you think this is not a suitable recommendation?
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

v2.23.0 | Report a Bug | By Email