[dnssd] Re: Progressing with multi-qtypes

Ted Lemon <mellon@fugue.com> Wed, 08 May 2024 11:56 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 20E8BC14F6A4 for <dnssd@ietfa.amsl.com>; Wed, 8 May 2024 04:56:33 -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 GBHAKSdypmaP for <dnssd@ietfa.amsl.com>; Wed, 8 May 2024 04:56:31 -0700 (PDT)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 E2BC6C14F5FA for <dnssd@ietf.org>; Wed, 8 May 2024 04:56:31 -0700 (PDT)
Received: by mail-qv1-xf33.google.com with SMTP id 6a1803df08f44-6a073f10e25so23647006d6.3 for <dnssd@ietf.org>; Wed, 08 May 2024 04:56:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1715169390; x=1715774190; 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=iJ3Q65p8dVarxtS9Bb3QWlb1WgdIKa3Hk0Jlk5/2s+E=; b=I/f2V6Y0erHQFLjmOnOoyE+EkR6jUvC7PeBrgNwPkt9GJt9L7oTw74/PH2cfFtpo3r 0wry9xIXbMd2HBTINERul28hDm6gZqGEG0GSuGcK6yS1RHR6MOWz7cusGIIlWY8OMxMm d3TsNyiqD6+ziJMz2Gj9cNLQAy7AKQYjBX+PP6G0DyaoUB9RpwDXGvmkFy5mHcFq/mDT jwbouPWPtQKM5lxVwulKDvwjsKzUZH8QJmhrXFMPpM+LtaGV6yw4U82GzL8Xoxvqbu4L Qf0NLKCZPuOVZLeNnlf8tw+rMNsLSgcvIqhN2/Z+3yio2J98Wm0xd8aeVooi2Q2KmVAA bY1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715169390; x=1715774190; 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=iJ3Q65p8dVarxtS9Bb3QWlb1WgdIKa3Hk0Jlk5/2s+E=; b=fuppMsvLmIGWQ/+2hw6fHXHRfQTWdD7Ocjr5AXN2t8S8JzeIsHfLLgglf0O9F1n+1/ LWDEViYSGA/2SXTArhZHN6MNEAo1YP1dXSMcrA3lWyiEDjwYQcNSkywxmxr1aJRCr/VO +H/f3gN3ZiBUcw5i1Phx0o5cKLqniwHsnKA0Cl67guwq+b14+u61W0LIynJyxadxWGHv lxXrnWMeMz3HkFC4LkunsZwY6PsHrI5lcXWFHaK/stXyJ/qQi0d5rnnhba+0HYUJNutX oweS+VG19mdqHSnps1N9Lz5NvpVmsM9UJaKQSbKP5G8mpOAqfiY/VHngXr/JfSvvygSX 3U7Q==
X-Forwarded-Encrypted: i=1; AJvYcCV3/Q4X+JAlxxWu6gfd5e22En8zfmWKFgmu/xjdrGcnutpjHdUxkFeZ4pW3ZYpVjI6kbdkZxXwmQudS4ABUEA==
X-Gm-Message-State: AOJu0Yx7CsUidXks0SUf7+T4syR+kRNc43hdaxW1znXTJYLpPH2HJbPX zEwt9xplvHOw9P0rtnoY6p6CTFRTFhbnbxYYmAYjyyt0Q3opniyjBwOBta0XKERJpRPX9fMhd7X xWuBQqrUSiOfeueBkYa7cNgSftjdfbTPg/+ENUvpoaLoawXhi
X-Google-Smtp-Source: AGHT+IG0Ihs0q5WFHDgkIUuhBv1bRVgLdP+FXQzYgquIzfREqm7fyyg2Pd7sA1cPblqxXm0NJBHcq2+QmSU2EvwSciQ=
X-Received: by 2002:a05:6214:29e7:b0:6a0:b3eb:5626 with SMTP id 6a1803df08f44-6a151500ecbmr28747206d6.39.1715169390037; Wed, 08 May 2024 04:56:30 -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> <CAPt1N1mu0_4fvFoL7tHExPxeODh-dGeaOZJSOMqjPqwchGmFYA@mail.gmail.com> <DU0P190MB1978E6F2B23958871B57C036FDE52@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <DU0P190MB1978E6F2B23958871B57C036FDE52@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 08 May 2024 07:56:18 -0400
Message-ID: <CAPt1N1koxCqCCurh1yqQjrby2U-K=3qSHD73RM9WT59x+5J1jw@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Content-Type: multipart/alternative; boundary="0000000000003927230617effe6b"
Message-ID-Hash: XU3WETNDCOPW377EOTGTJX7U2J6DW3MZ
X-Message-ID-Hash: XU3WETNDCOPW377EOTGTJX7U2J6DW3MZ
X-MailFrom: mellon@fugue.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnssd.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: David Schinazi <dschinazi.ietf@gmail.com>, Ray Bellis <ray@bellis.me.uk>, dnssd <dnssd@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [dnssd] Re: Progressing with multi-qtypes
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/RoiZylEQg07n-VUPcE6kfG8jLao>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Owner: <mailto:dnssd-owner@ietf.org>
List-Post: <mailto:dnssd@ietf.org>
List-Subscribe: <mailto:dnssd-join@ietf.org>
List-Unsubscribe: <mailto:dnssd-leave@ietf.org>

Another approach (I think someone already suggested) is that a caching
resolver responds with what it has and indicates that it didn’t have
answers for the rest, please send another query for those. But that’s more
complicated to implement.

Op wo 8 mei 2024 om 05:48 schreef Esko Dijk <esko.dijk@iotconsultancy.nl>

> If the query receiver is a recursive resolver, and the auth server is
> elsewhere, then my argument of easily iterating over 300 QTYPEs in the
> request falls apart.
>
> Whether the resolver is resource-constrained or not: sending out 300
> individual DNS queries to the auth server based on a single request sounds
> problematic – risk of amplification attacks?
>
>
>
> In this case David’s proposal could be applied by the resolver: it MAY
> ignore most of the requested QTYPEs.
>
> However, are we okay to leave the number of handled questions completely
> up to the implementation? What is reasonable/expected - 3, 7 (0b111 –
> current draft), 10, 100 … ?  Or could the resolver/server pick preferably
> those QTYPEs that it knows about?  (to avoid 100s of requests for undefined
> ‘bogus’ QTYPE numbers).
>
> Or MUST it process QTYPEs sequentially before deciding to drop the rest?
>
>
>
> Esko
>
>
>
> *From:* Ted Lemon <mellon@fugue.com>
> *Sent:* Tuesday, April 30, 2024 00:27
> *To:* Esko Dijk <esko.dijk@iotconsultancy.nl>
> *Cc:* David Schinazi <dschinazi.ietf@gmail.com>; Ray Bellis <
> ray@bellis.me.uk>; dnssd <dnssd@ietf.org>
> *Subject:* Re: [dnssd] Progressing with multi-qtypes
>
>
>
> 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
>
>