Why can't I resolve hostnames for devices on different VLANs?
-
@bingo600 said in Why can't I resolve hostnames for devices on different VLANs?:
don't want to open
Why?
I swear this worked before. I had a PFS box before but it broke. So I got a new one and did a brand new install using the latest version.
I feel like there is some setting I am not setting properly...
-
@imthenachoman
How many ways can a a host be resolved on a pfSense ?L3
1: DNS
2: mDNS (Avahi)L2
3: Broadcast
4: NetbiosIf it worked across vlans , it is prob. 1 or 2
Re: DHCP registering in unbound , requires Unbound to restart on each DHCP "add" , leading to sitewide DNS outage during the restart.
-
Are you using pfSense for DHCP on both VLANs?
Are you registering dhcp leases in unbound? (not enabled by default)
Are you using the same domain on both VLANs?
When you try to ping 'cam_living_room' that host tries to resolve it by appending it's own domain on the end unless you've send it some other search domain to use. So is it actually trying to resolve the host using the correct FQDN?Steve
-
I figured out what was wrong. For some reason the
Register DHCP leases in the DNS Resolversetting was unchecked. I checked it and now it works as expected. -
@imthenachoman said in Why can't I resolve hostnames for devices on different VLANs?:
For some reason the Register DHCP leases in the DNS Resolver setting was unchecked. I checked it
You've opened the can of worms.
The issue now is, that for every device that requests or renews a DHCP lease, unbound will get restarted.
If you have many hosts using DHCP, you will detect 'something isn't right' as your network seems to stutter. Observing closely will show you that the DNS is out. Because it's restarting 'all the time'.
This is on one the the reasons pfBlockerNG doesn't want to have this option checked :
Just be aware of this effect.
-
Mmm, only in Python mode though, as it says there.
I run with DHCP clients registered and with pfBlocker/DNS-BL running and have never seen an issue. I have 25-30 hosts.
Steve
-
Yeah .... I somewhat presumed that, when you use pfBlockerNG, you want "all" the DNS details, and the python script is the way to do so.
Regex blocking, log details, policy DNS facilities, this can only be done when unbound is given a callback function, the pfBlockerNG "python mode" script.I dealt with Resolver's "DCHP Client Registered" option myself : I declared all known LAN devices that I have to access with Static DHCP MAC leases. And done.
-
@gertjan said in Why can't I resolve hostnames for devices on different VLANs?:
I declared all known LAN devices that I have to access with Static DHCP MAC leases. And done.
I am a fan of this myself - while its a bit tedious to get started with if you have lots of devices. Overall I think this is the most bullet proof method. Stuff I want to resolve, temporary devices that might join my network. wifi guest for example - or some box working on, etc. I don't really care or need to resolve this to some fqdn.
Once the device is going to be on my network ongoing - then just setup a reservation for it. done and done ;)
-
Makes me wonder ....
Why doesn't unbound come with a 'written by Netgate, Python scripts' that rereads (refreshes) a dhcp 4+6 leases file (based on a signal, or file size time stamps, a regularly) ?
Please guys, just a small Python script ?! This will bury this issue for good, and we have best of both worlds. Let's nuke that dhcpleases process for good.
I presume (a lot, I know) that unbound can 'host' several callback Python scripts.
We'll have one option less in the Resolver settings, DHCP clients with a valid host name are locally registered in the DNS, period.
Less fuss in pfBlockerNG.Not wondering, I know, I'm out of subject here - sorry for that.
edit : Humm : dnsmasq would still have to use dhcpleases, I guess.
But who is using dnsmasq these days ? ;) -
@gertjan said in Why can't I resolve hostnames for devices on different VLANs?:
But who is using dnsmasq these days ? ;)
A surprising number of people.
-
Because they have to feed their pi-hole ?
Because they have this need to to feed the big-data DNS corporations ?Both are fine to me, although I suspect that often the second choice is take by the 'I've seen some one doing that also - dono why' reason.
I've nothing against dnsmasq or the forwarding way of DNS, in the past, pfSense was also forwarding out of the box, unbound was added later on. As we all were learned (told ?) to 'chain on to the ISP DNS' (for probably very valid reasons, very valid in the past).
I'm more a 'let works out of the box' guy. Not because 'Netgate' has build in this typical setup, but because t makes sense if you think (a lot - I'm getting slow ) about it.
Take the DNS for example : It's 2021 now, and somewhere in de 90ties was told how a typical DNS system should work in "network". With the root, tld and name servers and such.
Years after that, ISP started popping out of the ground, Internet became something public, and all kind of 'patched' system where used to make it work for everybody.
Also, their is a mutual exlcusive choice to make : Forwarding and Doh, or DNSSEC, as we can't have both. I tend to chose for the last one. -
@gertjan said in Why can't I resolve hostnames for devices on different VLANs?:
Forwarding and Doh, or DNSSEC, as we can't have both.
Well you can "have" dnssec and forwarding - just forward to resolver that does dnssec ;) Many of them do it already. So dnssec is being done - but do you trust where your forwarding is always the big question.
You don't have to ask for it - if where your forwarding to is doing dnssec - it is being done regardless if ask for it or not.
example
Does Quad9 implement DNSSEC?Yes. Quad9 provides DNSSEC validation on our primary resolvers.
9.9.9.9, 149.112.112.112
2620:fe::fe, 2620:fe::9In addition we validate DNSSEC on our EDNS enabled service.
9.9.9.11, 149.112.112.11
2620:fe::11, 2620:fe::fe:11This means that for domains that implement DNSSEC security, the Quad9 system will cryptographically ensure that the response provided matches the intended response of the domain operator. In the event of a cryptographic failure, our system will not return an answer at all. This ensures protection against domain spoofing or other attacks that attempt to provide false data. Learn more about DNSSEC here: https://www.icann.org/resources/pages/dnssec-qaa-2014-01-29-en
-
You guys have me so lost now.
@gertjan said in Why can't I resolve hostnames for devices on different VLANs?:
The issue now is, that for every device that requests or renews a DHCP lease, unbound will get restarted.
If you have many hosts using DHCP, you will detect 'something isn't right' as your network seems to stutter. Observing closely will show you that the DNS is out. Because it's restarting 'all the time'.Okay. I will see if it creates an issue for me. Is it possible to create some kind of static mapping? There is only one host on VL20 that I want DNS name resolution to work for from VL10. What should I do?
@gertjan said in Why can't I resolve hostnames for devices on different VLANs?:
This is on one the the reasons pfBlockerNG doesn't want to have this option checked :
Good to know. I was going to setup pfBlockerNG next. I guess I will have to uncheck that box.
@stephenw10 said in Why can't I resolve hostnames for devices on different VLANs?:
Mmm, only in Python mode though, as it says there.
How can I check if I am in Python mode? Does this mean I am using Python mode?
@gertjan said in Why can't I resolve hostnames for devices on different VLANs?:
I dealt with Resolver's "DCHP Client Registered" option myself : I declared all known LAN devices that I have to access with Static DHCP MAC leases. And done.
Is that the same as "static mapping"? I assume so but I'm still learning so I want to confirm.
@gertjan said in Why can't I resolve hostnames for devices on different VLANs?:
Why doesn't unbound come with a 'written by Netgate, Python scripts' that rereads (refreshes) a dhcp 4+6 leases file (based on a signal, or file size time stamps, a regularly) ?
I know Python. Is there some existing file that does this that I could use to refactor to be more efficient (threaded)?
-
Yes, DHCP static mapping is what's being discussed here.
https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv4.html#static-mappingsYou can set Unbound to resolve those separately and it doesn't require continually restarting the service.
Steve
-
@stephenw10 Great. Thank you!
