| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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/
|
|
|
|
In RFC 1035 there is no clear definition whether origin end with dot or
not. The only explanation is on page 33.
... Domain names that end in a dot are called
absolute, and are taken as complete. Domain names which do not end in a
dot are called relative; the actual domain name is the concatenation of
the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
an argument to the master file loading routine.
Also, most of examples that we found use dot for terminating origin.
|
|
Previously, the indexed caches for internal (records from hosts or zone
files) and external (records from parent name servers) are stored inside
single map.
This changes split those internal and external caches into two maps,
so any operation on one caches does not affect the other one, and vice
versa.
|
|
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.
|
|
Previously, the record class is represented by uint16 using prefix
QueryClassXxx.
This changes make the record class to be an independent type, to make
code more strict (prevent passing invalid value), and readable.
|
|
Previously, we use uint16 to represent type for ResourceRecord Type or
Question type.
To make the code more strict, where parameter or return value, must be
expected as record type, we add new type to represent the RR type:
RecordType.
This changes also rename any variable name of QType or qtype to RType
or rtype because QType is misleading. The type defined the
ResourceRecord to be queried not only question.
|
|
|
|
The CachesLRU method return the list of non-local caches ordered by
the least recently used.
This changes affect the answer type which must be exported, including
most of its fields, so consumer can access it.
|
|
This field is used for storing the actual DNS packet after Message.Pack
has been called.
|
|
|
|
This fix TTL on non local answer that is never changed when requested
several times by client.
|
|
As long as the response is OK (response code 0), we should accept response
with no answer RR. One of the case is when query is AAAA and the domain
does not have IPv6 address, it would response with empty answer with
response code OK.
|
|
There are two type of answer: local and non-local.
Local answer is a DNS record that is loaded from hosts file or master
zone file.
Non-local answer is a DNS record that is received from parent name
servers.
Server caches the DNS answers in two storages: map and list.
The map caches store local and non local answers, using domain name as a
key and list of answers as value,
domain-name -> [{A,IN,...},{AAAA,IN,...}]
The list caches store non-local answers, ordered by last accessed time,
it is used to prune least frequently accessed answers.
Local caches will never get pruned.
|
