Struct trust_dns_server::ServerFuture

pub struct ServerFuture { /* fields omitted */ }

Methods

impl ServerFuture

fn new(catalog: Catalog) -> Result<ServerFuture>

Creates a new ServerFuture with the specified Catalog of Zones.

fn register_socket(&self, socket: UdpSocket)

Register a UDP socket. Should be bound before calling this function.

fn register_listener(&self,
                     listener: TcpListener,
                     timeout: Duration)
                     -> Result<()>

Register a TcpListener to the Server. This should already be bound to either an IPv6 or an IPv4 address.

To make the server more resilient to DOS issues, there is a timeout. Care should be taken to not make this too low depending on use cases.

Arguments

• listener - a bound TCP socket
• timeout - timeout duration of incoming requests, any connection that does not send requests within this time period will be closed. In the future it should be possible to create long-lived queries, but these should be from trusted sources only, this would require some type of whitelisting.

fn register_tls_listener(&self,
                         listener: TcpListener,
                         timeout: Duration,
                         pkcs12: Pkcs12)
                         -> Result<()>

Register a TlsListener to the Server. The TlsListener should already be bound to either an IPv6 or an IPv4 address.

To make the server more resilient to DOS issues, there is a timeout. Care should be taken to not make this too low depending on use cases.

Arguments

• listener - a bound TCP (needs to be on a different port from standard TCP connections) socket
• timeout - timeout duration of incoming requests, any connection that does not send requests within this time period will be closed. In the future it should be possible to create long-lived queries, but these should be from trusted sources only, this would require some type of whitelisting.
• pkcs12 - certificate used to announce to clients

fn listen(&mut self) -> Result<()>

TODO how to do threads? should we do a bunch of listener threads and then query threads? Ideally the processing would be n-threads for recieving, which hand off to m-threads for request handling. It would generally be the case that n <= m.