On 16/11/2023 11:13, Paul Wouters wrote:
On Tue, 14 Nov 2023, internet-dra...@ietf.org 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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to