Unbound unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server)

[kernol]

I love a good mystery. I’m guessing your /etc/resolv.conf contains 1.1.1.1, 1.0.0.1 and 127.0.1.1. If you run

nslookup diversion.ch
nslookup fwupdate.asuswrt-merlin.net
nslookup raw.githubusercontent.com

Do they all work? Share the output please.

Many thanks @dave14305 - the results all worked as expected ...

johnw@RT-AC86U-8178:/tmp/home/root# nslookup diversion.ch
Server:    1.1.1.1
Address 1: 1.1.1.1 one.one.one.one

Name:      diversion.ch
Address 1: 80.74.145.140 emerson.ch-meta.net
johnw@RT-AC86U-8178:/tmp/home/root#
johnw@RT-AC86U-8178:/tmp/home/root# nslookup fwupdate.asuswrt-merlin.net
Server:    1.1.1.1
Address 1: 1.1.1.1 one.one.one.one

Name:      fwupdate.asuswrt-merlin.net
Address 1: 104.18.40.167
Address 2: 104.18.41.167
Address 3: 2606:4700:3035::6812:29a7
Address 4: 2606:4700:3037::6812:28a7
johnw@RT-AC86U-8178:/tmp/home/root# nslookup raw.githubusercontent.com
Server:    1.1.1.1
Address 1: 1.1.1.1 one.one.one.one

Name:      raw.githubusercontent.com
Address 1: 151.101.0.133
Address 2: 151.101.192.133
Address 3: 151.101.128.133
Address 4: 151.101.64.133
johnw@RT-AC86U-8178:/tmp/home/root#

What I did discover - but had never noticed before was that if I did a tracert on my Win10 PC to say www.github.com - I would get there in 15 hops and end at the correct ip address. However when I ran a tracert from the "Network" tab of the router's webUI to the same github ... it would **** out after 14 hops and go all the way through to 30 hops without arriving at the correct ip.

So wisely or not - I am part way through a complete factory reset and rebuild.
Suspect I'll be fine after that - but will yell if not - MANY thanks again.

 

[martinr]

Whilst I take full responsibility for any bugs/misunderstamdings introduced by my manky unbound_manager script, given the title of this thread, I suggest that you post your query in the official unbound support thread together with the requested supporting documentation.

View attachment 21590

However, despite you being the third person to have experienced difficulty with unbound, I notice that there is never any useful feedback/assistance from the resident SME for issues similar to yours.

So, although I have included the unbound 'lookup' feature in the unbound_manager menu, I think you may need to manually delve into the external 'dig' and 'tcpdump' utilities to investigate why unbound seemingly fails, but dnsmasq doesn't.

