# Proposal for swift-dns-types **URL:** \ **Category:** Networking\ **Created:** [July 23, 2026, 6:11pm UTC](https://forums.swift.org/t/proposal-for-swift-dns-types/88492 "2026-07-23T18:11:40Z")\ **Posts on this page:** 1\ **Showing post:** 30
**Author:** ![MahdiBM](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mahdibm/32/45271_2.png) [@MahdiBM](https://forums.swift.org/u/MahdiBM)\ **Post date:** [July 29, 2026, 7:26am UTC](https://forums.swift.org/t/proposal-for-swift-dns-types/88492/30 "2026-07-29T07:26:30Z")
> [@Saklad5](#): > > That's just RDATA. To be honest It's not clear to me what you mean here. My best guess is that "it's outside the swift-dns-type package's responsibility so it's not a worry right now and one could implement it either way"? > [@Saklad5](#): > > I'd argue the correct answer is "yes", though the design I proposed would allow considerable variation in API design between different record types. A hypothetical SVCB type could memoize decoded values without violating the protocol, and even that would still allow users to handle the value without unnecessary allocation (by simply moving around the `RawValue`). Sure. "the design I proposed would allow considerable variation in API" is correct. What I'm trying to say is that this will be a clear net loss all things considered, compared to a more classic "just decode" pattern. > [@Saklad5](#): > > A hypothetical SVCB type could memoize decoded values without violating the protocol, and even that would still allow users to handle the value without unnecessary allocation (by simply moving around the `RawValue`). It is possible. Does it come with any gains in practice though? Even if yes, is it overall worth it, all things considered (usability/UX for example)? Those are my doubts. > [@Saklad5](#): > > I think it's best to make specific record type implementations entirely distinct packages from this one, as some of them will require significant dependencies to do properly. Some are related to each other, of course: `A` and `AAAA` could be one package. This means that swift-dns-types would only have impl of the header and base record type without rdata implementations. But then it also implies that swift-dns-types will not contain decoding/encoding logics? Because performant such impls, for swift-nio for example, will need to rely on `ByteBuffer`? I haven't looked but i'd guess that's how swift-http-types does it? Then a secondary package could be swift-dns-nio-types, which allows for depending on `ByteBuffer` and adding RData impl? a third package could be swift-dns-nio-types-json or such? That sounds OK to me although there will be some complications. But then do we really want to be that generic? Right now the only networking library we have is swift-nio, which is fairly standardized. swift-nio itself supports using the Network framework underneath, but are we thinking we might need to account for such a case where Apple want to use this library to directly use it via the Network framework? I can't tell, but I'd lean on the side of "no, Apple would likely just use swift-nio anyway". And if swift-nio is the choice then I can't tell what this amount of genericism buys us. > [@Saklad5](#): > > Anyway, I think this has drifted a bit from the original point of the thread: Right, but I think it's important to actually consider swift-dns-type in context of ... well ... a dns client / server. > [@Saklad5](#): > > would the working group be willing to adopt a `swift-dns-types` package consisting of an implementation for the record and message formats defined in RFC 1035? **Not** the RDATA formats: RDATA can be considered opaque as far as this is concerned. Then I'd expect the working group to be able to come up with convincing arguments to the community as to why such decision has been made. I know Tommy, who is part of the working group, is very engaged in the DNS space. I had seen him in some IETF recordings of the DNS working groups. So naturally, if things get subjective, We should, and I will, value his opinions over mine. However, this has not been implied to me that these are his opinions. Or that there are any prior art regarding DNS types in other languages where it's been presented that such loosely defined APIs have substantial gains. Therefore, considering that I do have some experience with DNS, I have no choice but to rely on my own experience and raise my doubts against the proposed preferred way of doing things. What would be the gains to such a loosely defined API? If you want performance, I can guarantee we can have _very good_ performance (not "excellent" perhaps, but very good) with the correct impl without the need for an impl as generic as this. If you want composability and to ensure easy evolution of the package with respect to DNS's own evolution, then my experience shows such generic APIs result in minimal or no gains. Side note, "very good" and "excellent" are subjective adjectives. So to have an idea of what I mean by them, I can mention [simdjson](https://github.com/simdjson/simdjson) or [swift-endpoint](https://github.com/swift-dns/swift-endpoint#performance) as what I think of when I say "excellent". Basically an impl which is able to demonstrate that it beats other languages' impls, hopefully with ease. An impl that can demonstrate it adequately maxes-out CPU resources of at least a few common CPU architectures, without leaving them idle. All-in-all I'm not convinced what has been proposed as the preferred way of implementing swift-dns-types, is the best way. I'd say at this point the best course of actions is for me to actually get to work and showcase that the APIs can work pretty well in the way I'm proposing to implement the such a swift-dns-type package, but this might take a month at least so I thought it's worth discussing it if/when I have the time to do that. * * * > [@Saklad5](#): > > ```swift > /// The IPv6 address contained in the record. > /// > /// See [Section 2.2 of RFC 3596](https://www.rfc-editor.org/info/rfc3596/#section-2.2). > var address: UInt128 { // or custom IPv6 type defined elsewhere > get { rawValue.data.load(as: UInt128.self, endianness: .bigEndian) } > set { rawValue.data.store(newValue, as: UInt128.self, endianness: .bigEndian) } > } > > ``` A less important discussion compared to above is that if we are to anyway have such "lazy" decoding APIs, IMO at least some of these fields should be functions instead of computed variables, to imply that a possibly expensive action is being taken, such as decoding domain-names/arrays/sets. * * * A third discussion is that we're going to hopefully soon have a base bag-of-bytes impl ([see this post by one of the swift-foundation folks](https://forums.swift.org/t/discussion-bag-of-bytes-types/86983/34)), with which there should theoretically be no longer a need for relying on `ByteBuffer` as `ByteBuffer` should instead allow "free" conversion of itself to/from that "bag-of-bytes" type (Not guaranteed, we'll have to confirm). We could also rely on such assumption if we can confirm the accuracy if it, and for now live on with using `[UInt8]`/`Data`/`ByteBuffer` and just ensure that we are able to change them in such a future where the bag of bytes types are finally here. --- _[View the full topic](https://forums.swift.org/t/proposal-for-swift-dns-types/88492)._