doq bug #1185
Comments
|
Unbound has a chroot feature, and it is enabled by default. In the log it also has logged that it chrooted, to For the rest it looks okay. It is starting doq service on 854. |
I copied the certificate file to the /usr/local/etc/unbound folder and the problem persisted |
|
Unbound will still look for the whole path inside the chroot. You now have two different options. You either:
Both options have the same effect; Unbound will expect to find the |
After testing the two methods you gave with DOQ enabled, the bug still exists. But it is normal to turn on DOT alone.
|
|
But it is normal to turn on DOT alone.
|
|
I see the issue. That will work for DoT which reads the files before the chroot, and also for DoQ which reads the files after the chroot. I believe the correct solution to this is to create the DoQ TLS context also before the chroot is applied for consistency with the other TLS options. |
|
|
The only solution at the moment is to disable chroot, that is, add |
|
Did you copy the files in |
here，But the problem remains. dot is normal, but the problem is doq
|
|
I could reproduce the issue when hitting the chroot problem, but with the following minimal configuration it works for me here with and without chroot. The key.key and crt.crt files are in the chroot directory. I see that you have a couple configuration files. Just to rule it out, can you make sure you are using the correct one? |
I run it according to the configuration you gave, but the problem still exists. I only have one configuration, and the file name with -t is used by me to test this problem separately, otherwise I will be disconnected from the Internet. |
|
I am running out of ideas; not sure what is different in your case now. |
|
|
I assume Unbound drops privileges and uses user should solve it. |
privilege drop, just like the other SSL_CTX creations.
My unbound uses root privileges. I executed sudo chown root:root key.key crt.crt, but the same error message still appears. |
|
Could you show the current error message? |
|
|
|
Unbound complains that user Apart from that can you also paste the output of the following commands? |
|
|
I changed username: "" but still have the same problem |
|
You need to configure: |
I have tested it. It does not work properly. |
|
I am really confused. And your latest output mentions (emphasis mine): The first output fails when it tries to create the DoQ ssl context. This happens after the chroot and privilege drop. The second output fails when it tries to create the listening ssl context. This happens before the chroot and privilege drop. Looking at the outputs, for the first one if you would replace the filename to just crt.crt it would have worked. For the second one I am not sure what is happening anymore. Having both of those outputs does not make sense and it indicates that something is going wrong between invocations and the configuration. In the future could you please always paste the configuration you are using together with the whole log output? |
This is my configuration. I just changed a few ports and certificate paths. If you don’t believe me, you can compile a test yourself. |
|
Testing this doq bug will cause my dns to be completely interrupted, so I copied a separate copy for testing. During the test, I also modified some configurations but could not solve the problem. The only way to solve this problem is to disable chroot:"" |
|
It's not that I don't believe you, it's just that with all the changes in the configuration file I want to be certain how Unbound complains for a given configuration :) With the above configuration you pasted, changing the filenames to just key.key and crt.crt (so that they are relative paths to the current directory) works with both chroot enabled and disabled. I just tried it locally. I am not sure why Unbound reports that the files are not there. |
#######################################################
The text was updated successfully, but these errors were encountered: