duh! thanks... brand new to this software...

That doesn't make sense unless your WAN and LAN are on the same network, which shouldn't be the case.

@NogBadTheBad I know that its on the loopback address and I technically don't have to worry about it. But I am simply more personally curious about it then anything else. Like I get its there to send things like the start command or to collect stats etc (thus entirely benign traffic) though it doesn't really exactly explain why it has to open 30+ connections to do that not to mention leave them open for give or take a minute at a time if they are already in a state of being finished.

Pull Request created:
https://github.com/pfsense/pfsense/pull/4077

@johnpoz

When outgoing interfaces is set to Localhost as we discussed, DNS queries will still follow the routing table that pfsense has, correct? So in my specific use case, the query will route through the openvpn tunnel if and only if it is destined for the domain override that I set, correct?

Also, since we set an Outbound NAT rule for the domain override, would it make sense to add the tunnel network to the Access Lists of DNS resolver in both sides of the tunnel?

Here made it easier for the next guy to view your images

images.png

Why would you not just directly attach them to the post?

Anyway - what are you rules on the 192.168.70 interface of pfsense?

I would imagine the reason is because some of the services don't allow you to use @ (especially traditional dynamic DNS services that need a specified hostname, as opposed to actual full DNS services). So their check is for the lowest common denominator. Whether or not they could change the logic to allow it for some services and not others would probably be a more significant effort, especially in the homework to find out whether each service permits the use of @ as a hostname or not. However with more traditional DNS services - Azure, Route 53, and the like - being present in the service list these days, it might be worth it.

There is a workaround in creating an actual hostname, then using @ as an alias for that hostname... but kinda annoying. ☺

What happens when you try? Is there an error? Anything in the System log? If not, try to edit it, turn on verbose logging, save, then try to delete it again and check the log.

Ah, I see. Sorry, I have nothing else to suggest. Hopefully someone else has something to add.

You do understand android devices are notorious for doing their own thing when it comes to dns right?

Heres the thing if you tell your reservation to send out dns 1.2.3.4, there is nothing saying the client HAS to use that.. But there is nothing you can do but hand it to the client.

Simple enough to sniff on the dhcp offer, is 8.8.8.8 listed. If your client not using that - that is on the client.

Your options would be to redirect that specific clients IP queries to where you want them to go via a port forward.

The issue has zero to do with the resolver, and zero to do with forwarding on that resolve to some dns using tls.

Validate by sniff your dhcp traffic that your actually offering the client what you want to offer it for dns.. If you are - then its on the client if uses it or not. Nothing pfsense can do about that other then a redirection of clients traffic... Part of the problem with dot and doh - is the iot device might start doing their dns via that - then what the F you going to do ;)

I hand out different name server other than pfsense interface on that network all the time.. To many devices - works as designed.. Give me a sec and will sniff some dhcp for you and show you how it works.

edit:

here... Here I handed client gets handed 192.168.3.10 as its NS
I then change it to hand out 8.8.8.8
did a ipconfig /renew on the client
You see it is now listing that as its only NS
And as you see from the capture the dns it sent it was 8.8.8.8

dns.png

If you validate via sniff that pfsense is handing out the dns you want the client to use - and its not using it.. Then that is on the client, and the best you can hope to do is manually edit it on the client or redirect the traffic from that client from dns.. If its not hiding it in a doh or dot tunnel ;)

@socrates324 said in DNS multiple hostnames for IP (like /etc/hosts):

So it seems to me that this approach does only work with static IP addresses but not DHCP?

That depends on whether there's a static mapping for the address. With static mappings, the addresses are the same as static. Otherwise, they could change, which means there's no consistent address to point to. One thing some DNS servers can do is create an alias, where one name refers to another. I do this with my IPv4 WAN address, where my host name is long and based on the firewall and modem MAC addresses. I just create an alias, in my own domain, that points to the long host name. I don't know if that's supported with pfSense.

Thank you for your appreciated support, It's working perfectly.

FYI, after doing some research on how to get hostnames resolved in IPv6, it looks like the best option is to put in a host override in the DNS resolver.

DNS Resolver -> General Settings -> Host override

There's a thread discussing the options here.

In regards to the length:

I just realized the 70 length request is not one that went through the VPN, but through a proxy on the WAN - the standard length includes frame type and MAC address info, which the VPNs strip before sending on (which also explains how they "hide" you), resulting in the 60 length.

I have a capture that goes through the VPN and is 60 length and working, but I'll need to dig it out. The net result is the same - unbound comes up.

And, yes, it doesn't surprise me that some IPs are being marked as "bad", even by the root servers. As VPNs use the same IP for multiple clients, it's likely that some of their IPs have been used for nefarious means, resulting in their being blocked, refused, etc.
SIGH

@olaszfiu Not sure what you ended up doing but I disabled DHCPv6 and set the DNS server names in the "Router Advertisements" tab.

Buy a managed switch.. That is the only way your going to fix this so you can put the tv box on the L2 that is between them and your pfsense box.

Or just get another dumb switch to use between the modem and pfsense and tv box

If you want multiple public IPs via dhcp for wan on pfsense.. Then use another physical interface, and put a switch between your isp device and pfsense. Now you have multiple wans, with different IPs.

You could then do port forwards for 1 IP to server IP behind, or even 1:1 nat, etc.

Can really do it with just vlan on 1 physical nic in pfsense, because it will use the same mac.

Hi all

I have finally figured out the relations behind the curtain.

The solution would be to set the domain name of pfsense to match the dynamic DHCP environment.
The DNS lookup is dependent from the setting general setup -> domain. The DNS lookup for DHCP dynamic entries are looked up by the value given there.

However, it is not my intention to use it in that way...

So the question is: how can I have different (or generic) sub-domain entries for subnets, independent from the pfsenses FQN?

Btw: is it supposed to work like that? Seems a bit odd..

Kind regards
Oliver