Unbound - Authoritative Recursive Caching DNS Server

[vesalius]

dns64
This option has been widely discussed in the IPV6 unbound forums. For me, it works perfectly.

I will admit my ignorance and that a quick google search was less than satisfactory for me. Would you mind posting a link to this forum for those of us that would like to read up on this?

 

[L&LD]

https://www.google.ca/search?source...hUKEwjEmPS90b3nAhX_FzQIHfVbDRgQ4dUDCAg&uact=5

 

[rgnldo]

I will admit my ignorance and that a quick google search was less than satisfactory for me. Would you mind posting a link to this forum for those of us that would like to read up on this?

One of the major problems in automatically enabling IPV6 on devices is the fact that it depends on the ISP's infrastructure. Quality services are not always available. As a precaution, IPV6 has been disabled.
When enabled, it is possible (today with fewer) to encounter problems with some streaming services etc. You can check this here: dns64 Initial IPV6

 

[rgnldo]

What is the reason for deleting the log file when updating the adblock/unbound, simple: the way we organize the verbosity 2 generates a large file and difficult to analyze after updating the adblock lists. It turns out that the adblock list maintainers are difficult to trust, they end up detonating the script's operation with its updates. verbsity 1 is correct, with only operational log´s or verbosity 0 for errors only. So the user will know the problem.
I'm not a guy who masters the ´sed´ command, use adblock/unbound if you really have basic knowledge of linux and shell script.
The reason for organizing adblock/unbound was not to compete with Divertion, but to provide a complete unbound experience. For me it is fantastic.

 

[L&LD]

@Martineau I am finding many issues with the new IPv6 defaults, specifically this one.

 #module-config: "validator iterator"
    module-config: "dns64 validator iterator"  # v1.01 perform a query against AAAA record exists
    dns64-prefix: 64:FF9B::/96

The issues are not just a slower connecting OpenVPN connection because it is trying IPv6 addresses first as previously posted above. At least the OpenVPN connection eventually goes live and usable.

Here is what I have seen so far:

• Outlook, Spotify, OneDrive, Dropbox, Skype, and many other such services either do not load at all or load even slower than the OpenVPN client example above (sometimes half an hour and still not connected).
• The 'Your Phone' program in Windows 10 doesn't connect at all, even with a computer left on overnight.
• The 'Fitbit' connections fail from watch to phone (Android) app. The watch cannot connect at all.

I would like to suggest that the 'dns64-prefix: 64:FF9B::/96' option be selectable in the 'i' command instead of being automatically applied if that makes sense of course.

Other than this ('almost' showstopper), the v2.05 Unbound_manager release seems to be working well.

Thanks again.

Edit: This is kind of funny. Another issue is that websites will randomly switch language with the 'dns64-prefix: 64:FF9B::/96' option set, while browsing from one link to another within the same site. Funny at first. Gets old real fast.

 

[JemTheWire]

I have been having trouble with the System Log page. Whenever I entered that page, my router would become VERY slow to respond.

I did have Scribe and uiScribe installed. I found the only way to get the router to perform again was to uninstall both.

Now that I have, System Log is as fast as it should be with no GUI slow downs. Is there a way to have Scribe and uiScribe back with out slowing down the GUI?
I did try to remove loging in Unbound but the Unbound log tab always remains in the System Log page.

 

[Kingp1n]

@Martineau I am finding many issues with the new IPv6 defaults, specifically this one.

 #module-config: "validator iterator"
    module-config: "dns64 validator iterator"  # v1.01 perform a query against AAAA record exists
    dns64-prefix: 64:FF9B::/96

The issues are not just a slower connecting OpenVPN connection because it is trying IPv6 addresses first as previously posted above. At least the OpenVPN connection eventually goes live and usable.

Here is what I have seen so far:

• Outlook, Spotify, OneDrive, Dropbox, Skype, and many other such services either do not load at all or load even slower than the OpenVPN client example above (sometimes half an hour and still not connected).
• The 'Your Phone' program in Windows 10 doesn't connect at all, even with a computer left on overnight.
• The 'Fitbit' connections fail from watch to phone (Android) app. The watch cannot connect at all.

I would like to suggest that the 'dns64-prefix: 64:FF9B::/96' option be selectable in the 'i' command instead of being automatically applied if that makes sense of course.

Other than this ('almost' showstopper), the v2.05 Unbound_manager release seems to be working well.

Thanks again.

