Re: [Cbor] Multiple questions with CBOR for DNS

[Esko Dijk <[e-mail]>]

I'm not expecting that the multi-question request will be used in the future with actual protocols like DNS-over-CoAP.
If it's a goal of the DNS-CBOR format to encode any possible DNS message, including ones that are very little used in practice, then supporting multiple questions would be required even though it has little practical application.

The case I described where it can be used is by devices running the OpenThread open source software; which has a facility to ask two questions (QTypes SRV and TXT) for one name. There's also DNS resolver code that understands this two-question format and provides the two answers back in a single DNS response. It may be that this behavior is eventually phased out of OpenThread though, because there's no IETF consensus at the moment to support QCOUNT >= 2 - see for example https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-qdcount-is-one .

So ideally we constrain our CBOR format here to 0 or 1 questions, which it can efficiently encode, while keeping some extension option open to - in the future, if really needed - be able to add questions.  So that older versions of a CBOR DNS parser would just ignore the additional questions.
This may be done via a CBOR tag, or some extra (reserved) items that can be added later in a CBOR list; so that we don’t burden today's format with extra structure or extra bytes just to support the multi-question case.
It's a bit like being able to add an "extension" to the format for the rare cases that it would be needed as discussed for the CRI format in CoRE.

Nit in the document: the section 8.2.1 section header should have a '+' in it :)

Esko

-----Original Message-----
From: Martine Sophie Lenders <[e-mail]> 
Sent: Wednesday, November 8, 2023 14:37
To: [e-mail]
Cc: [e-mail]; Esko Dijk <[e-mail]>
Subject: Multiple questions with CBOR for DNS

Hi all,

Esko talked yesterday about the potential requirements of having two 
questions in a DNS message. I think this could be achieved with a small 
extension to the existing definition that makes the question section an 
alternating list of names an type-specs (each pair of those being one 
question):

     question-section = [question+]
     question = (
       name: domain-name,
       ? type-spec,
     )

The only caveat I see is, that if we go with the componified domain name 
definition I presented yesterday, that at least a record type needs to 
be provided when more than one question is used. Otherwise, the 
compontents of names of different questions will become hard to keep 
apart by a parser.

Alternatively, we can go for a list of list in the question (each of the 
inner lists being a question). This has two caveats, however. (1) The 
question section will be harder to distinguish from the other sections 
in the response (given that it is optional, this is important). (2) We 
add at least 1 extra byte for the very rare (and by most resolvers not 
accepted) case that someone wants to have more than one questions.

Best
Martine