| Age | Commit message (Collapse) | Author |
|---|
|
This is to minimize lookup on map each time we need the string
representation.
|
|
The log level cache changed to the following format,
... {MSG_ID QNAME TYPE TTL} ...
where MSG_ID is the message ID, QNAME is the question name, TYPE is the
type of question, and TTL is the time-to-live of the answer.
This changes require adding field TTL to Answer and exporting the field
Message.
|
|
For each logged request, there should be one line of response logged,
success or fail.
This changes remove redundant log "^" (request forwarded) and
"~" (answer is expired).
The final log would be only "+" (new answer cached), or "#" (answer
updated), or "!" (error).
|
|
With help of spdxconv tool [1], we able to bulk update all files license
and copyright format to comply with SPDX formats.
[1] https://kilabit.info/project/spdxconv/
|
|
Using ":=" simplify the code but we lose the type. For example,
v := F()
The only way we know what the type of v is by inspecting the function
F.
Another disadvantages of using ":=" may cause extra variables
allocation where two or more variables with same type is declared
inside body of function where it could be only one.
While at it, we split the struct for test case into separate type.
|
|
|
|
Using the fieldalignment, we got the following output,
answer.go:15:13: struct with 56 pointer bytes could be 24 = 32 bytes
caches.go:27:13: struct with 24 pointer bytes could be 16 = 8
dot_client.go:20:16: struct with 16 pointer bytes could be 8 = 8
hosts_file.go:24:16: struct with 64 pointer bytes could be 48 = 16
message.go:53:14: struct of size 176 could be 168 = 8
rdata_mx.go:20:14: struct with 16 pointer bytes could be 8 = 8
rdata_opt.go:18:15: struct with 16 pointer bytes could be 8 = 8
rdata_srv.go:16:15: struct with 64 pointer bytes could be 56 = 8
rdata_wks.go:30:15: struct with 40 pointer bytes could be 32 = 8
request.go:20:14: struct with 32 pointer bytes could be 24 = 8
resource_record.go:24:21: struct with 56 pointer bytes could be 40 = 16
server.go:76:13: struct with 120 pointer bytes could be 112 = 8
server_options.go:20:20: struct of size 240 could be 224 = 16
tcp_client.go:21:16: struct with 40 pointer bytes could be 24 = 16
udp_client.go:24:16: struct with 24 pointer bytes could be 16 = 8
udp_client_pool.go:25:20: struct with 24 pointer bytes could be 16 = 8
zone_file.go:22:15: struct with 128 pointer bytes could be 120 = 8
zone_parser.go:53:17: struct with 88 pointer bytes could be 72 = 16
Turns out the struct that we frequently used, answer and resource_record,
is not optimized.
This changes reorder all structs field to save space in memory.
|
|
This field is used for storing the actual DNS packet after Message.Pack
has been called.
|
|
|
|
Previously, we need the UDP address of client to write back response to
client on UDP connection and http ResponseWriter to write back response
to client of DoH connection.
This changes simplify the sender using io.Writer.
On UDP connection, writer is an instance of UDPClient with
connection reference to UDP server and with peer address.
On TCP connection, writer is a TCP connection from accept.
On Doh connection, writer is http ResponseWriter.
|
|
Since the caches and forwarding now is handled internally, and Request
has been unexported, there is no need for exporting the connection type
anymore.
|
|
Since the caches and forwarding now is handled internally, there is no
need for exporting the request anymore.
|
|
This is to limit implementation to assign value of connection type to
known values only.
|
|
The kind value indicate from which connection the request is coming from.
If Kind is UDP, Sender and UDPAddr must be non nil.
If Kind is TCP, Sender must be non nil
If Kind is DoH, both Sender and UDPAddr must be nil and ResponseWriter
and ChanResponded must be non nil and initialized.
|
|
Previously, we have request pooling but it does not work well (causing
data race) when handling DoH request.
This commit reimplement them back by adding http ResponseWriter and a
channel to notify response has been written, to request fields.
|
|
Since implementation of DNS over HTTP, the request contains channel for
waiting response from DNS server. The channel message cause data race
due to request can be closed on the other side (handler of DNS request).
For temporary fix, we disable request pooling until we found the simple
way to manage DoH response.
|
|
The implementation is based on latest draft [1].
[1] https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-14
|
|
|
|
|
|
|