Edit: This is kind of funny. Another issue is that websites will randomly switch language with the 'dns64-prefix: 64:FF9B::/96' option set, while browsing from one link to another within the same site. Funny at first. Gets old real fast.

Yes I noticed Twitter feeds take a while to load as well. I never figured out the nest app issue so I'm back to built DoT...will continue to monitor.

 

[L&LD]

@JemTheWire simply go to uiScribe and 'exclude' the unbound log file.

This will make System Log usable again.

Also, you have updated to v2.05 of the unbound script, correct?

Last thing: see the post below where I've quoted @Martineau. 'i' doesn't do a 'fresh' install, it merely adds options. So running 'i' without logging still leaves the logging enabled.

https://www.snbforums.com/threads/u...-caching-dns-server.58967/page-57#post-547925

 

[JemTheWire]

Thanks. I didn’t know I could exclude logs in uiScribe. Yes I have updated to v2.0.5

Thanks for the info.

I’m calling it a day now, need to ‘unwind’ before bed. Ha.

 

[Treadler]

@Martineau I am finding many issues with the new IPv6 defaults, specifically this one.

 #module-config: "validator iterator"
    module-config: "dns64 validator iterator"  # v1.01 perform a query against AAAA record exists
    dns64-prefix: 64:FF9B::/96

The issues are not just a slower connecting OpenVPN connection because it is trying IPv6 addresses first as previously posted above. At least the OpenVPN connection eventually goes live and usable.

Here is what I have seen so far:

• Outlook, Spotify, OneDrive, Dropbox, Skype, and many other such services either do not load at all or load even slower than the OpenVPN client example above (sometimes half an hour and still not connected).
• The 'Your Phone' program in Windows 10 doesn't connect at all, even with a computer left on overnight.
• The 'Fitbit' connections fail from watch to phone (Android) app. The watch cannot connect at all.

I would like to suggest that the 'dns64-prefix: 64:FF9B::/96' option be selectable in the 'i' command instead of being automatically applied if that makes sense of course.

Other than this ('almost' showstopper), the v2.05 Unbound_manager release seems to be working well.

Thanks again.

Edit: This is kind of funny. Another issue is that websites will randomly switch language with the 'dns64-prefix: 64:FF9B::/96' option set, while browsing from one link to another within the same site. Funny at first. Gets old real fast.

Using 2.04, which appears to include the “dns 64”, my internet slowed over a few hours, then suddenly broke.
I had WAN, & wifi ok, but couldn’t go anywhere. I ‘assume’ resolving broke, or was at least horrendously slow?

So, I had to get my network back quickly, uninstalled Unbound, gone back to a vanilla public resolver + dnssec setup.

Can anyone advise, if I install Unbound & just enter through all the options, accepting none, will ipv6 work ok?

 

[L&LD]

@Treadler, things did break for me (see posts above), but I could still surf.

I would suggest you update to v2.05 first.

Then, using WinSCP or similar, remove this part:

module-config: "dns64 validator iterator"  # v1.01 perform a query against AAAA record exists
    dns64-prefix: 64:FF9B::/96

And also delete the '#' in front of the part right above the above code.

#module-config: "validator iterator"

Do these edits in unbound.conf which you should be able to find in /opt/var/lib/unbound.


Reboot your router.

 

[Smokey613]

I have tried several times to enable IPv6 but continued to have “issues”. I do not think my ISP has a good handle on it. I finally decided to disable it on my router and things are now running smoothly.

 

[Treadler]

I have tried several times to enable IPv6 but continued to have “issues”. I do not think my ISP has a good handle on it. I finally decided to disable it on my router and things are now running smoothly.

Works fine with my ISP.
(I believe they had huuuuge problems implementing it originally though)

 

[Treadler]

@Treadler, things did break for me (see posts above), but I could still surf.

I would suggest you update to v2.05 first.

Then, using WinSCP or similar, remove this part:

module-config: "dns64 validator iterator"  # v1.01 perform a query against AAAA record exists
    dns64-prefix: 64:FF9B::/96

And also delete the '#' in front of the part right above the above code.

#module-config: "validator iterator"

Do these edits in unbound.conf which you should be able to find in /opt/var/lib/unbound.


Reboot your router.

Thanks for that, I might hold off for now, & see how things develop.

 

[rgnldo]

