@johnpoz said in Netflix and HE tunnel broker: No gua, no ula - not even a link-local, so why and the F would it ask for AAAA for?? Lazy freaking programing if you ask me. Good question. If there are no local IPv6 interfaces to talk to, I'm curious what the advantage is knowing that an AAAA exists for a host that will be contacted over A anyway. I've a possible reason in front of me, the one and only Firefix plugin I use : [image: 1773127237304-4cc14808-f093-4491-9b04-2d62263ab906-image.png] edit : the plugin is he.net powered. It shows me for every web site I visit what I'm using : A or AAAA, and it also shows what other sites are visited when the page was retrieved. [image: 1773127312570-36fdb069-8ff7-4888-a2ce-c2c8e65d6013-image.png] I can image that when this Firefox plugin is used, these AAAA requests are made. But if it isn't used ? @SteveITS said in Netflix and HE tunnel broker: Edit: also FWIW we found HE tunnels were rate limited. I mean they are free, so hard to complain, but bandwidth was about 1/3 of our IPv4 connection speed. Because the POPs have cost involved Some of them are marked as "can't add any new clients anymore" == they are 'full'. If they would throw hardware on it, tunnel.he.net would become a real, free VPN alternative **, which would need even more hardware. ** he.net uses a tunnel = IPv6 packets are encapsulated into a IPv4 packets = the GIF protocol, which is, afaik, not encrypted. Not a big deal as all traffic is TLS already anyway.

Wow... ok figured it out. The links provided in @Gertjan post put me on the right path. It seemed strange that only Ubuntu Server hosts were affected so I started digging on that. Turns out that by default in Ubuntu Server systemd-resolved is not configured to use the domains passed by DHCP (either v4 or v6) not by RDNSS. So all I had to do was to edit /etc/systemd/networks/networkd.conf to have UseDomain=true and just like that, by magic the hostname is properly registered in Unbound...

@JonathanLee said in Serving different WPADs per subnet with Unbound: for Netflix not liking the HE ipv6 tunnel That was also solved with the help of pfBlockerng : [image: 1758778353680-eca53c7f-080b-4bc2-ab1a-cf4abc9e9f38-image.png] and enter all the domain names you don't want to be resolved as AAAA, only A. In my he.net days, this worked very well.

Thanx a lot @Gertjan That was it. It was listening on port 953. Since I had not seen any configuration option in the UI I thought it was disabled.

[image: 1737050808671-685ef897-9dfa-4656-81a3-8cb04f4c40f8-image-resized.png] I am aware of the resolver interval, is there a way to bypass one url example imap.gmail.com always forward to 8.8.8.8 do not save in firewall dns namesever for reuse thus every time it gets the new ip address google has for the mail server, they change so fast the firewall can't keep up so the mail app at times says error after 5 mins it will resolve but that is unacceptable for modern use.

@JonathanLee said in IPv6 HE tunnel broker and Netflix quick fix idea: This fixed my issues 100% anyone else parse AAAA and A dns records like this? That issue is very old. Hit the search button - its just above : [image: 1721814205482-979fea0f-8b0a-4338-afa4-9be21a3aeefa-image.png] The issue has even a pfBlockerng solution made for it : [image: 1721814277228-99d7ab85-cb14-44e3-958e-e48648d7256f-image.png] Check the check box. Add all the host names that should not be resolved to AAAA. Done.

I figured it out - I should not put my authoritative server under the domain override section because unbound put it in a forward zone and expects a dns resolver. Instead, I switched to a stub zone under custom configuration, which requires an authoritative dns server and unbound will perform recursive lookup itself.

@bassplayaman re: latest, see https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#troubleshooting

@n300 der umgekehrte Fall trifft zu, das Modul hat aber auch nichts mit den Client zu tun, sondern mit Übermittlung von Domains via pfB wenn das gemeint ist.

@ericafterdark I'm actually one of the authors of ctrld. If you're into fancy DNS routing, you may dig this article on how to use ctrld with pfSense, and what you can accomplish with it, especially if you use Control D as an upstream. https://github.com/Control-D-Inc/ctrld/wiki/pfSense-and-OPNsense-Operations-Guide

If it's fully standalone in Unbound that should be possible, though I don't know what kind of time frame we'd be looking at. I haven't kept an eye on it but last I saw it required passing in the https requests from something else like an nginx proxy setup but from the look of those docs they seem to have native support now. The library they mentioned is present on pfSense and is a dependency of Unbound already (the ports option DOH is enabled) so all the backend parts appear to be present, just the GUI/PHP config code would need to be implemented. The larger problem is that it's going to want to use port 443 which complicates GUI access and makes it trickier to use in practice.

@johnpoz Thanks again john. Decided to by-pass the whole local network and plugged the internet straight into Wireshark. Couldn't find any DNS packets! Did a factory reset and assigned Snort to the LAN interface and all is good! Thanks for your help.

@gessel I too have an alert from this China IP block 183.136.225.29 [image: 1697653460002-screenshot-2023-10-18-at-8.24.51-am-resized.png] https://forum.netgate.com/topic/183488/et-scan-hid-vertx-and-edge-door-controllers-discover Virus total shows it is an invasive actor. 183.136.225.31 also [image: 1697653692436-screenshot-2023-10-18-at-11.27.08-am-resized.png]

Do you have a complex Unbound config? pfBlocker with DNSBL?

@sauce I've found https://knot-resolver.readthedocs.io/en/stable/modules-refuse_nord.html How is this related to pfSense ?

@coyote1abe said in DNS over TLS Not Working?: could you please be a little more specific about the change you made to system Somewhere in the past, he changed the IP settings of his device ( a Windows PC ) from the default DHCP settings to a static setting. Like this : [image: 1659682406226-d3577074-a66d-4dc6-9d2a-47fe70abc2e1-image.png] which means this windows device doesn't use pfSense at all for DNS .... because he asked 1.2.3.4 to be used. He has undone that, and now all is well.

@rvjr On pfSense unbound generally restarts. See https://redmine.pfsense.org/issues/5413