Re: [dnssd] Progressing with multi-qtypes

Ted Lemon <mellon@fugue.com> Mon, 29 April 2024 22:27 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EB9C15107A for <dnssd@ietfa.amsl.com>; Mon, 29 Apr 2024 15:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.895
X-Spam-Level:
X-Spam-Status: No, score=-6.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.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 F0XbKCPXEQjt for <dnssd@ietfa.amsl.com>; Mon, 29 Apr 2024 15:27:00 -0700 (PDT)
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 37210C151071 for <dnssd@ietf.org>; Mon, 29 Apr 2024 15:27:00 -0700 (PDT)
Received: by mail-qv1-xf30.google.com with SMTP id 6a1803df08f44-6a073f10e8eso24005266d6.2 for <dnssd@ietf.org>; Mon, 29 Apr 2024 15:27:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1714429619; x=1715034419; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=M7+1c51nZ4GFDRrjuf1JubP6c+9Oj/9t3V54H3Do+wU=; b=sNfi/R+xOs3AhCDEUA2W0ZQovmba3dA6gLk/hI9uP9NiMIlJM2dVV86+5NubSCnbeN BLJe6lU0APcga1GsJKnFEge2Q+tiCG4WB2bReLP0+eI4F1CToS8Yil5qJn8vAT69c9Au w1CeBdYKCt5iu8mk+nF+VypENWT15CBOOEI/suf1M4xYfLp71R9XPSuOUfJ93yT6WiIV iu8xiS5SIn7z41TL7PU2skHmCImvFoIPC+CT/L5plPs/z1ZCMjEhb/ByPMyLZIpwnEsg 530zNW/lVqYhPGylldgxIWpE9KpIz5cLAjRtU+uwHL1amvO/xJ+PfQSr010v4UOUcfBL WMqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714429619; x=1715034419; 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=M7+1c51nZ4GFDRrjuf1JubP6c+9Oj/9t3V54H3Do+wU=; b=Msm23nW1+rsFO2Tse8evXpICtr+HvUfI6Plckr1cEfm2Qi/UcUxMPL7G6sT42LrXpj E4Xp3nPc31WFT8e+gCta/FjAfxqS7+zhgQ1uoYl+X2f0Q5TqsOyJiWy3TR+omqbc+cnT tcaar3sNeqjRUldxMJu9K0XPy2q9Giedk5kfRdeGVOwJnQDm2V3IePb+Pd/kjBoqzFF5 6L/KqTGHxw2eGrmxkSEMH8NHsPv6P/QepE8XeT5UpP0A9APsXOTzMtckTXdPPoYh55Yy ztP7LjYSpYcku8+Ohiv4ErOa/+ZsQe/K3bEywD7SlUsbUnMrqF74KYjBCNNxXWEnKb3d lO1Q==
X-Forwarded-Encrypted: i=1; AJvYcCUUUyAEy8ZvOigB8z4+sfAUDBdQB/GkWscy4EsoTTNvQeNfsNwNokE2IzNwK0rZdDjsHVypxJN2dqJdeKGYCg==
X-Gm-Message-State: AOJu0YwIerdh1WeqTX8jCeo8TwJcZxf+0dporgpBVyFI3zFb/0py2FBi msRWL+c+l8JlpSehLbpP9icAAxPf943TY4X8vNnuHLzaCITOtXMDnIm2a+JW5hJnm8Htozl3Y3R HZAF8NClRhxOReNVaX7KW4M+pE7ecvm17Kki0oQ==
X-Google-Smtp-Source: AGHT+IEm0ZHS7T5aIAcp0pxSXPyBAPECvEjvOiiMiJw3LaMonUG6wrPsUdYcFcYehCDZnx9KfjGrBVGsB7YcAUn8PHY=
X-Received: by 2002:a05:6214:d08:b0:6a0:67ae:784 with SMTP id 8-20020a0562140d0800b006a067ae0784mr629115qvh.65.1714429618865; Mon, 29 Apr 2024 15:26:58 -0700 (PDT)
MIME-Version: 1.0
References: <39876154-aea3-44ca-9250-6ab0d78e1ec1@bellis.me.uk> <CAPt1N1mcEqz5W2c8DgA+JQ-gk6=fGfHfHRvHQKShBC0VG1LiAg@mail.gmail.com> <CAPDSy+6E33e2E3G3A4y9QFNAaLH--Wg3r0b1X2U2NSczmWT6eg@mail.gmail.com> <DU0P190MB197899449A62158B2816C0BFFD1B2@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <DU0P190MB197899449A62158B2816C0BFFD1B2@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 29 Apr 2024 18:26:47 -0400
Message-ID: <CAPt1N1mu0_4fvFoL7tHExPxeODh-dGeaOZJSOMqjPqwchGmFYA@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, Ray Bellis <ray@bellis.me.uk>, dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006ce42d061743c09c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/7FqVbSc81POGlyLo0a7f5LSzepI>
Subject: Re: [dnssd] Progressing with multi-qtypes
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2024 22:27:01 -0000

I suppose the reason for the MUsT is that we want a recursive resolver to
actually try to fetch all the requested records.  But if the auth server
doesn’t support multi-qtype, that might mean a lot of queries.  Was that
the motive for the limit?

Op ma 29 apr 2024 om 16:40 schreef Esko Dijk <esko.dijk@iotconsultancy.nl>

> Agree with the proposed changes.
>
>
>
> About David’s comment:
>
>
>
> > the server is allowed to only handle some of them if it is resource
> constrained
>
>
>
> I see the point. But the present draft also has the requirement “MUST
> attempt to return all specified RR types except where that would result in
> truncation”. This seems more strict than the “SHOULD” requirement that is
> quoted.
>
> If the intention is that a “MUST attempt” is at equal level to a “SHOULD”,
> then it’s compatible, but it’s too fuzzy for my taste. So: can be clarified
> in whatever way we intended this to be.
>
>
>
> Considering the situation of a resource constrained server that only has a
> few RR types for a given (query) name – there may be no need for this
> server to ignore any of the QTYPES in the request.
>
> Suppose that for example the client asks for 300 QTYPES, really a lot, but
> the server stores only 4 RR types for the name. In that case the server can
> just keep iterating over the 300 QTYPES in the request and only add the 4
> records that it recognizes by type. Its response Multi-QTYPE option would
> be small, and no resources are spent on the server side apart from storing
> the request packet which I assume it can do anyway (otherwise it wouldn’t
> have received the packet in the first place.)
>
> So the only resource spent here by the server is some iteration and
> comparison time in memory, which should be really fast on any platform
> nowadays. No extra memory allocation is needed.
>
>
>
> If the server is resource constrained and also stores many different RR
> types per name, then it’s another story, but in this case it would be
> rather unlikely to have this hosted on a resource constrained server I
> think.  But even so, such a server could still perform the truncation as
> already described in the current -00 draft. (when it’s not able to complete
> the “SHOULD” or “MUST attempt” part discussed above.)
>
>
>
> So what I’m trying to say with many words is that if we remove QTCOUNT, no
> special provisions for a “resource constrained server” are needed in
> addition to what we already have in -00 – only some clarification or
> language harmonization of this SHOULD-behavior is needed.
>
>
>
> Esko
>
>
>
> *From:* dnssd <dnssd-bounces@ietf.org> *On Behalf Of *David Schinazi
> *Sent:* Monday, April 29, 2024 18:59
> *To:* Ted Lemon <mellon@fugue.com>
> *Cc:* Ray Bellis <ray@bellis.me.uk>; dnssd <dnssd@ietf.org>
> *Subject:* Re: [dnssd] Progressing with multi-qtypes
>
>
>
> [ Speaking as individual contributor ]
>
>
>
> +1 to removing the QTD bit in favor of two option codes
>
>
>
> +1 to removing the type number limit entirely. Since the server handling
> of these is a SHOULD, the server is allowed to only handle some of them if
> it is resource constrained. We already have the server send the list of
> types it handled in the response option, so we could just say that the
> server MAY ignore some of the requested types, but in that case it MUST NOT
> include them in the response options?
>
>
>
> David
>
>
>
> On Mon, Apr 29, 2024 at 6:21 AM Ted Lemon <mellon@fugue.com> wrote:
>
> I think I may have already argued for some of these points, but I think I
> was a bystander for the multi-option versus QTD question. I do agree with
> the approach you've stated—just burn two option codes. We have plenty. I'm
> sure someone will curse our memory 2000 years from now, but how else will
> we be remembered if we don't do this?
>
>
>
> I may have been one of the people who argued for getting rid of QTCOUNT,
> and I still think that's right—it's redundant, and if we send it, we have
> to validate it. That seems like needless complexity.
>
>
>
> As for the limit on the number of qtypes, I also don't see the need for
> that. There will no doubt be practical limits; the most likely of these is
> simply that there aren't actually that many rrtypes that will likely be
> represented on any given name. So I'm not sure what an explicit limit here
> accomplishes. At the very least we should articulate a reason for the limit
> if we impose one.
>
>
>
> On Mon, Apr 29, 2024 at 6:17 AM Ray Bellis <ray@bellis.me.uk> wrote:
>
> With apologies for the delay (caused by other travel since the Brisbane
> meeting) the proposal during the session there was to:
>
> - remove the QTD bit and use a pair of EDNS option codes instead
>    (one for queries, and another for responses).
>
> - remove the QTCOUNT field
>
> - either impose a fixed limit on the number of additional QTYPES (in the
>    range of 3 - 8?) or remove the limit altogether.
>
> We need to get formal WG consensus on these points so please send your
> thoughts to the list...
>
> thanks
>
> Ray
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
>