Struct trust_dns_server::ServerFuture

pub struct ServerFuture<T: RequestHandler + 'static> { /* fields omitted */ }

A Futures based implementation of a DNS server

Methods

impl<T: RequestHandler> ServerFuture<T>

fn new(handler: T) -> Result<ServerFuture<T>>

Creates a new ServerFuture with the specified Handler.

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: ParsedPkcs12
) -> 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.

fn tokio_core(&mut self) -> &mut Core

Returns a reference to the tokio core loop driving this Server instance