Re: [dnssd] Progressing with multi-qtypes

Ted Lemon <> Mon, 29 April 2024 13:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 593A9C151064 for <>; Mon, 29 Apr 2024 06:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.895
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ti5R3EUGmfyy for <>; Mon, 29 Apr 2024 06:21:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::231]) (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 73C15C14F610 for <>; Mon, 29 Apr 2024 06:21:31 -0700 (PDT)
Received: by with SMTP id 5614622812f47-3c7513a991cso3120284b6e.1 for <>; Mon, 29 Apr 2024 06:21:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1714396890; x=1715001690;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=or2qJfEmAUpreY6ph3CUX2Bs8m1AMKqsmDRVrSL21Qo=; b=hUuoMWfpHTm/DeTInucyV5VhowGaSLD0J3viazTjLkp2IQSmRry1OaASWXieOPBnPX wCjnbJHf2dJLrC4LtHJiHqDpp1voHhFgB6B0F5NoUtjUm8/PmN+tobKtyBajwCaOU08C W4momyRwm27qqMHaraNFxhCNfr9zg5VcQC35mApnA0u7f2iDOgJ2KFR1SqHYfV6spjp4 4GZkmp+Edf3DFovGuU1QfMrEnUq3vUrbo4cj5KnjEP8zTOT6giT9RA8OmkwNsjONi3DU 8ZokZp2UOnvvHjx1JYSsLYUEpoJM9gOuubJqcQbQchu5a/8alJU5eReyGT9RMrxK5YKL MfoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1714396890; x=1715001690; 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=or2qJfEmAUpreY6ph3CUX2Bs8m1AMKqsmDRVrSL21Qo=; b=oc4SfT4jt5S74F2Gk8DfryGx+JBzMMsgt6SHgysAiBwAP9LzqyVJpGFS2Fwzz1GT7e tvSIoicnLAopnhDuKnD/cIIQ/Iajobkac3MJVZ/JKq/6HvV1td6AbdfjIlJwnD4rpd1e BZid8aD5CsIqv5e9FMIGGJdEjT7n5O4tcG5HbS15mkhc4juoBMMyPT5MdmeNU1187FAv wlvSeeV04BA4ZqOTQuk1B+5UI+1ddmuivYBcXKD/2t4UXA9eU2zvpOO3Skg5yl4ngmwY 2JR0SbfBShy4TGgJw441xgtzyDefUZHK9io3oBxeIbbp9Zj07oRKidX1e7pEg21e91e1 WNdA==
X-Gm-Message-State: AOJu0Yyy0EUYH7WK6yoll0+zJ/qASa30ElrrWyP666hRTup/Mbmi/h4i M2nlFBvSI8sIMZXWRX3xLqlctBiY9RzWTNh+IyWSRXr3lI5zioLHcykny2uN3hhiG+TohakZJdp LjP3krwfUnrMTQvyuwVFN+aEsvltb/1snJ4WRIYtwHSDLw67j
X-Google-Smtp-Source: AGHT+IGh30VAxnNJ/5DIKQl+hoXixLWVdG23FhP0mU67qgHf3ZpU0P99oKjNdZtQbuM6JvvxqARyztA+0kXJxD785JU=
X-Received: by 2002:a05:6808:a09:b0:3c8:53aa:b1cd with SMTP id n9-20020a0568080a0900b003c853aab1cdmr10749997oij.23.1714396889980; Mon, 29 Apr 2024 06:21:29 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Mon, 29 Apr 2024 09:20:54 -0400
Message-ID: <>
To: Ray Bellis <>
Cc: dnssd <>
Content-Type: multipart/alternative; boundary="000000000000a1bdd506173c2159"
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 13:21:35 -0000

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