It turns out that depending on how you organize your settings, they even hinder the firmware with nothing. That is why I am in favor of scripts or even firmware detecting users' mistakes. For my use, working perfectly, version Merlin beta 1. Best experiences so far.
I tested all scenarios with IPV6, VPN, streaming's, UPNP, airplay, samba etc ... Simply stable and with excellent performance. Better smooth!!

P.S .: and still organizing the Suricata in a light way, without consuming, in a light way.

 

[joe scian]

anyone see these in log when Unbound logging enabled?

Feb  7 16:34:05 RT-AC5300-0680 kernel: net_ratelimit: 326 callbacks suppressed
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:17 RT-AC5300-0680 kernel: net_ratelimit: 160 callbacks suppressed
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow

 

[kernol]

anyone see these in log when Unbound logging enabled?

Feb  7 16:34:05 RT-AC5300-0680 kernel: net_ratelimit: 326 callbacks suppressed
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
Feb  7 16:34:05 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow
....
Feb  7 16:34:17 RT-AC5300-0680 kernel: TCP: time wait bucket table overflow

Not seen anything like it in my logs - and have been running unbound with logging for several days.

May have nothing to do with unbound ... see here ...
https://www.snbforums.com/threads/c...wait-bucket-table-overflow-on-rt-ac68u.46242/

and here
https://www.snbforums.com/threads/system-log-question.44570/

 

[joe scian]

Not seen anything like it in my logs - and have been running unbound with logging for several days.

May have nothing to do with unbound ... see here ...
https://www.snbforums.com/threads/c...wait-bucket-table-overflow-on-rt-ac68u.46242/

and here
https://www.snbforums.com/threads/system-log-question.44570/

thanks - looks like it was a leftover from downloading torrents last night. rebooted my laptop and all is well with unbound logging enabled. Cheers

 

[Treadler]

@Treadler, things did break for me (see posts above), but I could still surf.

I would suggest you update to v2.05 first.

Then, using WinSCP or similar, remove this part:

module-config: "dns64 validator iterator"  # v1.01 perform a query against AAAA record exists
    dns64-prefix: 64:FF9B::/96

And also delete the '#' in front of the part right above the above code.

#module-config: "validator iterator"

Do these edits in unbound.conf which you should be able to find in /opt/var/lib/unbound.


Reboot your router.

Thanks for that!
Reinstalled Unbound (2.05) from the beginning.
Pressed ‘enter’ (no) on every option offered.
All working well many hours later.

Updated customise cpu/memory option, then:
Deleted the “dns64 validator integrator” portion, plus the “#” preceding the “module-config: validator interator”.
Restarted Unbound (rs).
So far, so good........

 

[rgnldo]

Performance check, network TOR, VPN, DNS leak and unbound cache. Working really well.

Spoiler: Log's network TOR

[1581069749] unbound[12272:0] info: resolving www.youtube.com. AAAA IN
[1581069749] unbound[12272:0] info: query response was REFERRAL
[1581069749] unbound[12272:0] info: resolving . DNSKEY IN
[1581069749] unbound[12272:0] info: query response was ANSWER
[1581069749] unbound[12272:0] info: resolving com. DNSKEY IN
[1581069749] unbound[12272:0] info: query response was REFERRAL
[1581069749] unbound[12272:0] info: response for com. DNSKEY IN
[1581069749] unbound[12272:0] info: reply from <com.> 192.52.178.30#53
[1581069749] unbound[12272:0] info: query response was ANSWER
[1581069749] unbound[12272:0] info: response for www.youtube.com. AAAA IN
[1581069749] unbound[12272:0] info: reply from <com.> 2001:502:7094::30#53
[1581069749] unbound[12272:0] info: query response was REFERRAL
[1581069749] unbound[12272:0] info: response for www.youtube.com. AAAA IN
[1581069749] unbound[12272:0] info: reply from <youtube.com.> 2001:4860:4802:32::a#53
[1581069749] unbound[12272:0] info: query response was CNAME
[1581069749] unbound[12272:0] info: resolving www.youtube.com. AAAA IN
[1581069749] unbound[12272:0] info: resolving com. DNSKEY IN
[1581069749] unbound[12272:0] info: response for www.youtube.com. AAAA IN
[1581069749] unbound[12272:0] info: reply from <com.> 192.43.172.30#53
[1581069749] unbound[12272:0] info: query response was REFERRAL
[1581069750] unbound[12272:0] info: response for www.youtube.com. AAAA IN
[1581069750] unbound[12272:0] info: reply from <google.com.> 216.239.32.10#53
[1581069750] unbound[12272:0] info: query response was nodata ANSWER
[1581069750] unbound[12272:0] info: response for www.youtube.com. AAAA IN
[1581069750] unbound[12272:0] info: reply from <google.com.> 2001:4860:4802:32::a#53
[1581069750] unbound[12272:0] info: query response was ANSWER
[1581069750] unbound[12272:0] info: response for www.youtube.com. AAAA IN
[1581069750] unbound[12272:0] info: reply from <google.com.> 2001:4860:4802:34::a#53
[1581069750] unbound[12272:0] info: query response was ANSWER
[1581069750] unbound[12272:0] info: prime trust anchor

