config dhcp 'lan'
...
list dns 'fd00:bbbb::2'
list dns 'fd00:bbbb::3'
If unbound is running on the OpenWrt you can leave it empty.
1 Like
This works for unbound in serial mode, that is when it is the sole upstream server for dnsmasq, which is answering queries from local clients. In parallel mode, where unbound is directly answering local clients unless the query concerns a local domain, this approach is not applicable. That is to say, use serial mode if you value simplicity over efficiency and you need to deal with Netflix 
Unless your local router happens to be ::c0:fefe because that was so silly it had to be done 
I have added, also in "dhcp":
list dhcp_option 'option:dns-server,0.0.0.0'
thank you both for the replies!
I am using Unbound in parallel mode and I have "list dhcp_option 'option:dns-server,0.0.0.0'" configured in my /etc/config/dhcp file.
It still seams like unbound is ignoring my netflix ipv6 entries.
root@GateKeeper:/etc/config# cat unbound_ipv6_netflix.conf
#Netflix IPV6 Unbound Filter
local-zone: "netflix.com" typetransparent
local-data: "netflix.com IN AAAA ::"
local-zone: "netflix.net" typetransparent
local-data: "netflix.net IN AAAA ::"
local-zone: "nflxext.com" typetransparent
local-data: "nflxext.com IN AAAA ::"
local-zone: "nflximg.net" typetransparent
local-data: "nflximg.net IN AAAA ::"
local-zone: "nflxvideo.net" typetransparent
local-data: "nflxvideo.net IN AAAA ::"
local-zone: "www.netflix.com" typetransparent
local-data: "www.netflix.com IN AAAA ::"
local-zone: "customerevents.netflix.com" typetransparent
local-data: "customerevents.netflix.com IN AAAA ::"
local-zone: "secure.netflix.com" typetransparent
local-data: "secure.netflix.com IN AAAA ::"
local-zone: "adtech.nflximg.net" typetransparent
local-data: "adtech.nflximg.net IN AAAA ::"
local-zone: "assets.nflxext.com" typetransparent
local-data: "assets.nflxext.com IN AAAA ::"
local-zone: "codex.nflxext.com" typetransparent
local-data: "codex.nflxext.com IN AAAA ::"
local-zone: "dockhand.netflix.com" typetransparent
local-data: "dockhand.netflix.com IN AAAA ::"
local-zone: "ichnaea.netflix.com" typetransparent
local-data: "ichnaea.netflix.com IN AAAA ::"
local-zone: "art-s.nflximg.net" typetransparent
local-data: "art-s.nflximg.net IN AAAA ::"
local-zone: "tp-s.nflximg.net" typetransparent
local-data: "tp-s.nflximg.net IN AAAA ::"
Do I still need to enter those DNS values?
config dhcp 'lan'
...
list dns 'fd00:bbbb::2'
list dns 'fd00:bbbb::3'
I guess setting all of this doesn't have any huge advantages at the moment. (using he.net for ipv6 support) It seems when some of my dhcp clients surf.. it randomly uses either my ipv4 wan (ISP) or ipv6 wan (HE.NET) to access the internet. So depending on the site they visit.. it sometimes thinks they're in the USA when in fact they're in Canada.
I'll still try to make this work... I just want to make sure all my ipv6 dhcp client query my unbound server for dns requests and NOT the he.net dns servers... Otherwise my parental filters won't work for them.
The fact that some sites are accessed via IPV4 while others via IPV6 is perfectly normal: if both are available, IPV6 is given priority. Also, it depends exactly on how the application queries the DNS: asking for ANY will give you, well, any record regarding a domain while asking for A / AAAA will return just that.
I can't really comment on unbound filtering since I am not using this feature but I do recall that there was a two-server setup involved in most suggestions. Out of curiosity, I did another quick search and found a new interesting approach.
Also, be aware that some clients deliberately use hardcoded servers.
Oh, by the way: how did you include your "netflix" file in the main unbound conf? I might be able to replicate the setup here and check if that works: I have blocked access to external DNS servers so it's either my server or no answer 
In in the /etc/unbound/unbound_src.conf file I added this line:
include: "/etc/config/unbound_ipv6_netflix.conf"
which is:
#Netflix IPV6 Unbound Filter
local-zone: "netflix.com" typetransparent
local-data: "netflix.com IN AAAA ::"
local-zone: "netflix.net" typetransparent
local-data: "netflix.net IN AAAA ::"
local-zone: "nflxext.com" typetransparent
local-data: "nflxext.com IN AAAA ::"
local-zone: "nflximg.net" typetransparent
local-data: "nflximg.net IN AAAA ::"
local-zone: "nflxvideo.net" typetransparent
local-data: "nflxvideo.net IN AAAA ::"
local-zone: "www.netflix.com" typetransparent
local-data: "www.netflix.com IN AAAA ::"
local-zone: "customerevents.netflix.com" typetransparent
local-data: "customerevents.netflix.com IN AAAA ::"
local-zone: "secure.netflix.com" typetransparent
local-data: "secure.netflix.com IN AAAA ::"
local-zone: "adtech.nflximg.net" typetransparent
local-data: "adtech.nflximg.net IN AAAA ::"
local-zone: "assets.nflxext.com" typetransparent
local-data: "assets.nflxext.com IN AAAA ::"
local-zone: "codex.nflxext.com" typetransparent
local-data: "codex.nflxext.com IN AAAA ::"
local-zone: "dockhand.netflix.com" typetransparent
local-data: "dockhand.netflix.com IN AAAA ::"
local-zone: "ichnaea.netflix.com" typetransparent
local-data: "ichnaea.netflix.com IN AAAA ::"
local-zone: "art-s.nflximg.net" typetransparent
local-data: "art-s.nflximg.net IN AAAA ::"
local-zone: "tp-s.nflximg.net" typetransparent
local-data: "tp-s.nflximg.net IN AAAA ::"
I seem to have limited ALL my dhcp dns request to ONLY use my local DNS server. That way any devices with hard coded DNS servers can't sneak by.
/etc/config/firewall
config redirect 'restrict_dns_53'
option name 'restrict DNS, port 53'
option src 'lan'
option target 'DNAT'
option dest 'lan'
option dest_port '53'
list proto 'tcp'
list proto 'udp'
option src_dport '53'
config redirect 'restrict_dns_853'
option name 'restrict DNS, port 853'
option src 'lan'
option target 'DNAT'
option dest 'lan'
option dest_port '853'
list proto 'tcp'
list proto 'udp'
option src_dport '853'
config redirect 'restrict_dns_5353'
option name 'restrict DNS, port 5353'
option src 'lan'
option target 'DNAT'
option dest 'lan'
option dest_port '5353'
list proto 'tcp'
list proto 'udp'
option src_dport '5353'
I'm assuming this will apply to ipv6 traffic too.. however I'm not sure.
When I did a nslookup on 1 of my workstations on my network I got:
nslookup www.netflix.com
Server: GateKeeper.myhomedomain.ca
Address: fd4a:d0d8:34a9::1
Non-authoritative answer:
Name: www.netflix.com
Addresses: ::
34.210.217.170
34.215.79.124
52.33.134.215
52.39.48.121
52.41.135.17
52.43.218.25
52.89.214.214
54.187.132.161
and tried to specify another DNS server I got the same results.
nslookup www.netflix.com 8.8.8.8
Server: dns.google
Address: 8.8.8.8
Non-authoritative answer:
Name: www.netflix.com
Addresses: ::
34.210.217.170
34.215.79.124
52.33.134.215
52.39.48.121
52.41.135.17
52.43.218.25
52.89.214.214
54.187.132.161
Even though it "seems" to be working.. whenever any of my kids try to load the Netflix APP on their devices they get that darn PROXY error message until I shutdown my wan6 interface. 
We discussed it thoroughly here for hijacking DNS queries that try to bypass the legitimate nameservers.
1 Like
@Cylac have yet to try it, sorry, will update perhaps this evening
@trendy I had a very quick look at the thread you linked, just adding here that I took a different approach: simply blocked connections to external servers. My reasoning is that any device that tries a hardcoded server first must also have a backup plan (like using the dhcp-supplied server) or simply stop working if that server ever fails, which is not great.
Exactly, that's why I went for the hijacking option. Given that most Android devices will do that (I still see them in the logs trying) I didn't want to have the extra delay for most of the queries until they timeout.
1 Like
I copied this rule directly to my file, then checked from the web interface:
It is shown as IPV4-only. I have verified that I can still query an external server if I dig google's IPV6 dns server. I asked for my router's address using the local name, which google doesn't know about, and it failed as expected. If I query 8.8.8.8 for netflix, then there is no AAAA reply, thanks to your extra unbound config.
TLDR with those rules, the Netflix app is still able to bypass your DNS server, get an IPV6 answer and promptly send traffic through the tunnel.
I'd say it is time to study the example linked by @trendy
thanks for testing it out! I'll check out the examples that were linked. Seems my issue is some ipv6 dns queries can still bypass my local dns server.
I'm also looking at testing out the NextDNS.io client they have for OpenWRT and dropping Unbound.
I'm assuming by these results that all my ipv6 dns queries are only being resolved locally.
This is on my Windows 10 workstation (a client)
cylac@CHAOS:~$ nslookup gatekeeper.myprivdomainname.ca 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Name: gatekeeper.myprivdomainname.ca
Address: 192.168.76.1
cylac@CHAOS:~$ nslookup gatekeeper.myprivdomainname.ca 2001:4860:4860::8888
Server: 2001:4860:4860::8888
Address: 2001:4860:4860::8888#53
Name: gatekeeper.myprivdomainname.ca
Address: 192.168.76.1
I followed the instructions found here: https://openwrt.org/docs/guide-user/services/dns/intercept
I wasn't sure if it worked since I got this once I reloaded the firewall:
* Populating IPv6 nat table
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_wan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_rule'
It's probably not related.
Anyhow, I'm gonna guess that ANY ipv6 and ipv4 dns queries from any of my clients have to use my local dns.
Most likely so, that's why I am not sure switching server software will do anything beyond learning how to configure it
Hmm, that guide doesn't look right, @trendy: only in UCI is the target "DNAT" or "SNAT", in iptables-save that becomes "REDIRECT" so the sed invocation for IPV6 would probably not work as intended, at least here it does not generate any IPV6 rules.
Assuming I don't have pi-hole and that the DNS server lives on the router, do I need all those rules or can one get by with a reduced set? For example that from the guide above, albeit with a revised "sed" translation?
The REDIRECT is almost the same as DNAT, but to redirect to the same device.
The REDIRECT target is used to redirect packets and streams to the machine itself. This means that we could for example REDIRECT all packets destined for the HTTP ports to an HTTP proxy like squid, on our own host. Locally generated packets are mapped to the 127.0.0.1 address. In other words, this rewrites the destination address to our own host for packets that are forwarded, or something alike. The REDIRECT target is extremely good to use when we want, for example, transparent proxying, where the LAN hosts do not know about the proxy at all.
Note that the REDIRECT target is only valid within the PREROUTING and OUTPUT chains of the nat table. It is also valid within user-defined chains that are only called from those chains, and nowhere else. The REDIRECT target takes only one option, as described below.
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
I know
My question was on the "sed" string: I don't think it works as intended.
The sed string works as intended, to create the custom chains in the ip6tables from iptables.
Then it is up to you to add the redirect in the proper chain in ip6tables.
Does that cover you?
Have you tried it? Not just looked at it, like I also did at first
I have copypasted the whole thing and it doesn't change anything, because on the current 19.07.2 this
uci -q delete firewall.dns_int
uci set firewall.dns_int="redirect"
uci set firewall.dns_int.name="Intercept-DNS"
uci set firewall.dns_int.src="lan"
uci set firewall.dns_int.src_dport="53"
uci set firewall.dns_int.family="ipv4"
uci set firewall.dns_int.proto="tcp udp"
uci set firewall.dns_int.target="DNAT"
becomes:
-A zone_lan_prerouting -p tcp -m tcp --dport 53 -m comment --comment "!fw3: Intercept-DNS" -j REDIRECT --to-ports 53
-A zone_lan_prerouting -p udp -m udp --dport 53 -m comment --comment "!fw3: Intercept-DNS" -j REDIRECT --to-ports 53
Then sed looks for either DNAT or SNAT, finds none and does not output MASQUERADE for IPV6.
I'm trying to understand if I have made a mistake somewhere, if I am missing something or somehow the guide was written for an older version of openwrt where the uci stanza above would be expanded as expected by sed. (EDIT: nope, see later)
EDIT: I have also tried "sed" by itself, feeding it input with DNAT or SNAT, but no luck, I'm stuck.
I am actually using it. If you compare the output between iptables-save -t nat and iptables-save -t nat | sed -e "/\s[DS]NAT\s/d;/\sMASQUERADE$/d" you'll verify that all DNAT, SNAT, and MASQUERADE rules are removed. So what is restored to ip6tables is the skeleton of the custom chains and whatever rules were created before you ran that, other than SNAT, DNAT, and MASQUERADE.
I am running my dns-hijack6 custom scripts after I run this firewall.nat6, so I need to create the DNAT and MASQUERADES in the dns-hijack6. I guess if you had run already the REDIRECT before, then it would be transferred over when firewall.nat6 runs, since REDIRECT is not a keyword in sed to be omitted.
1 Like
Ahhhhh, thanks! See, I was indeed missing something 
(old habit of using sed only to transform strings, not to remove them altogether... as a consequence, I didn't look at other lines, just those related to DNS)
I had a look at the post you linked but I haven't tried it, yet.
1 Like