pfSense English Support > DHCP and DNS

DNS lookups failing periodically on VPN VLAN

(1/2) > >>

toluun:
Every so often DNS lookups on my VPN VLAN fail. I don't really know what causes this issue, as I can't consistently repeat the error. When this error occurs I can't make DNS requests but I can ping multiple servers on the internet and the VPN WAN gateway is shown as open. When I try to look at the packets its appears the DNS requests are returning nxdomain which I think may be significant.  The only way I have found to fix the problem is to reset both the open VPN service and unbound (DNS Resolver). 

 
My VPN VLAN is setup to direct all traffic through my VPN WAN (OpenVPN).  The VPN WAN gateway is setup to monitor my VPN services DNS server and shutdown the gateway whenever pings to that server fail. The DNS Resolver is setup for the VPN network and resolving internal names. It is authoritative for my local.lan domain to preventing unneeded leakage of information.  As I believe the DNS Resolver is at fault, I have included a picture of my settings below.





Do you have any thoughts on how I could proceed in troubleshooting the problem?  I have tried using the packet manager tool to look into the packets and all I could find is what I mentioned above, that the DNS requests appeared to be returning nxdomain.  My apologies if I did not provide enough information however it is hard to replicate the error as to do so would require continuously spending time on the VPN VLAN.

toluun:
Just a quick update as I have been doing some more troubleshooting.  I have narrowed down the issue being only with the dns resolver.  Fixing the problem only requires restarting unbound.  Still don't see anything in the logs that would indicate unbound failing.  I also tried adding Service Watchdog to monitor unbound and send me a notification if unbound crashes or stop working whith little success.  The issue has occurred multiple times without any notification of a restart from Service Watchdog.  Any thoughts on anything else I can try?

It may be down to creating a cron job that restarts unbound every hour or so.  Still trying to research the syntax to do that, however I would rather not take this step as it seems a workaround.

toluun:
After a couple more nights of testing I believe I have narrowed down the issue to DNSSEC.  I disabled DNSSEC and have not has any problems since.  Would like to enable DNSSEC so I will continue to look for a solution.

toluun:
Could someone maybe walk me through my resolver logs? I have to say I am thoroughly confused at some of the addresses the replies are coming from.


--- Code: ---Jan 23 21:11:10 unbound 86566:1 info: query response REC_LAME: recursive but not authoritative server
Jan 23 21:11:10 unbound 86566:1 info: mark as REC_LAME
Jan 23 21:11:10 unbound 86566:1 info: response for data.cnn.com. A IN
Jan 23 21:11:10 unbound 86566:1 info: reply from <dsce12.akamaiedge.net.> 69.31.102.177#53
Jan 23 21:11:10 unbound 86566:1 info: query response was ANSWER
Jan 23 21:11:10 unbound 86566:1 info: resolving cnn.com. DS IN
--- End code ---

THe first three lines repeat over and over with variation on the response address and the address the reply is from.  It seems the relevant logs data ends with:


--- Code: ---Jan 23 21:10:15 unbound 86566:1 info: Verified that unsigned response is INSECURE
Jan 23 21:11:05 unbound 86566:1 info: resolving www.cnn.com. A IN
--- End code ---

All these responses are from when cnn.com was actually resolved and I was able to see the page, however seeing the INSECURE has me worried. I have included similar logs for when I unbound fails to resolve a page.


--- Code: ---Jan 23 21:35:46 unbound 86566:1 info: query response was nodata ANSWER
Jan 23 21:35:46 unbound 86566:1 info: response for n5g.akamaiedge.net. AAAA IN
Jan 23 21:35:46 unbound 86566:1 info: reply from <akamaiedge.net.> 184.26.161.192#53
Jan 23 21:35:46 unbound 86566:1 info: query response was nodata ANSWER
Jan 23 21:35:46 unbound 86566:1 info: response for n2g.akamaiedge.net. AAAA IN
Jan 23 21:35:46 unbound 86566:1 info: reply from <akamaiedge.net.> 95.101.36.192#53
Jan 23 21:35:46 unbound 86566:1 info: query response was nodata ANSWER
Jan 23 21:35:46 unbound 86566:1 info: response for www.nhl.com. A IN
Jan 23 21:35:46 unbound 86566:1 info: reply from <g.akamaiedge.net.> 88.221.81.192#53
Jan 23 21:35:46 unbound 86566:1 info: query response was ANSWER
Jan 23 21:35:46 unbound 86566:1 info: resolving nhl.com. DS IN
--- End code ---

Once again it appears to end with


--- Code: ---Jan 23 21:35:10 unbound 86566:1 info: NSEC3s for the referral proved no DS.
Jan 23 21:35:10 unbound 86566:1 info: Verified that unsigned response is INSECURE
Jan 23 21:35:16 unbound 86566:1 info: resolving www.nhl.com. A IN
--- End code ---

At this point I am probably stuck with disabling DNSSEC as I probably just do not have enough knowledge to fully understand what is causing unbound to stop working (but not crashing).  I will stop spamming this thread now.

Gertjan:

--- Quote from: toluun on January 23, 2018, 08:29:06 pm ---At this point I am probably stuck with disabling DNSSEC as I probably just do not have enough knowledge to fully understand what is causing unbound to stop working (but not crashing).  I will stop spamming this thread now.

--- End quote ---
It's the other way around : you should keep DNSSEC enabled.
cnn.com, as many if not the most sites on the net use the classic DNS without DNSSEC - so, from a "DNSSEC-check" point of view, the answers to DNS request are unsecured. But that's ok.
Because the entire DNS, as it works for many years already, is very not secure. "DNS spoofing" really happens these days.

Btw : even forum.pfsense.org doesn't use DNSSEC  ;)

Navigation

[0] Message Index

[#] Next page

Go to full version