Spoiler: DNS leak TOR

Spoiler: Log's with VPN

[1581070653] unbound[15895:0] notice: init module 0: dns64
[1581070653] unbound[15895:0] notice: init module 1: validator
[1581070653] unbound[15895:0] notice: init module 2: iterator
[1581070653] unbound[15895:0] info: start of service (unbound 1.9.6).
[1581070671] unbound[15895:0] info: resolving ucp.nordvpn.com. A IN
[1581070671] unbound[15895:0] info: query response was REFERRAL
[1581070671] unbound[15895:0] info: resolving . DNSKEY IN
[1581070671] unbound[15895:0] info: query response was ANSWER
[1581070671] unbound[15895:0] info: resolving com. DNSKEY IN
[1581070671] unbound[15895:0] info: query response was REFERRAL
[1581070671] unbound[15895:0] info: resolving ucp.nordvpn.com. AAAA IN
[1581070671] unbound[15895:0] info: response for ucp.nordvpn.com. A IN
[1581070671] unbound[15895:0] info: reply from <com.> 2001:503:83eb::30#53
[1581070671] unbound[15895:0] info: query response was REFERRAL
[1581070671] unbound[15895:0] info: response for ucp.nordvpn.com. AAAA IN
[1581070671] unbound[15895:0] info: reply from <com.> 2001:500:d937::30#53
[1581070671] unbound[15895:0] info: query response was REFERRAL
[1581070671] unbound[15895:0] info: response for ucp.nordvpn.com. AAAA IN
[1581070671] unbound[15895:0] info: reply from <nordvpn.com.> 2606:4700:50::adf5:3a82#53
[1581070671] unbound[15895:0] info: query response was ANSWER
[1581070671] unbound[15895:0] info: response for ucp.nordvpn.com. A IN
[1581070671] unbound[15895:0] info: reply from <nordvpn.com.> 2606:4700:50::adf5:3a82#53
[1581070671] unbound[15895:0] info: query response was ANSWER
[1581070671] unbound[15895:0] info: prime trust anchor
[1581070671] unbound[15895:0] info: generate keytag query _ta-4f66. NULL IN
[1581070671] unbound[15895:0] info: resolving . DNSKEY IN
[1581070671] unbound[15895:0] info: validate keys with anchor(DS): sec_status_secure
[1581070671] unbound[15895:0] info: Successfully primed trust anchor . DNSKEY IN
[1581070671] unbound[15895:0] info: resolving _ta-4f66. NULL IN
[1581070671] unbound[15895:0] info: query response was NXDOMAIN ANSWER
[1581070671] unbound[15895:0] info: validated DS com. DS IN
[1581070671] unbound[15895:0] info: resolving . DNSKEY IN
[1581070671] unbound[15895:0] info: response for ucp.nordvpn.com. AAAA IN
[1581070671] unbound[15895:0] info: reply from <nordvpn.com.> 2606:4700:58::adf5:3b8e#53
[1581070671] unbound[15895:0] info: query response was nodata ANSWER
[1581070671] unbound[15895:0] info: validated DS com. DS IN

Spoiler: DNS leak VPN

Spoiler: Status VPN

Do not forget to restart all the services (use the installer script) you use with each addition of services that depend on the DNS server. As we are dealing with DNS, we need to restart the unbound, and clear the DNS cache of the devices on the LAN for each service addition.

Spoiler: Services restart

@rgnldo:/tmp/home/root# sh /jffs/scripts/gen_unbound.sh
Removing unbound.conf files..
Removing log's files...
Restarting services...
 Shutting down unbound...              done.
 Starting unbound...              done.
 Shutting down haveged...              done.
 Starting haveged...              done.
 Shutting down suricata...              done.
 Starting suricata...              done.
 Shutting down clamav...              done.
 Starting clamav...              done.