search

rust-embedded-community / embedded-nal

An Embedded Network Abstraction Layer
Apache License 2.0
177 stars 25 forks source link

Evaluate effectiveness of DNS traits #35

Closed ryan-summers closed 3 years ago

ryan-summers commented 3 years ago

It is currently my understanding that DNS can be implemented on top of generic sockets. As such, it should be possible to write a generic no_std DNS client crate that relies on the embedded-nal. This would mean that the dns traits in this crate could likely be removed, since they no longer need to be generic.

I'm curious to hear other opinions here - I have not yet written a DNS client, but likely will be doing so in the near future (and would publish it as said no_std DNS resolver)

ryan-summers commented 3 years ago

@MathiasKoch Can you elaborate as to the use case of the original trait? Is the desire to be able to provide a NetworkStack to a client protocol crate that is capable of resolving domain names to IP addresses for connections?

I could see that being a useful attribute, but it introduces of complexity of crate users - for example, what should we do for a protocol that wants optional DNS resolution? E.g. a network stack may or may not support DNS resolution.

Instead, if we had a standalone crate, then any protocols that want DNS resolution can just use any provided NetworkStack to construct a DNS resolver on top of available sockets to resolve domain names. This would eliminate the requirement that end users provide a DNS resolver

MathiasKoch commented 3 years ago

I have in my cases for example hardware that supports DNS lookups as AT commands, removing the need for a no_std dns client

MathiasKoch commented 3 years ago

I think it would be awesome to add some default opt-in embedded-nal based dns-client, but i wouldn't want to see the trait removed, as there are lots of cases where one can save binary size, and offload the task using co-processors

ryan-summers commented 3 years ago

Sounds good! Thanks for providing the input - I figured I was missing something. Do you have some examples of how these traits are being used?

MathiasKoch commented 3 years ago

You know i do ;)

https://github.com/BlackbirdHQ/ublox-cellular-rs/blob/master/ublox-cellular/src/services/data/dns.rs

Sympatron commented 3 years ago

I think it can be useful to have a "thing that does DNS" trait. Especially as it may already be supported by hardware or firmware.

Maybe adding a (basic) DHCP trait makes sense, too.

ryan-summers commented 3 years ago

@MathiasKoch I'm now starting to need the Dns traits, and I'm noticing that they appear to assume that the lookup can be completed in a blocking manner. For network stacks like smoltcp I don't think that's possible, since the network stack will need to communicate with the DNS server to resolve the request asynchronously. Perhaps we should use an nb::Result and potentially update this to async in the future?

MathiasKoch commented 3 years ago

@ryan-summers That wouldn't be a problem for me :+1:

ryan-summers commented 1 year ago

For context here, I chatted with the smoltcp folks and they pointed out that DNS can be intrusive into the lower layers of the network stack (i.e. grabbing at MAC addresses, etc.) because of its history with the bootp protocol. As such, it's somewhat difficult to segment DNS as distinctly "above" the socket layer. This makes a stack-agnostic DNS implementation difficult because of the need to know stack-specific information.