i.e. you should be able to provide tangible data metrics as a comparison when the utilities are used when unbound fails vs. dnsmasq success for the appropriate domains(s) 'diversion.ch' etc.
P.S. I think I saw a post where unbound vs bind resulted in a similar situation and 'dig +trace' / 'tcpdump port 53' on the WAN interface proved useful.
(NOTE: I think in this instance, the underlying issue was something to do with the remote load-balancing servers' response?)

EDIT: Forget the above @dave14305 has taken an interest!

“manky”???? I don’t know which dictionary you’re using.

 

[dave14305]

What I did discover - but had never noticed before was that if I did a tracert on my Win10 PC to say www.github.com - I would get there in 15 hops and end at the correct ip address. However when I ran a tracert from the "Network" tab of the router's webUI to the same github ... it would **** out after 14 hops and go all the way through to 30 hops without arriving at the correct ip.

That’s interesting. Do you use IPv6? Both traceroutes need to go through the router so it’s curious why the difference. Any VPN clients?

I’m boarding a flight now, so I’ll be offline for a while. I’m interested in your results after the reset.

 

[kernol]

That’s interesting. Do you use IPv6? Both traceroutes need to go through the router so it’s curious why the difference. Any VPN clients?

I’m boarding a flight now, so I’ll be offline for a while. I’m interested in your results after the reset.

No IPv6 and no VPN clients - will post later when done. thnx

 

[^Tripper^]

..the trusted @L&LD full factory reset route.
That routine 9 times out of 10 will cure aberrations such as the one recently suffered.

Many a times I’ve spent days in vain trying to fix an issue when his trusty routine could’ve solved the problem in about 20 mins.

 

[kernol]

@dave14305 - problem recurs after reset and BEFORE unbound even installed - so must stop wasting space in this unbound thread.
Connectivity problem to github - cause as yet unknown.

 

[Martineau]

Thanks @Martineau - if I had the slightest clue what you were suggesting - "dig" "tcdump" etc I would most certainly oblige

Well a comparison of the output of these two commands using unbound then dnsmasq

dig diversion.ch +trace

dig fwupdate.asuswrt-merlin.net +trace

may provide useful info.

 

[bluepoint]

Hi @dave14305 - thanks for your response. My WAN settings unchanged - before and after updates described above.
View attachment 21587

I have however tried changed to Quad9 for both settings [Router and DoT] - but no improvement.

Please note - was NOT seeking to "blame" any one or any script - was just seeking help on a peculiar issue not experienced before.

I am now beginning to wonder if it may be a timing issue within latest amtm - so going back there for help.

In your WAN settings, you have DOT enabled. Disable that option, if you wish to use DOT, enable it from unbound. They are two different things.
With your WAN settings right now, you have dnsmasq stubby DOT and unbound recursive DNS conflicting to resolve URL's.

 

[kernol]

In your WAN settings, you have DOT enabled. Disable that option, if you wish to use DOT, enable it from unbound. They are two different things.
With your WAN settings right now, you have dnsmasq stubby DOT and unbound recursive DNS conflicting to resolve URL's.

Many thanks @bluepoint - my understanding was that once unbound was installed it would "take over" and in consequence ignore the WAN settings for DNS - whether secure or otherwise ... however should unbound be stopped [or unlikely but possible - "crash"] then DNS would automatically be restored to WAN settings. That is the reason why I left the DoT settings in place [I accept that this may waste a smidgen of RAM].

Anyway - I have now determined that the problem has nothing to do with unbound - but is most likely a problem with github regional mirrors - specifically the ones they have down here in South Africa. The router logs were not helping ... but I finally managed to get capture this error for raw.githubusercontent.com ...

Error 503 Backend is unhealthy
Backend is unhealthy
Guru Mediation:
Details: cache-jnb7027-JNB 1582566942 340133284
Varnish cache server

I have no idea who or how to alert at Github ... but assume that someone there will wake up and fix in the next few days??

 

[dave14305]

my understanding was that once unbound was installed it would "take over" and in consequence ignore the WAN settings for DNS - whether secure or otherwise ... however should unbound be stopped [or unlikely but possible - "crash"] then DNS would automatically be restored to WAN settings. That is the reason why I left the DoT settings in place [I accept that this may waste a smidgen of RAM].

Spot on, at least the way I understand things.

Anyway - I have now determined that the problem has nothing to do with unbound - but is most likely a problem with github regional mirrors - specifically the ones they have down here in South Africa. The router logs were not helping ... but I finally managed to get capture this error for raw.githubusercontent.com ...

So are you getting a different DNS resolution if you resolve raw.githubusercontent.com through the router (e.g. 1.1.1.1) versus Unbound (from a LAN client)? I'm still unsure how stopping Unbound was improving the situation or if that was just a placebo to kill time until DNS routed you to a different server on the backend.

 

[juched]

@Martineau I know the adblock scripts do not have an owner, and I do find they work well, couple small suggested tweak:

Can the DNSWarden download link be replaced with this link:
https://raw.githubusercontent.com/dnswarden/blocklist/master/blacklist-formats/hostnames

The one used by the script is a static copy checked in Dec 2019. The link above is the regularly updated file it seems. Looking closer this new file is much larger.... so it seems this may be a bad bad idea Not really sure the current small list is adding much, couple spot checks shows it in Steven's list.

Can the frogeye first party trackers link be replaced with this link:
https://hostfiles.frogeye.fr/firstparty-trackers.txt

This one is not in the hosts name format, so the script can drop the extra processing commands. I see this file isn't currently downloaded as the line is commented out.

The StevensBlack would be great to find one already processed.


So, overall, I see now what it meant by the adblock needing work. I am interested to see how I can help, but I see @rgnldo hinted to some changes he is perhaps creating?

 

[SomeWhereOverTheRainBow]

So while working with this on one of my alternative routers (rtac3100 384.15), I ran into an issue after installing I noticed my internet status showed disconnected on the webpage, but while hovering over the connection wan icon in the corner of the page, I noticed the text that popped up said connected. What is going on? No issues with ntp or running any amtm scripts, just the annoyance of disconnected status on main page.

 

[kernol]

Spot on, at least the way I understand things.

So are you getting a different DNS resolution if you resolve raw.githubusercontent.com through the router (e.g. 1.1.1.1) versus Unbound (from a LAN client)? I'm still unsure how stopping Unbound was improving the situation or if that was just a placebo to kill time until DNS routed you to a different server on the backend.

My best guess is that connectivity to github mirrors in South Africa was intermittent - maybe flipping from one to another.
I fired up a VPN client via UK routing and was able to install and update all required scripts via amtm - so no doubt it is the SA mirrors.
Cut the VPN UK client - and back to same problem.

What I can't figure is why workstation tracert would at least arrive at github destination ip - whereas router traceroute would not. That is the case even under VPN Client via UK from router - never arrives within 30 hops - workstation arrives within 7 hops ??? All other destinations tested - [google etc] from traceroute on router end properly at destination ip? Go figure ??

EDIT: - sorry didn't answer your question - no ... turns out it was not DNS at fault [no differences in resolved ip's whether on PC or on router]. The data on the mirrored destination was corrupt and that caused the update errors first reported.

 

