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
