Open rushmorem opened 3 years ago
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.
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.
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.
By doing the construction through methods. Say Value::issue
, Value::issue_wild
etc that do the construction on the user's behalf.
How the user can access the different data? For example, a DomainName
if it is a Issue
or the Url
if it is a IoDef
.
That boils down to your API design choice but here is one way to do it.
These have value types explicitly defined in the RFC (https://tools.ietf.org/html/rfc8659#section-4.2).
Perhaps instead of having
tag
andvalue
fields for CAA RRs, we could just havevalue
whose type is an enum like?