Support DNS messages with RFC 8490 DSO-Data

[Kentzo]

In this PR I used custom, non-RR, type to directly represent DSO data in Msg.

Msg.Pack doesn't stand in user's way if they want to pack DSO message with RRs. On the other hand, Msg.Unpack won't attempt DSO unpacking unless true number of RRs is zero.

[Kentzo]

This is done in spirit that if user wants to pack an invalid DSO message (with both DSO-Data and RR-data) we should not disallow compression.

[Kentzo]

This seems wasteful when messages originate from the user as it going to be just slices of N '\0' bytes. I suppose this could be replaced with some "sparse" structure.

[Kentzo]

fwiw, of 1212 added lines, there are 126 are "newlines" and 222 are comments.

[miekg]

isDSOCompressible(dns)

DSO has compression??

(still 1200+ lines ...if inclined to review, I'm spending less then an hour on this lib per week, so we're talking early next year)

[Kentzo]

Correct. See RFC 8765, Push TLV.

still 1200+ lines ...if inclined to review, I'm spending less then an hour on this lib per week, so we're talking early next year

no worries and no rush. Im experimenting in my fork and happy to assist.

[miekg]

Wow, some badly written text right there. Compression in nsec rdata. Wtf? Anyway that is just normal owner name compression, so nothing to do with dso what so ever. So again. No new code required

…

On Sat, Aug 16, 2025, 19:30 Ilya Kulakov ***@***.***> wrote: *Kentzo* left a comment (miekg/dns#1672) <#1672 (comment)> Correct. See RFC 8765, Push TLV. — Reply to this email directly, view it on GitHub <#1672 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACWIW5VSAPED3B2MQATPCT3N5TEDAVCNFSM6AAAAACD3DFGOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOJTHAYDGMRYGY> . You are receiving this because your review was requested.Message ID: ***@***.***>

[Kentzo]

Msg.isCompressible as written relies on *Count to determine whether Msg os compressible in principle. This check is useless for DSO messages, because counts are 0.

Although, since this is a performance optimization (to avoid allocation of compression tables needlessly), it could suffice to consider any OpcodeStateful message as compressible for the sake of simplicity.

[miekg]

Nothing of this stuff will be merged as-is. We can have a discussion on this - should have happened first - but then still I don't think such a niche DNS feature should warrant such a code increase in this lib. /Miek

…

On Sat, Aug 16, 2025, 21:04 Ilya Kulakov ***@***.***> wrote: *Kentzo* left a comment (miekg/dns#1672) <#1672 (comment)> You want this checks directly in dns.is Compressible? — Reply to this email directly, view it on GitHub <#1672 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACWIW5D5QKJWBMENBQR6AT3N56CHAVCNFSM6AAAAACD3DFGOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOJTHA2TAOJXGQ> . You are receiving this because your review was requested.Message ID: ***@***.***>

[Kentzo]

*please see edit to the message above.

still I don't think such a niche DNS feature should warrant such a code
increase in this lib.

The readme says support of rfc 8490, hence my interest to actually help implementing it. I understand if you don’t want, but then I’m confused by the claim.

We can have a discussion on this - should have happened first

I wanted to have full working implementation (via CoreDNS plugin) and intended to present my work only then. I decided to publish this (and previous related one) PR after learning of your work on dnsv2 just to give you an idea what might be needed for proper DSO support, as claimed in readme.

By no means the PR is final and I’m happy to rearrange as necessary.

However, since you have little to no time to dig into RFCs and read other implementations, perhaps it’s more efficient to do back-and-forth via PRs? Easier to discuss code at hand than abstract ideas.

[miekg]

there are many, many unfleshed things that are done in this PR and I'm not going add this anytime soon and probably never (in this repo).

In codeberg's version there are/were some issues that start from the very beginning on how this might be possible or not.

Even super basic things like: everything guard against question != 1, how do you propose the cleanly fix that and do we need this (and maybe more - dont think its my task to enumerate these)

[Kentzo]

Whether this lib needs guards / validation checks is up to your consideration, of course. User’s code will need them, because the spec often requires to “forcibly disconnect” and it seems prudent to drop a poor actor as soon as possible. But I have no objections to omit them from this pkg entirely.

I will wait until you figure out a way to cleanly fold edns0, svcb and dso into pseudo in dnsv2. Don’t want to further clash with your process.