* Modify the SVCBAlpn to properly parse/print
* Remove debug
* Change SVCB test from reflect to loop
* Refactor SVCB code to reduce indentation
* When stringifying SVCBAlpn, use strings.Builder for whole process
* Update comment in svcb.go
Co-authored-by: Miek Gieben <miek@miek.nl>
* Describe why we use a specific size for the alpn buffer
Co-authored-by: Miek Gieben <miek@miek.nl>
* Add SVCB dohpath key
The parameter is being added in [its own IETF draft][1] and also being used in
the [IETF draft about Descovery of Designated Resolvers][2].
Additionally, the mappings of the numeric key values to strings are exported,
under names consistent with the already existing exported mappings, to make it
easier for the clients of the module to validate and print SVCB keys.
Testing was done by sending SVCB queries for the "_dns.resolver.arpa" domain to
OpenDNS's 146.112.41.2 server.
[1]: https://datatracker.ietf.org/doc/html/draft-ietf-add-svcb-dns-02
[2]: https://datatracker.ietf.org/doc/html/draft-ietf-add-ddr-06.html
* Fix template length, docs; reverse some changes
* Remove incorrect validations; improve docs
Of course the wording was changed (for the better) in an errata:
https://www.rfc-editor.org/errata/eid193
We still followed the original RFC4034 text. Note I haven't given this
much thought, just changed the 2 into a 3 and ran the test.
Fixes: #1352
Signed-off-by: Miek Gieben <miek@miek.nl>
* Invalid NSEC/3 bitmap on non-zero buffer
If the PackBuffer is used to encode an NSEC/3 record, the bitmap is
xored with the content of the buffer instead of being zeroed first.
The algorithm has been changed so it is able zero bytes without
losing too much performance (around 2x slower).
* Add some comments + rename some vars to make algo clearer
* Revert to previous algo with window length compute+0 on new window
* Use typeBitMapLen to compute the bitmap length to zero
* Change EDNS_EXPIRE field to support zero length option data (Resolves#1292)
As per [RFC7134](https://datatracker.ietf.org/doc/html/rfc7314#section-2) the Expire
Option in queries should be zero-length. In the current implementation the field is
uint32 which always instatiates 4bytes for that field when packing to wire format.
For that reason we change the field to []uint8 so it can support 0-length and 4-byte
length option data.
* addressed comments
* addressed comments
* make change backwards compatible
* add comment for Empty field
This adds hash.go and creates a identityHash that is used for algorithms
that do their own hashing (ED25519) for instance.
This unifies the hash variable naming between dnssec and sig(0) signing
and removes the special casing that existed for ED25519.
This unifies the variable naming between sig(0) and dnssec signing and
verifying.
I didn't want to used crypto.RegisterHash as not to fiddle with the
global namespaces of hashes, so the value of '0' from AlgorithmsToHash
is handled specially in dnssec and sig(0) code.
Note that ED448 isn't implemented at all.
Signed-off-by: Miek Gieben <miek@miek.nl>
Using Exchange doesn't add anything, as it just wraps client.Exchange
with a default client.
Remove them and speed up the tests, goes from 3s to 1s (for the entire
test suite).
Signed-off-by: Miek Gieben <miek@miek.nl>
* Refactor net.PacketConn checks into helper function
* Only treat a *net.UnixConn of unixgram as a packet conn
* Handle wrapped net.Conn types in isPacketConn
* Use Error instead of Fatal where appropriate in TestIsPacketConn
* Fix un/packing of EDNS0 TCP keepalive extension
The current code is assuming the OPT code and length are part of the
data passed to the unpacker and that it should be appenedded during
packing while those fields are parsed by the caller.
This change fixes the parsing and make sure a request with a keepalive
won't fail.
* added tests for EDNS0_TCP_KEEPALIVE pack/unpack
* mark Length as deprecated
* removed named returns
* restored String
Co-authored-by: Olivier Poitrey <rs@rhapsodyk.net>
* Per RFC 8945 5.3.2, responses with BADKEY and BADSIG errors must not be signed.
Signed-off-by: Chris O'Haver <cohaver@infoblox.com>
* refactor to remove else block
Signed-off-by: Chris O'Haver <cohaver@infoblox.com>
* skip signing only for BADKEY and BADSIG
Signed-off-by: Chris O'Haver <cohaver@infoblox.com>
* Fix go generate missing required go.mod entry
There were no non-excluded files importing golang.org/x/tools so it's
require was missing from go.mod. This caused the go run commands
invoked by go generate to fail.
tools.go is currently the recommended way to force non-build
dependencies to be retained by the go mod commands. If that changes in
the future, we can update then. As nothing from the import is actually
used, it won't impact anyone's build at all (except requiring an extra
download by the go tool which is unavoidable).
Pulling in the @master version of golang.org/x/tools (which doesn't yet
have a stable release version) also updates a number of other
dependencies, but not quite to latest, so while I'm here just update
them all.
* Add explanatory comment and build tag to tools.go
Make it more obvious that these two lists (const, and case) need to be
in sync.
Also sort the list to match the const sorting.
Signed-off-by: Miek Gieben <miek@miek.nl>
When decoding a HIP resource record, 'base64.StdEncoding.DecodedLen' can return a length larger than the length of the decoded public key. This change decodes the public key and retrieves the correct length. In our tests, the public key length was being set to 33, instead of 32. Below is our offending resource record:
'23b5993f649c0827.a.b.c. 3600 IN HIP 5 200100100020001523B5993F649C0827 Cm6k4jhir9YYoKq9JDqD3Ob1hBfCuwbWam1igFPhkGg='
The existing of the file signifies it needs to run, so now it errors
that there is nothing to run (everything is commented out).
Remove the entire file.
Signed-off-by: Miek Gieben <miek@miek.nl>
Go 1.11 was a long time ago, so rename the reuseport go files to
something more sane. Contemplated _unix, or _posix but that didn't
really cut it. Went with reuseport and no_reuseport.
Also bump go.mod to 1.14
Signed-off-by: Miek Gieben <miek@miek.nl>
* Fix copy() in SVCBIPv4Hint and SVCBIPv6Hint
The problem with the current implementation is that it is not a real deep copy,
it points to the same base arrays behind the slices. This was causing some
issues in real-life application.
* Address review comments
* Remove HmacMD5 from the documention
The aglo is deprecated.
Signed-off-by: Miek Gieben <miek@miek.nl>
* bump to sha256
Signed-off-by: Miek Gieben <miek@miek.nl>