Re: [DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-08.txt

[Ray Bellis <[e-mail]>]

On 16/11/2023 11:13, Paul Wouters wrote:
> On Tue, 14 Nov 2023, [e-mail] wrote:
> 
>> Internet-Draft draft-bellis-dnsext-multi-qtypes-08.txt is now available.
> 
> Last time this came around I also suggested instead of n times QT
> entries, to use the same method as NSEC does for conveying which RRtypes
> are covered using a single bitmap:
> 
> https://datatracker.ietf.org/doc/html/rfc3845#section-2.1.2

Speaking personally, I am not a fan of NSEC bitmaps when used to encode 
a small and possibly sparse list of QTYPES.   It's relatively 
complicated to encode / decode and is often inefficient.

I note, for example, that encoding HTTPS (type 65) this way requires 10 
octets.   Notwithstanding that asking for "AAAA" too would also fit 
within that 10 octet bitmap, in this draft's simpler model it would only 
take 2 octets to encode HTTPS, or 4 to encode AAAA + HTTPS.

In any other use case where multi-qtypes is just used to request one 
single additional type then that singleton list takes two octets 
irrespecitive of what that type is, and that's smaller than the smallest 
possible NSEC bitmap (3 octets).

[I've excluded the QTCOUNT leading byte because it has been suggested 
that it's not necessary.  This should be a separate discussion].

Making HTTPS the primary QTYPE such that the EDNS option only needs to 
encode (A + AAAA) would reduce an NSEC-style bitmap from 10 bytes to 6, 
but it'll be a long time before HTTPS becomes the most common response 
to A / AAAA / HTTP.

cheers,

Ray