Skip to content
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

Support issue, issuewild and iodef CAA property tags #11

Open
rushmorem opened this issue Apr 2, 2021 · 6 comments
Open

Support issue, issuewild and iodef CAA property tags #11

rushmorem opened this issue Apr 2, 2021 · 6 comments

Comments

@rushmorem
Copy link
Contributor

These have value types explicitly defined in the RFC (https://tools.ietf.org/html/rfc8659#section-4.2).

Perhaps instead of having tag and value fields for CAA RRs, we could just have value whose type is an enum like

pub enum Value {
    Issue(DomainName),
    IssueWild(DomainName),
    IoDef(url::Url),
    Unknown(Tag, Vec<u8>),
}

?

@LinkTed
Copy link
Owner

LinkTed commented Apr 3, 2021

Thanks for the suggestion. It has to be prevented that the user or the parse creates a Value::Unknown with Tag for example equals to issue. Because it would be ambiguous to Value::Issue.

I want to keep the library so that for the user it would be nearly impossible to create an incorrect DNS packet or ambiguous packet.

@rushmorem
Copy link
Contributor Author

We can prevent the user from not making such a mistake by not exposing the enum or checking for such mistakes when encoding the packet. As for creating it when parsing, that would be a bug in the parser. With correct code, it will simply not be possible.

I want to keep the library so that for the user it would be nearly impossible to create an incorrect DNS packet

Right now it's trivial for a user to create an incorrect DNS packet by creating a CAA record with a tag of "issue", "issuewild" or "iodef" and then using a value that doesn't parse to the type specified by the RFC. That's what I'm trying to avoid with this suggestion. We can use Rust's type system to avoid that.

@LinkTed
Copy link
Owner

LinkTed commented Apr 3, 2021

We can prevent the user from not making such a mistake by not exposing the enum or checking for such mistakes when encoding the packet. As for creating it when parsing, that would be a bug in the parser. With correct code, it will simply not be possible.

If we are not exposing the enum, how can the user create such RR then? About the parser you are right.

@rushmorem
Copy link
Contributor Author

By doing the construction through methods. Say Value::issue, Value::issue_wild etc that do the construction on the user's behalf.

@LinkTed
Copy link
Owner

LinkTed commented Apr 3, 2021

How the user can access the different data? For example, a DomainNameif it is a Issueor the Urlif it is a IoDef.

@rushmorem
Copy link
Contributor Author

rushmorem commented Apr 3, 2021

That boils down to your API design choice but here is one way to do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants