-bash: ./configure No such file or directory

Also, there appears to be another issue. I was only able to compile with quic support using the older TLS versions, I was not able to compile unbound using OpenSSL 3.0.15+quic or OpenSSL 3.3.0+quic. Instead I had to use an older branch https://github.com/quictls/openssl/releases/tag/OpenSSL_1_1_1w-quic1 .

Thank you for the additional details, the documentation was updated with newer instructions. Not sure if a blog should be updated. It is nice to hear that it works with the latest ngtcp2 version, at the time the function calls changed rapidly, so I wanted to fixate the version used for the test instructions.

For the compile issue with openssl, it works fine for me with openssl 1.1.x+quic and also openssl 3.0.x+quic when I tested those. I have no clue what is causing the failure for the compile.

Thank you for the additional details, the documentation was updated with newer instructions. Not sure if a blog should be updated. It is nice to hear that it works with the latest ngtcp2 version, at the time the function calls changed rapidly, so I wanted to fixate the version used for the test instructions.

For the compile issue with openssl, it works fine for me with openssl 1.1.x+quic and also openssl 3.0.x+quic when I tested those. I have no clue what is causing the failure for the compile.

@wcawijngaards
Maybe it is something specific in the compile instructions that causes the error. I will play around with it some more to see if I can figure it out. One thing I am good at is tinkering, I will reach back out to you when I have new information, stay tuned.

@wcawijngaards I don't know if this helps any.

The output seems to suggest that the library in the directory cannot be linked with. That is perhaps why all the -lcrypto tests fail. In the file config.log there is verbose output, including the compiler command, the program, and the output of the compiler with the compile failure. Look in that file and find the output of the -lcrypto tests, like the EVP_sha256 check. Likely that compiler output there can explain what is causing the failure.

@wcawijngaards thank you for updating the documentation.

One other issue I noticed with DoQ is that testing worked OK on the server where Unbound is installed, but on another machine, I got the following error:

failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.

On that machine, I had to increase the memory buffer, either temporarily with:

sudo sysctl -w net.core.rmem_max=8388608
sudo sysctl -w net.core.wmem_max=8388608

or permanently with:

cat <<EOF>50-custom-membuff.conf
# Increase the read and write memory buffers
net.core.rmem_max=8388608
net.core.wmem_max-8388608
EOF
sudo mv ./50-custom-membuff.conf /etc/sysctl.d

Otherwise, it works great!

Nice to hear that things are working! The message that is quoted is, I assume, from the client implementation. It is interested to hear. Unbound has so-rcvbuf: 8m and so-sndbuf: 8m configuration options in unbound.conf, if you want similar settings it is possible to increase them with configuration there. This is applied to the doq socket for Unbound.

The value of 4m is suggested in unbound documentation for traffic spikes on busy servers. If unbound fails to increase the buffer size that would be in unbound logs. On Linux, there is code in unbound where it uses the root permissions, that the server is frequently started with, to bypass those kernel limits and set the buffer size requested. So it may not be necessary to update the system buffer size limits in that situation.