forward-host not working
#1165
Comments
|
the forward-host is written exactly like the forward-addr with an upstream like Adguard dns and other upstream servers. forward-zone: Once you have added it to your unbound config, restart the unbound service with service unbound restart and then check with: service unbound status whether there are any errors. |
|
@Aura67
The name of the server is the domain, not the IP address. And as you can see in the log, it tries so resolve the address of the domain. So that does work as written. If |
|
it makes sense in the unbound wiki it says that you can use # @ and enter the name of the upstream server like that and I use it like that myself and my unbound resolves exactly the name that I specified. but here the part from the wiki: Name of server to forward to. Is itself resolved before it is used. To use a non-default port for DNS communication append '@' with the port number. If TLS is enabled, then you can append a '#' and a name, then it’ll check the TLS authentication certificates with that name. If you combine the '@' and '#', the '@' comes first. If only '#' is used the default port is |
|
@Aura67 The whole purpose of Thanks for trying to help but I'll wait for a member to respond here. |
|
See info on Ad-Guard public DNS.
I think you used the wrong IP-address? Also, I think you have a typo in the tls domain name used in your |
|
@sunbearc22 I understand that everyone is just trying to help but please don't just type the first thing that comes to your head.
Again, you seem to misunderstand the issue. The whole issue is about using Let's just wait for someone from the team to respond here, please. |
|
I had the same Issue. As a workaround I created a second forward host which only matches the hostname of the dns server I want to use and set there forward-addr |
|
Indeed, as @Zoey2936 said using |
|
@gthess Do you think this is something that should be solved in the code so this works without the mentioned workaround? |
|
Not sure because it would need explicit permission to bypass the configuration, as in don't forward certain queries and instead resolve yourself. The issue is about forwarding "." which is a special case by itself but it shouldn't impact generic configuration. I'll bring it up with the team if that is something we would like to change. In general the current practice if you forward the root is to specify IP addresses to avoid the chicken-egg problem. I also don't understand the workaround because I believe it is the same as using forward-addr in the first place, unless I misread something. |
|
my workarround looks like this: I use 1.1.1.1 in the first forward-zone if I'm outside of my LAN, but I need 192.168.168.1 inside my LAN, because I block port 53/853 outgoing on udp/tcp in my LAN. so it first tries to resolve the forward-host using "default" unbound resolving using root dns server and if it fails (which it would do in my LAN) it would use |
|
I hope you understand what I mean. I edited my last message a bit |
|
I understand and thanks for sharing configuration, but I think the specific |
|
sorry, but I think I don't understand exactly what you mean |
|
@Zoey2936, in your home network the 1.1.1.1 address does not work and Unbound eventually will note that in its infrastructure cache. If you now change networks and Unbound knows that 192.168.168.1 is the only nameserver that works for the This is however theoretical and in reality it should not happen because it all relies on the TTL of the But in a more practical note, issuing Another small thing to note about the |
|
Thanks for the explanation! |
I think there might be a problem with
forward-host. It never works and returnsSERVFAIL.Setup: I tried 1.20.0 and 1.22.0
Tested with
dig @127.0.0.1 heise.deResponse:
Here is the log:
Note that it does work, if I comment the host and uncomment the addr.
The text was updated successfully, but these errors were encountered: