-
Notifications
You must be signed in to change notification settings - Fork 427
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proto: implement FromStr for CAA/MX/SOA record data #1762
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, that sounds good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?