Re: [dnssd] Progressing with multi-qtypes

David Schinazi <> Mon, 29 April 2024 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91091C14F70B for <>; Mon, 29 Apr 2024 09:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Status: No, score=-7.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JdEU3wPRAWvd for <>; Mon, 29 Apr 2024 09:58:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62b]) (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 (Postfix) with ESMTPS id 0B915C14F68F for <>; Mon, 29 Apr 2024 09:58:49 -0700 (PDT)
Received: by with SMTP id a640c23a62f3a-a52223e004dso506967466b.2 for <>; Mon, 29 Apr 2024 09:58:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1714409927; x=1715014727;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AYFjxFzKACMQMVksVyoeP/tcUJsUoIpkEQxEOQM5WOc=; b=BkEP760t0coe/N6uZ1Ndc/Cm0vSuXlmckqTDtzsQ8fthX/rYq8ltqNCQEAm8xqdH9a FpQPY5bHeiaS0CXAoOpCez5aBIV83y6ezpZRQ0YP7WsBhO4pcukUReQwEIByTE4iKQwm jWjtIQ6N6hqoO5V2WMF7YrMZjlxDpbOmbQeuhN8sy1mk+3mLex+A3+jc0CX0hx32DbHz mcvS9rvfjuMwWnUWcBdSY7UlabRy0IUdW1rk26VYpA/f16GENrpVveGbfxtRDAWyfhAy VBIlF28bHyS/3T5fNLKgJXvkfs7xjuGSwdzIt6ZliXsH9oV/6vMOyUTa5+QD7J3pyadJ Yxwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1714409927; x=1715014727; 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=AYFjxFzKACMQMVksVyoeP/tcUJsUoIpkEQxEOQM5WOc=; b=LSJNFRfciDzewLinUl/GZgvDRyqoNNd4hU7oQk4G7qTuVCQqAx1euV1PeuxV+hrvAR t4gtcTub0Im6ylu46YWfbYsVkFfRqIlvqo8JbumOgoGitwkDa1YDZeBkdDJfjJS6Pj0l 788Jq7Zf7pNIehY2kPjpehEcrBkRozRfaOGFXPjVqynolEMTZ+cYasSf4d2V8zWoG9HS 3IQlaVYd8KUi4bu0J5j0NihteEr+gPjqskPL9DkimqxCD9gi7AWh2+WUMBJd32qXhs/n Awj2HqMnNdTId2P1zhV0igpEw4AnJXAYLwj6ftVdibN02Ev7IxJCPgNtrRsLkvZOHbd4 wTow==
X-Forwarded-Encrypted: i=1; AJvYcCWo6fyhf9PvpTQDSfBVH4spfwvEK58QWNHQKkzEY/w1TumEMZeH7xsWLvAEOCR7HbMA5GdeXrZQAofmncDyJA==
X-Gm-Message-State: AOJu0YzpjAmunoaPoBJMHOS0zD95PIyYutSQXy26hxAV95U7S9nT9C7+ YvT4V+ddBF/PVIbOvpAFDA5xrq+gt5fSfBXfKIZuzi+XtiWdiKVdKc8QejGkSlFKIOyVvpA8cLx IEHJUKY/D8wYvieIE69X0RDqYnAQ=
X-Google-Smtp-Source: AGHT+IFGCOK1wh7O2YBhmPZW/PcRC0WMhWIvoMv93l4eiO2xP9OdLBOaEbd8Lk9PTJNEVjCU1BZ7M4McAxDQg1GcY7g=
X-Received: by 2002:a17:906:3805:b0:a58:e3d5:87ba with SMTP id v5-20020a170906380500b00a58e3d587bamr6579385ejc.75.1714409926965; Mon, 29 Apr 2024 09:58:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Mon, 29 Apr 2024 09:58:35 -0700
Message-ID: <>
To: Ted Lemon <>
Cc: Ray Bellis <>, dnssd <>
Content-Type: multipart/alternative; boundary="000000000000b240f006173f2aa5"
Archived-At: <>
Subject: Re: [dnssd] Progressing with multi-qtypes
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Apr 2024 16:58:53 -0000

[ 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?


On Mon, Apr 29, 2024 at 6:21 AM Ted Lemon <> 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 <> 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 mailing list