[joe scian]

In your WAN settings, you have DOT enabled. Disable that option, if you wish to use DOT, enable it from unbound. They are two different things.
With your WAN settings right now, you have dnsmasq stubby DOT and unbound recursive DNS conflicting to resolve URL's.

Bluepoint - do you happen to be based in Joberg SA?

 

[bluepoint]

Bluepoint - do you happen to be based in Joberg SA?

Negative.

 

[Skeptical.me]

I understand that your ISP's IP Address is used for the WAN DNS address because Unbound has become your DNS server. But is that WAN address used externally for anything related to Unbound (I'm not 100% clear in my understanding, I ask as I use VPN's to avoid a 2-year mandatory logging of all metadata here in Australia)

 

[dave14305]

I understand that your ISP's IP Address is used for the WAN DNS address because Unbound has become your DNS server. But is that WAN address used externally for anything related to Unbound (I'm not 100% clear in my understanding, I ask as I use VPN's to avoid a 2-year mandatory logging of all metadata here in Australia)

Authoritative DNS servers will see recursive requests coming from your WAN IP. But that doesn’t mean the destination websites see your WAN IP if they are routed through a VPN client.

 

[SomeWhereOverTheRainBow]

Authoritative DNS servers will see recursive requests coming from your WAN IP. But that doesn’t mean the destination websites see your WAN IP if they are routed through a VPN client.

So they may see your associated wan IP, but wont necessarily be able to associate it with you as you are behind a VPN?

 

[dave14305]

So they may see your associated wan IP, but wont necessarily be able to associate it with you as you are behind a VPN?

You would have to assume that a particular website also has access to dns logs from its domain’s authoritative nameserver, which isn’t likely in most cases (maybe except google, cloudflare, Amazon).

 

[SomeWhereOverTheRainBow]

You would have to assume that a particular website also has access to dns logs from its domain’s authoritative nameserver, which isn’t likely in most cases (maybe except google, cloudflare, Amazon).

Yea I can imagine if they are using the "bigger" services like you mention cloudflare, amazon, and google. it is highly unlikely they are tracking that deep.