Bug #11457
closed
Client DNS doesn't resolve when using VIP in place of interface IP
0%
Description
"My inside interface is set to 192.168.1.1 and I created a VIP on .254. When I set a client device to use .254 as the gateway, I can verify the traceroute to the internet and connectivity to the internet is verified.
The problem is when I set the client device to use the VIP as the DNS host. No responses come back. All DNS entries fail to resolve. If I use nslookup and alternate between .1 (inside interface) and .254 (inside VIP) for queries, .1 always works and .254 always fails."
my test:
# dig a netgate.com @192.168.88.44 ;; reply from unexpected source: 192.168.88.41#53, expected 192.168.88.44#53
192.168.88.41 - LAN IP, 192.168.88.44 - LAN CARP VIP
it's better to hide all VIPs from the DNS Resolver "Network Interfaces" list
Updated by Viktor Gurov almost 4 years ago
Updated by Travis McMurry almost 4 years ago
The bug is the "All" Network Interface isn't including VIPs. If I manually select all of the network interfaces (except "All") then save & apply, DNS works on the VIP. When I go back to using "All", the VIP stops responding to DNS.
The bug is 100% repeatable.
Workaround: Manually select each network interface DNS should respond to.
I also realize it's possible to do a NAT Port Forward as a workaround. If the path is taken to hide VIPs from DNS Resolver, it would be very helpful if the documentation & UI were updated to remark VIP handling behavior and make a recommendation. Without any kind of documentation to indicate this is how VIPs are handled or UI guidance, I would assume "All" means all, and I would have no context to guess why a VIP is missing from the Network Interface list.
Basically, if I trust the docs to be accurate as of the time of this writing, then DNS Forwarder has a "bug" that needs to get fixed. If the documentation is not accurate and VIPs should never be listed in DNS Forwarder, and the docs need to be updated to reflect this reality and also mention the NAT Port Forward as a supported alternative.
Updated by Jim Pingle almost 4 years ago
- Status changed from New to Rejected
"All" works fine for me here in an HA setup with CARP. Clients query the CARP VIP and receive responses from the CARP VIP.
Set to 'All' => OK
Set specific Interfaces and VIPs => OK
Set back to 'All' => Still OK
You must have some other setting contributing or a flaw in your testing methodology.
Keep the discussion on the forum until a more accurate description can be defined.
Updated by Jim Pingle almost 4 years ago
After working on the forum thread, this is due to the "Enable SSL/TLS Service" setting which requires unbound have interfaces-automatic: no set. Using no there means it cannot automatically set the proper source on replies, and setting yes prevents unbound from binding to the TLS port.
We can't easily add input validation to prevent this combination since a user may want to use All and doesn't care about using the DNS resolver on the VIPs for example.
We already have a warning under the SSL/TLS option about response routing behavior but perhaps it needs to be stronger.