dhcpd no set domain name
-
@Gertjan Ok . But my goal is for clients to receive all the complete parameters, as my linux AD server currently runs. So my goal is for a default client to take the ip and domain name I assigned to the card in this case called guests . I don't know what you mean by list of domains present in clients, but I expect after the request of the dhcp:
Domain local.lan
Search local.lan
192.168.1.123 ( dns).
-
@frankz said in dhcpd no set domain name:
I don't know what you mean by list of domains present in clients
I mean : this is what the clients asks (a list) from the server :
Parameter-Request (55), length 14:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
Router-Discovery (31), Static-Route (33), Vendor-Option (43), Netbios-Name-Server (44)
Netbios-Node (46), Netbios-Scope (47), Unknown (119), Classless-Static-Route (121)
Classless-Static-Route-Microsoft (249), Unknown (252)When I set this :
My DHCP clients receive it :
-
@Gertjan said in dhcpd no set domain name:
Btw : I don't see this as a real solution. It's easier to enter a 'fake' domain name in DHCP server settings.
Seems like a real waste of time and effort for zero benefit.. Which any changes you make to services.inc will just get overwritten on upgrade..
To do what?? Hide a domain name from client? What advantage is that? These are clients on your network.. What do you care if they know your domain is home.arpa - which is what you should be using ;)
-
@johnpoz said in dhcpd no set domain name:
@Gertjan said in dhcpd no set domain name:
Btw : I don't see this as a real solution. It's easier to enter a 'fake' domain name in DHCP server settings.
Seems like a real waste of time and effort for zero benefit.. Which any changes you make to services.inc will just get overwritten on upgrade..
To do what?? Hide a domain name from client? What advantage is that? These are clients on your network.. What do you care if they know your domain is home.arpa - which is what you should be using ;)
Yes, in fact, I agree. Clients must receive what the pfsense dhcpd has declared. The fact that you write that it is of little use is unfortunately correct ..... As the first change that will be made to the pf configuration will be overwritten. I don't understand why such an important problem has been underestimated. -
@frankz said in dhcpd no set domain name:
I don't understand why such an important problem has been underestimated.
Important to who? You are prob the only one.. Been here for many many years, read way to many posts.. And have never seen such a question come up.. Hiding the domain name from clients on your network is not something I would think anyone but you has gotten into their head that they should do..
The pfsense gui is there to make basic configuration of dhcp easy for your typical user, that might not be well versed in dhcp.conf - if you are not happy with the options and features of what is presented. Run dhcp on something else on your network, and tweak the dhcp.conf to your hearts content..
Put in a feature request for it... They are working on the new KEA integration, maybe they will add such a feature? But don't hold your breath ;)
Do these clients have access to pfsense dns? if so a simple query for pfsense lan IP will return the fqdn. Do they have access to the web gui on any IP of pfsense, if so the CN in the cert will give them the fqdn..
Just at a loss to what client I would allow on my network that I should hide the domain from? But simple solution would be just put them on a vlan and hand them home.arpa or whatever else you want that is not your domain name.. And I wouldn't allow them to access any pfsense gui IPs nor use your dns, I would point them to something external for dns if you don't want them knowing anything about the rest of your network.
-
@johnpoz I assert the opposite! My question was related to the fact that clients must have the dnsdomainname! Dhcpd sends it but the one not declared in the parameters. Anyway, considering that your answers are not in line with what I had asked, I would ask you for your intervention. In order to avoid any misunderstanding, I just asked that what is declared in the dhcp is not reflected in the configuration of the clients that continue to receive the main domain.
-
@frankz my gawd dude this is such a pointless thread... Yes by default dhcp hands out what you set for pfsense domain.. Because this is the NORM..
If you want to hand out a different domain, change it for the vlan these clients are on.. Not handing out any domain is just utter nonsense..
-
@johnpoz il Dhcp is configuredkk on another network card where pfsense has to deploy another domain because it has to perform for that dhcpd interface. I don't think it's that impossible also because this option has always existed that has never worked.
-
I noticed that with the assignment of the ip or rather the reservation on the dhcp, the domain e.g. guest.lan, local.lan, etc. is assigned.
So it seems to work only if in the network segment where the ipfsense serves other hosts with other ips and domains , it works . Unlike if I do not make the reservation it takes the domain name declared by the pfsense e.g. mypfsense.fqdn .
-
@frankz so I know this thread is a bit old.. And I still don't see the point of trying to hide your domain from devices on your network. But I have found a use case for not handing out any domain to iot type devices..
Seems these iot devices now add the domain they get as a search suffix, especially when what they try and resolve does not resolve, like in the case of blocking with pihole or something.
I noticed it on my alexas first, but then noticed my firesticks where doing it too - not sure if something changed in their software, or I just never noticed it before.. But I had recently updated the rasbian on my pi from bulleye to bookworm - and I had to reinstall some stuff. pihole being one of them.. So I was paying more attention to what was being queried, and returned, what was being blocked, etc. Just making sure my new install of pihole was working the way I wanted, etc.
So the alexas were doing a query for something.a2z.com - which wasn't blocked, but they were also seen doing querys for that same fqdn with just my home.arpa added to it... Maybe the original query just failed for some reason, even if I wan't blocking it. So something.a2z.com.home.arpa - which is never going to resolve to anything. But it was just a bunch of log spam in pihole query log..
At first I just stopped it from being listed as a top domain on the dashboard.. But then I thought why is alexa adding that search suffix? It sure is never going to resolve that in home.arpa - and to be honest they would have zero reason to ever resolve anything that even does exist in my home.arpa domain, and if they did it would resolve if was a fqdn query for say something.home.arpa.. But if I could figure out a way to prevent alexa and my firesticks from using home.arpa as a search suffix that would for sure remove the extra dns queries these devices seemed to be doing.
So I figured hey if I don't hand the domain to these devices, they wouldn't be able to add that as a search suffix, so they wouldn't be able to do a query for something.a2z.com.home.arpa
So solution I found is if you set a custom option for the domain (dhcp option 15) and just leave it blank, then they don't get anything. I sniffed the dhcp traffic and no domain (option 15) is sent..
This is what gets put into the dhcpd.conf
option custom-opt8-1 "";I then went and rebooted all my alexas - and have not seen a single query for something.com with home.arpa added to it from them. So log spam stopped.
Since their should be no way that they can even learn about this home.arpa domain now - there should be no way they should ever do a query with that suffix tacked onto the end.
This seems to be a way to accomplish what you were after without having to edit the services file for dhcpd, and don't have to worry about upgrades overwriting your change, etc.
This really has nothing to do with security of the device knowing the domain, its about reducing useless dns queries that only amount to log spam.
