Introduce a new base module
#474
Conversation
It implements 'Hash' for the provided integer types.
This has already caught a missing commit (for 'Question').
These interfaces need to be redesigned to be more specific to important use cases.
| fn parse_from_message( | ||
| message: &'a Message, | ||
| start: usize, | ||
| ) -> Result<Self, ParseError> { |
There was a problem hiding this comment.
Why not call split_from_message and check that rest is empty?
There was a problem hiding this comment.
While that would be a valid implementation, I am hoping to define new proc macros for SplitFromMessage and ParseFromMessage soon (in the same fashion as SplitBytes and ParseBytes). I chose to define this method with a bit more boilerplate so that I can refer to it as a template when writing the proc macro.
| #[derive(Clone, BuildBytes, ParseBytes, SplitBytes)] | ||
| pub struct Question<N> { | ||
| /// The domain name being requested. | ||
| pub qname: N, |
There was a problem hiding this comment.
I think for names there needs to be some underlying trait that specifies that N can parse and build compressed DNS names. Otherwise, for example, compressed and uncompressed names can get confused or other confusion may arise.
There was a problem hiding this comment.
It is strongly expected that any domain name type (at least those in this crate) will implement ParseFromMessage, SplitFromMessage and BuildIntoMessage using name (de)compression. It is currently possible to use an incorrect type here, but I believe the risks of such a confusion are quite low. In the future, if we introduce new name types which do not follow these conventions, we can introduce e.g. a Name trait.
| #[cfg(all(feature = "std", feature = "siphasher"))] | ||
| use crate::new_base::wire::{AsBytes, TruncationError}; | ||
|
|
||
| //----------- CookieRequest -------------------------------------------------- |
There was a problem hiding this comment.
I find this very confusing. There are two types of cookies, short cookies that only contain the client's cookie and longer cookies that contain both the client and the server parts. There are two roles, the client and the server.
It is unclear to me what is what and who does what.
There was a problem hiding this comment.
A CookieRequest is a "client coookie", which requests a Cookie ("server cookie") from the server. I tried these names out as I found them more intuitive than ClientCookie and ServerCookie, but I'm happy to switch to the conventional names.
There was a problem hiding this comment.
Clients send two types of cookies, the small one and the big. And receive only the big one. Servers receive small and big and send only big.
Another issue might be that if a client receives a server cookie, we cannot assume anything about what the server put there. The server might just send some random bytes.
| #[repr(transparent)] | ||
| pub struct Txt { | ||
| /// The text strings, as concatenated [`CharStr`]s. | ||
| content: [u8], |
There was a problem hiding this comment.
This seems wrong. A txt record is a collection of strings. Boundaries need to be preserved.
There was a problem hiding this comment.
CharStrs are the DNS <character-string>s and always start with a length octet, so boundaries are preserved.
There was a problem hiding this comment.
Ah. Maybe an extra comment with what you just wrote.
This introduces a
new_basemodule as a potential candidate for replacingbase. While it has a similar structure (although much is left to be filled out), it has three distinguishing features:It builds the foundation for a
derive-based interface for easily and efficiently parsing (and possibly building) DNS messages.It introduces
RevName, a more efficient type for domain names (where labels are stored in reverse order).There's a lot more work to be done:
Note: this is a new version of #469 with a less problematic branch name.