Using the ListenAndServe with network as "tcp-tls" will cause an error, as the
certificates weren't informed. To solve that we created the function
ListenAndServeTLS that will configure a DNS server listening TCP and handling
requests on incoming TLS connections.
See #297
We should allow the server to receive requests of an encrypted connection. This
is proposed on the document draft-ietf-dprive-dns-over-tls [1].
Now it is possible to initialize the DNS server to listen with TLS using
"tcp-tls" value in network parameter of ListenAndServe function, or passing a
listener initialized with tls.Listen to ActivateAndServe.
There's also an option in Server type to change the TLS confirguration, to
inform the certificates that are going to be used, or to change any other
desired option of tls.Config.
See #297
[1] http://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-02
We currently close the connection after 128 TCP queries. But the
when the last query comes in, we close the connection immediately.
Fix this by moving the check to before we read data from the TCP
socket.
Fixes: #218.
Expose the udp and tcp listening socket when ListenAndServe() is used, it seems like
plopping them on Server.Listener and Server.PacketConn would be ideal. The use case is so
that a port of zero can be used and having them exposed will allow for examination of the port
that is bound.
Adds a field, NotifyStartedFunc func() to Server.
If non-nil, it is called after a server starts listening. This is useful
for synchronization purposes, for example when a daemon needs to drop
privileges after binding. Otherwise, there is no way to determine when
the server has begun listening and hardcoded delays (!) must be used or
race conditions may occur.
This stops it from checking if the incoming requests have the QR bit
unset, so be careful when enabling this. This can be useful in
combination with mDNS.
Also the check for only 1 question in the question section is relaxed
to be "at least one", even without setting Unsafe!
Also update TestServingResponse to test for Unsafe vs not using Unsafe.
Clients sents NULL-packet to server which helps to avoid
timeout. Timeout is still possible to encounter.
Shutdown will likely report error for those cases.
* stopped obvious race condition with replacing handler in
ServingLargeResponses test
* lowered probability of other race conditions with test code
while test server is yet activating
* fixed errmessage in Shutdown
* incorporated @miekg suggestions on switch vs if
* for now moved reaction to stopXXX channel messages until
after the packet is responded to avoid client timeout in
Shutdown (causing 2 sec. hanged thread)
Still not great how the abort logic is implemented....