[GH-ISSUE #897] Support for RDATA presentation format #557

New issue

Closed

opened 2026-03-15 23:08:30 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 23:08:30 +03:00

Owner

Originally created by @rotty on GitHub (Oct 21, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/897

I'm currently (slowly) working on adding the "presentation format" of various record types to tdns-cli. This functionality may make sense to have in trust-dns-proto; the API might look something like this:

let rdata = RData::CAA(...);
assert_eq!(rdata.display().to_string(), 
           "CAA 0 issue \"letsencrypt.org\"".to_owned());

That is, the RData enum would gain an additional method, named something like display() (which has precedent in std::path::Path) or presentation() (which would follow RFC terminology), that returns a type that implements std::fmt::Display. It may also make sense to add such a method to all types wrapped by RData (e.g., for rdata::caa::CAA itself) that do not already implement Display themselves.

I would first finish the code in tdns-cli (see query.rs for the measly beginnings), and when I've implemented all record types and added tests, I'd construct a PR based on that, if there's interest for this feature.

Originally created by @rotty on GitHub (Oct 21, 2019). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/897 I'm currently (slowly) working on adding the "presentation format" of various record types to `tdns-cli`. This functionality may make sense to have in `trust-dns-proto`; the API might look something like this: ```rust let rdata = RData::CAA(...); assert_eq!(rdata.display().to_string(), "CAA 0 issue \"letsencrypt.org\"".to_owned()); ``` That is, the `RData` enum would gain an additional method, named something like `display()` (which has precedent in `std::path::Path`) or `presentation()` (which would follow RFC terminology), that returns a type that implements `std::fmt::Display`. It may also make sense to add such a method to all types wrapped by `RData` (e.g., for `rdata::caa::CAA` itself) that do not already implement `Display` themselves. I would first finish the code in `tdns-cli` (see [`query.rs`](https://github.com/rotty/tdns-cli/blob/master/src/query.rs) for the measly beginnings), and when I've implemented all record types and added tests, I'd construct a PR based on that, if there's interest for this feature.

kerem

2026-03-15 23:08:30 +03:00

closed this issue
added the
enhance

crate:client
labels

kerem commented

2026-03-15 23:08:46 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 22, 2019):

I think doing display would be fine. It might be enough to change add Display implementations for all the RData's? I've been intending to do this at some point, but never got around to it.

Most are pretty simple conversions. I think we only have the text serialization routines in the client, we might want to continue that president to keep the resolver lightweight.

@bluejekyll commented on GitHub (Oct 22, 2019): I think doing `display` would be fine. It might be enough to change add `Display` implementations for all the RData's? I've been intending to do this at some point, but never got around to it. Most are pretty simple conversions. I think we only have the text serialization routines in the `client`, we might want to continue that president to keep the `resolver` lightweight.

kerem commented

2026-03-15 23:08:51 +03:00

Author

Owner

@rotty commented on GitHub (Oct 23, 2019):

I think doing display would be fine. It might be enough to change add Display implementations for all the RData's? I've been intending to do this at some point, but never got around to it.

Yeah, just adding a Display implementations to all encapsulated RData types and RData itself should work; no need for the indirection.

Most are pretty simple conversions. I think we only have the text serialization routines in the client, we might want to continue that president to keep the resolver lightweight.

How would that work? Due to the orphan rules, one cannot add Display implementations in the client crate for types defined in the proto crate, I think. I agree however that adding them to proto directly is not ideal, as that would add (at least) a dependency on the data-encoding crate (for base64, base32 and base16 encodings), which would be nice to avoid. The alternative would be to add a newtype wrapper, e.g., ShowRData<'a>(&'a RData) which then implements Display. This could be added to the crate where it makes the most sense, such as client.

@rotty commented on GitHub (Oct 23, 2019): > I think doing `display` would be fine. It might be enough to change add `Display` implementations for all the RData's? I've been intending to do this at some point, but never got around to it. > Yeah, just adding a `Display` implementations to all encapsulated RData types and `RData` itself should work; no need for the indirection. > Most are pretty simple conversions. I think we only have the text serialization routines in the `client`, we might want to continue that president to keep the `resolver` lightweight. > How would that work? Due to the orphan rules, one cannot add `Display` implementations in the `client` crate for types defined in the `proto` crate, I think. I agree however that adding them to `proto` directly is not ideal, as that would add (at least) a dependency on the `data-encoding` crate (for base64, base32 and base16 encodings), which would be nice to avoid. The alternative would be to add a newtype wrapper, e.g., `ShowRData<'a>(&'a RData)` which then implements `Display`. This could be added to the crate where it makes the most sense, such as `client`.

kerem commented

2026-03-15 23:08:56 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 19, 2022):

I can't point to exact PRs, but I think this is complete at this point.

@bluejekyll commented on GitHub (Mar 19, 2022): I can't point to exact PRs, but I think this is complete at this point.

kerem referenced this issue

2026-03-16 02:10:33 +03:00

[PR #557] [MERGED] DNS over HTTPS suppor in server & client #1511