Previously it was possible for two different questions to hit the same
single in flight entry if the type or class isn't in the relevant
XToString map. This could happen for a proxy server or similar.
* Simplify Server.readTCP
This slightly alters the error behaviour, but it should not be
observable outside of a decorated reader. I don't believe the old
behaviour was either obvious, documented or correct.
* Simplify TCP reading in client Conn
This alters the error behaviour in possibly observable ways, though
this is quite subtle and may not actually be readily observable.
Conn.ReadMsgHeader should behave the same way and still returns
ErrShortRead for length being too short.
Conn.Read will no longer return ErrShortRead if the length == 0,
otherwise it should be largely similar.
* Remove redundant error check in Conn.ReadMsgHeader
* Revert "Require URLs for DOH addresses (#684)"
This reverts commit 8ccae88257.
* Revert "WIP: DNS-over-HTTPS support for Client.Exchange API (#671)"
This reverts commit 64746df23b.
Signed-off-by: Miek Gieben <miek@miek.nl>
* Finish revert of DoH
Signed-off-by: Miek Gieben <miek@miek.nl>
* Add back in the race condition comment
Signed-off-by: Miek Gieben <miek@miek.nl>
* Remove redundant parenthesis
These were caught with:
gofmt -r '(a) -> a' -w *.go
This commit only includes the changes where the formatting makes the
ordering of operations clear.
* Remove more redundant parenthesis
These were caught with:
gofmt -r '(a) -> a' -w *.go
This commit includes the remaining changes where the formatting does not
make the ordering of operations as clear as the previous commit.
* ensure dialTimeout is used at Dial time. Ensure dial functions setup the right timeout
* - on Dialing, ensure a dialTimeout for the Dialer only if it is just created, else keep going with parameters of the Dialer.
* Require URLs for DOH addresses
* Move time.Now directly above http.Client.Do in DoH
* Remove https scheme check from DOH
Although the draft RFC explicitly requires that the scheme be https,
this was deemed undesirable, so remove it.
* Add DNS-over-HTTPS support to (*Client).Exchange
* Ignore net/http goroutine leak from DoH
* Use existing Dialer and TLSConfig fields on Client for DOH
* Make DOH http.Client fully configurable
* Pipe context into exchangeDOH
* TSIG name must be presented in canonical form
Update the documentation to make clear that the zonename in the
TsigSecret map must be in canonical form.
* Reference RFC 4034 for canonical form
The response message must copied regardless of whether there was an
error or not, otherwise two concurrent queries may modify the response
as they write it out.
My home router only return 1 byte on the initial tcp read of 2 bytes
for the size of the reply. We should read the other byte as well if this
happen.
With this fix, this:
~~~
% ./q -tcp @192.168.1.1 higgs
;; dns: short read
~~~
becomes:
~~~
% ./q -tcp @192.168.1.1 higgs
;; opcode: QUERY, status: NOERROR, id: 12968
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;higgs. IN A
;; ANSWER SECTION:
higgs. 0 IN A 192.168.1.108
;; query time: 10737 µs, server: 192.168.1.1:53(tcp), size: 44 bytes
~~~
* Remove {un,}packUint{16,32}Msg functions.
unpackUint16Msg unpackUint32Msg packUint16Msg packUint32Msg implemented
functionality that is part of the encoding/binary package.
* Use encoding/binary's encoding in more places.
Remove the use of reflection when packing and unpacking, instead
generate all the pack and unpack functions using msg_generate.
This will generate zmsg.go which in turn calls the helper functions from
msg_helper.go.
This increases the speed by about ~30% while cutting back on memory
usage. Not all RRs are using it, but that will be rectified in upcoming
PR.
Most of the speed increase is in the header/question section parsing.
These functions *are* not generated, but straight forward enough. The
implementation can be found in msg.go.
The new code has been fuzzed by go-fuzz, which turned up some issues.
All files that started with 'z', and not autogenerated were renamed,
i.e. zscan.go is now scan.go.
Reflection is still used, in subsequent PRs it will be removed entirely.
TCP wasn't returning rrt info anymore, fix this. Also add
an issue_test.go where fixes for specific issues can be put.
Pull the rtt for udp message up into the function where we now
also set the rrt for tcp (for symmetry).
We are removing the TLS atributte from Client type. Now if you want to enable
DNS over TLS you should use the value "tcp-tls", "tcp4-tls" or "tcp6-tls" in
Net attribute.
See #297
After some thoughts, I realized that the fallback should be made by who is
using the client, as it will need to change the port (from 853 to 53). This
would also remove from the library the complexity of storing the recursive
nameservers that aren't working well with TLS (draft-ietf-dprive-dns-over-tls,
section 3.1).
See #297
As tlc.Conn is just a TCP connection after the handshake, we will modify the
TCP functions to work with an io.Reader/io.Writer parameter instead of a
net.TCPConn so we can reuse them.
See #297
When starting a TLS connection in some environments, we usually disabled some
certificates checks to allow tests with self-signed certificates. To disable
this checks we need to change some TLS parameters when starting a connection,
and for that we need to inject this parameters in the API.
Now the Client will also have an attribute for the TLS configuration
parameters. For future refactories, we could change the TLS attribute from bool
to a struct that would store the "Enable" flag and the configuration.
See #297
We should allow the client to send requests to a recursive DNS server using a
encrypted connection. This is proposed on the document
draft-ietf-dprive-dns-over-tls [1].
For now we didn't allow the API user to change the TLS configuration (using
defaults). We also need to add the intelligence to fallback to normal DNS when
the TLS connection fails (as described in the draft).
See #297
[1] http://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-02
The current code sets the read deadline at the same time as the write
deadline. If the write nearly times out but doesn't, the read timeout
can fire before the read happens within the specified deadline.