proto: implement FromStr for CAA/MX/SOA record data #1762
Conversation
|
Sorry for the late response to this. Do you think we could maybe reuse the client parsers for this? This is what I didn't do a good job of directing you to before, for example, here's the CAA parser, https://github.com/bluejekyll/trust-dns/blob/e166a23432ba74a1304b95390ad306a574775dbf/crates/client/src/serialize/txt/rdata_parsers/caa.rs#L48 We can move the For some background, this was separated out to reduce the overall size of the resolver and proto crates, so maybe we should feature gate it in proto? |
| impl FromStr for CAA { | ||
| type Err = ProtoError; | ||
|
|
||
| fn from_str(s: &str) -> Result<Self, Self::Err> { |
There was a problem hiding this comment.
This seems redundant to the existing parsing in the txt module of the client crate. I think we want to combine these and not duplicate the logic. Was there a reason you couldn't use that logic?
There was a problem hiding this comment.
I wasn't aware of that logic, I've never really used the client crate -- I guess I don't really understand what it's for? I've so far stuck with proto, resolver and server. Plus, it still seems weird that the server crate depends on the client crate, things like LowerQuery and LowerName feel like they belong in proto more than in client.
There was a problem hiding this comment.
Yes. I’m happy for us to shutdown the client crate at this point. I can review the history with you if you want, but at this point it does seem like the crate is a bit unnecessary. Moving it all into proto seems like a good idea. We could achieve the same goals of the crate by having a feature on proto.
There was a problem hiding this comment.
Yup, that sounds good to me.
There was a problem hiding this comment.
BTW, not sure we should shut down the entirety of the client crate? I just think a lot of these low-level parts make more sense in proto.
There was a problem hiding this comment.
Yes. That’s fine. Move txt to proto.
|
Also the formulation as |
It was a minimal attempt at a tokenizer. I’m open to any cleanup you might want to do here, it’s used during zone file parsing, where we tokenize and then pass the tokens into these parsers. I think we can put a blanket |
|
Do we want to keep this open at this point? Seems like we have since cleaned up the library implementations enough to make this unneeded at this point... |
No tests yet -- would you like me to write some up?