I am a bit confused. Are you adding static route for the root server over tun14? I don't know how many are there. Is the list covers all of them?
Unbound Understanding Unbound...
- Thread starter Viktor Jaep
- Start date
SomeWhereOverTheRainBow
Part of the Furniture
SomeWhereOverTheRainBow
Part of the Furniture
That is definitely a finite method. I am curious to see the results if @Viktor Jaep has not already followed this method.You can’t add enough static routes to cover all the possible authoritative name servers out there (root servers alone are not enough).
I would just follow this post from Martineau and don’t miss the step from the wiki.
Unbound - unbound_manager (Manager/Installer utility for unbound - Recursive DNS Server) - General questions / discussion thread 2
Dumb question but how do u add it this list? From diversion -> b (blocking list) -> 1 (change composition custom) -> 2 (customize hosts list) -> 1 (Add hosts list) -> paste new hosts link link here -> e (exit) -> 1 (yes to update list now). It will take some time to update the lists.www.snbforums.com
Got it.
How about other authoritative servers in the recursive query?
Code:
admin@RT-AC86U-DBA8:/tmp/home/root# dig dell.com @localhost +trace
; <<>> DiG 9.18.11 <<>> dell.com @localhost +trace
;; global options: +cmd
. 484650 IN NS d.root-servers.net.
. 484650 IN NS e.root-servers.net.
. 484650 IN NS f.root-servers.net.
. 484650 IN NS g.root-servers.net.
. 484650 IN NS h.root-servers.net.
. 484650 IN NS i.root-servers.net.
. 484650 IN NS j.root-servers.net.
. 484650 IN NS k.root-servers.net.
. 484650 IN NS l.root-servers.net.
. 484650 IN NS m.root-servers.net.
. 484650 IN NS a.root-servers.net.
. 484650 IN NS b.root-servers.net.
. 484650 IN NS c.root-servers.net.
. 484650 IN RRSIG NS 8 0 518400 20230517050000 20230504040000 60955 . euvMHZqurPBykFmPr1OYrEWd3ZIP2l3skATDF8FxfGFfEZmBl/NIn+lu 463u/qxl9F3NYoxN7ANmZyJFMoDhCVpRMEk9mRimctn9fj+6B1EiG02g vUiMKSBPrv/gWbZZcXobaE/F99WYV0xnWNWAKJqRO52YRXqvqltvcjNM FnreCFXRPLFKJ6jqortPA8XfDEUeyt2oFnNZFy9aVqBSGsIqT2gaqX++ 6CXeemp5SSX1YHBxVVWnI6FWw7FjPBRNa485e0RmTi/0WdTTaYd2Eh5u Sfbpn4OzAgOkGJEU0J45Z4nO8j8M8PpRIW8xh7muW/pLUL6x3FsRsf2s scKr8w==
;; Received 525 bytes from 127.0.0.1#53(localhost) in 0 ms
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20230517200000 20230504190000 60955 . osCwjYKoG85SJEV8XEBRg6OG/n4n33uy+5vZhn9pojslOWLO05iRY/qw DSimL+UpbpZExrN85N7tIdB0Auie7Abr0tbjzaB90gadW/sImZQLjr6w q/jMg+CCWLQTZ/xXzCrEUbS1IxZfoWK5WpfUsArmVZBd0jzvJ5TW/FOs iir25upMGLaSfLKkrnt/gVaSbdqj5+kQ8JcrbSIJy+3QbJw6QMequ/1z KihqlMFsfEuLNdCv9Az54NqLH7sEbFJANbGjlsp/vppCTSNll4U9ptD4 E2qBjG94NvrBYSdp//qgqGG1/lcBIT24i53MKaYsqSgHGjHWKLIuLwOp BSY7tA==
;; Received 1196 bytes from 192.112.36.4#53(g.root-servers.net) in 209 ms
dell.com. 172800 IN NS ns1ak.dell.com.
dell.com. 172800 IN NS ns2ak.dell.com.
dell.com. 172800 IN NS ns4ak.dell.com.
dell.com. 172800 IN NS ns3ak.dell.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20230510042250 20230503031250 46551 com. HpyzWqBzY2A8rDtxpNm9P8eNu0iT0E37qgJDloItgnV9N5mb3gDNieR9 3gP94NltHonAOe32HxaBwCRT22XPyftxDpY/syq7Ea9av4tKAtb2N3xi hzGmQ7GVC3otNYqLbF+EL+6aF6MieJajWvNu38Vv5/w+8KQ9Srt9jHbq 7uwUJHIalX9XbITrGLn8i9HDYuLp/HlyiI06lUS0a9+KPQ==
II0V79T8AB9A6LVD6E2FBPK9CH01LH6U.com. 86400 IN NSEC3 1 1 0 - II0VE7BP74PHKFHV0PBQJ15U5ILVJ194 NS DS RRSIG
II0V79T8AB9A6LVD6E2FBPK9CH01LH6U.com. 86400 IN RRSIG NSEC3 8 2 86400 20230510043041 20230503032041 46551 com. oZf6U1Hq/LNqVSAPEiHrpXPy7nvMaBHepeOrdScE5qRARU3gWCAiU+zj 9mBVzmKyd58+joBQUhBt4/QLm/ZAO8G+VN/V6XkOZhcYp8tx0S9CcqNR Kjj1xDsdIoV1z6qlN80vifTiM8eBB8wVhSlTQWDqD+lwApWNcGGFrjpq CKh/L3VDPCwLmlfWHQ2jKywVR52aKA0ZLPN+ZNgHrWhA1A==
;; Received 730 bytes from 192.41.162.30#53(l.gtld-servers.net) in 79 ms
dell.com. 600 IN A 143.166.135.105
dell.com. 600 IN A 143.166.147.101
;; Received 69 bytes from 184.85.248.65#53(ns4ak.dell.com) in 59 ms
admin@RT-AC86U-DBA8:/tmp/home/root#SomeWhereOverTheRainBow
Part of the Furniture
Obviously, if there are more root servers in the root.hints that unbound uses, then we would have to consider those as well. I only considered those since presumably they are what would be talked to first. But as @dave14305 suggest maybe there is more dynamics that need to be considered like marking the traffic as the script you use does.
dave14305
Part of the Furniture
This is a problem that was solved a couple years ago, but apparently not easy to find for new Unbound / VPN users.
Your iptables rule serves no functional purpose. You wouldn’t masquerade across a VPN interface. Your route statements only covered the TLD root servers. There are countless authoritative name servers as @chongnt points out. Since capturing all the possible destination IPs is near impossible for an open internet, the best course of action is to route based on the destination port using policy based routing.
Back to this, it shows VPN IP as sender source IP.So that's good news...What's your theory on this? Using Eibgrad's DNSMON tool, it shows DNS requests going out over the VPN, but it almost seems like their replies are coming back to the WAN? One would think if they go out over the VPN, they would return over the VPN?
View attachment 49888
Here my tun11 ip is 10.7.1.3.
When I run traceroute with source ip of 10.7.1.3, it is actually going through WAN interface. I think this is what you see at the moment, sender source IP is VPN IP. But DNS traffic is actually still going through WAN interface. That is also the reason why there is no DNS packet captured when run tcpdump on tun14, because there is no DNS traffic on tun14.
When I run traceroute with source interface tun11, it is actually going through OVPNC1 interface.
Code:
admin@RT-AC86U-DBA8:/tmp/home/root# ifconfig tun11
tun11 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.7.1.3 P-t-P:10.7.1.3 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:18962706 errors:0 dropped:0 overruns:0 frame:0
TX packets:14212720 errors:0 dropped:262255 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:22046722634 (20.5 GiB) TX bytes:7902595236 (7.3 GiB)
admin@RT-AC86U-DBA8:/tmp/home/root# traceroute -s 10.7.1.3 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1) from 10.7.1.3, 30 hops max, 38 byte packets
1 X.X.X.X (X.X.X.X) 2.819 ms 1.288 ms 2.247 ms
2 *^C
admin@RT-AC86U-DBA8:/tmp/home/root#
admin@RT-AC86U-DBA8:/tmp/home/root# traceroute -i tun11 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
1 10.7.1.1 (10.7.1.1) 8.516 ms 8.058 ms 8.186 ms
...snipped...
admin@RT-AC86U-DBA8:/tmp/home/root# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 X.X.X.X 0.0.0.0 UG 0 0 0 ppp0
10.7.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tun11
...snipped...I started to think that sender source IP address does not really tell if DNS traffic is going through WAN, but only the recipient destination IP is significant.
Below are images I posted in DNS Monitoring thread.
This is when I leave unbound "outgoing-interface" blank, WAN IP is shown as sender source IP. It remains as sender source IP after I bind unbound over ovpnc1.
The same goes to DoT. This is when I try to route DoT over the ovpnc1. Even though sender source is my WAN IP, there is nothing captured when I run tcpdump on WAN interface . It is captured when I run tcpdump on tun11.
Below are images I posted in DNS Monitoring thread.
This is when I leave unbound "outgoing-interface" blank, WAN IP is shown as sender source IP. It remains as sender source IP after I bind unbound over ovpnc1.
The same goes to DoT. This is when I try to route DoT over the ovpnc1. Even though sender source is my WAN IP, there is nothing captured when I run tcpdump on WAN interface . It is captured when I run tcpdump on tun11.
Jumpstarter
Senior Member
I started to think that sender source IP address does not really tell if DNS traffic is going through WAN, but only the recipient destination IP is significant.
Below are images I posted in DNS Monitoring thread.
This is when I leave unbound "outgoing-interface" blank, WAN IP is shown as sender source IP. It remains as sender source IP after I bind unbound over ovpnc1.
The same goes to DoT. This is when I try to route DoT over the ovpnc1. Even though sender source is my WAN IP, there is nothing captured when I run tcpdump on WAN interface . It is captured when I run tcpdump on tun11.
So how do you know this is going over the tunnel then? The first image indicates it is going over WAN primarily.
Jumpstarter
Senior Member
Perhaps you could write a tutorial on this. No one really can seem to figure out how to use the search buttons in this place. Google tends to work better at finding stuff in here.
Viktor Jaep
Part of the Furniture
Even searching for stuff this specific can take an extraordinary amount of time... that's why we built a Asuswrt-Merlin Addon Software Catalog page to make it easier to find this kinda stuff. I'm just trying to get Unbound to reliably query root dns servers over the VPN (as supposedly advertised), avoiding the WAN altogether. Once I can zero in on something that is producing reliable results, I will link to that script/discussion.
Jumpstarter
Senior Member
It is a good thing you had the master of the search engine around to help. After reviewing the script he linked, it looks like it should do the trick. His sleuthing skills are unmatched around these parts. he even mentioned to not miss reading the wiki. https://github.com/RMerl/asuswrt-me...sed-Port-routing-(manual-method)#installation
Before DNS Monitor tools is available, I have been using tcpdump. DNS tools is very easy, everything is color coded and presented in a single page. In case you want to inspect what is going on in the packet, tcpdump is still very useful.
The first image indicates it is going over WAN because the sender source IP is my WAN IP. If you look at the recipient dest ip, it is actually my OVPN1 IP. I have verify with tcpdump that the DNS query actually traverse through OVPNC1.
Here is the logic in the DNS mon tools:
Code:
if echo $line | grep 'dport=53 ' | \
grep -Eq "(src|dst)=($wan0_ip|$wan1_ip)( |$)"; then
# Do53 connection routed over WAN
Last edited:
Jumpstarter
Senior Member
So, I mean isn't different to send a request to an 10.0.0.0/8 address than to say it actually traversed the VPN.
I don't really get what you mean here.
Jumpstarter
Senior Member
Similar to how we see this,
wouldn't we expect to also see a response coming back in the green from 10.7.3.2? or am I misunderstanding what you mean in your post?
Ok, I think I get you now.
Here is the thing, DNS Mon tools will show the entry in red as long as there is a match on source or destination with WAN IP. In the sample above the source sender ip matches my WAN IP. This is how it is written.
It may seems like DNS request is send over WAN and replies are coming from VPN. However, DNS request does not send out over WAN, it is send out over VPN. Tcpdump tells me that DNS queries and replies are all happening over the vpn tunnel. I hope this is clear.
From my experience above and what is seen in Viktor's post it seems we can ignore the source and just look at the recipient dest IP. What I mean is, probably the entry should be in red ONLY when the recipient dest ip matches the WAN IP. In other word, as long as recipient dest IP does not match WAN IP, the entry should be green. I could be wrong though.
Jumpstarter
Senior Member
I guess it would have cleared that up if you had shared your corresponding recorded TCPDUMP screenshots that also corresponded with your DNSMon. As you put it, with DNS Mon tool we are only seeing the first half of the cake.
Unfortunately I don't keep all the records. Anyway. tcpdump command is shared in earlier posts in this thread. Feel free to run it and perhaps you can share your findings here.
dave14305
Part of the Furniture
You remind me of another member named Sam. Quite a coincidence. I’m getting senile, perhaps.
Similar threads
Similar threads
Similar threads
-
-
-
-
-
Solved Latest entware update borked up Unbound- Started by Viktor Jaep
- Replies: 25
-
-
-
-
-
Unbound Unbound graphical statistics tab doesn't update all groups
- Started by Skywise
- Replies: 4
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!