dhcpd no set domain name

[tgl]

I have kind of the opposite complaint: there doesn't seem to be any way to prevent the dhcp server from sending the system's configured domain name. I would like it to do that on the "house" VLAN, but to send nothing on the guest and IoT VLANs, which don't have any access to the house net and shouldn't see its domain name either. However, leaving the domain name field empty is interpreted as "use the system setting". I guess I could use a dummy entry like foobar.arpa or so, but that sure seems like a kluge.

[Gertjan]

@tgl

Complaint ?
Not sure if it works that way I know it's a world wide sport : trying to break DNS
What about : If a DHCP clients asks for a network domain name, the server has to give one. RFC 2131.
So, a solution might be : check up with every client device so it doesn't do so anymore. And I know, this isn't probably possible.

If you have one, check out your ISP router: is was probably handing over a 'name' like 'local', you know why now : it had to do so. So, the solution is as you already mentioned : if you want to purposely a hide a name, use a 'another' one.

[tgl]

@Gertjan said in dhcpd no set domain name:

What about : If a DHCP clients asks for a network domain name, the server has to give one. RFC 2131.

Not sure I believe that argument, first because I see no such requirement in RFC 2131 (admittedly, maybe it's buried in some lower-level RFC), and second because the DHCP servers I've used before this one didn't send a domain name unless I specifically configured them to.

[Gertjan]

@tgl said in dhcpd no set domain name:

Not sure I believe that argument,

And your probably right.

Check this : https://serverfault.com/questions/1060330/isc-dhcp-server-does-not-push-domain-name-to-client

Check this : /var/dhcpd/etc/dhcpd.conf

The "option domain-name "some-domain.tld";" is set no matter what.
And these options are send to a requesting client "no matter what".

What about not setting it at all => omitting this line in the config ?

Try this : Remove / comment out line 2195 /etc/inc/services.inc

[frankz]

@Gertjan Ciao e grazie per le tue indicazioni .
Tu dici di commentare o rimuovere questa riga ?

[Gertjan]

@frankz

Yes.

(alwyas) Make a copy of the file first :
Example

cp /etc/inc/services.inc /etc/inc/services.inc.old

Then edit ...
and test.

If things go bad :

cp /etc/inc/services.inc.old /etc/inc/services.inc

Btw : You are using ISC DHCP, right, and not KEA ?

[frankz]

@Gertjan because , ikea not have a dns name client register .

[Gertjan]

@frankz

Because KEA uses another config file - other config option - is another process - but it does the same thing : it's a DHCP server.

[frankz]

@Gertjan Hi, I performed the procedure you indicated to me on line 2195. Unfortunately, the result is unchanged.

[Gertjan]

@frankz

I did the same thing.

Removed the line :

Saved the file.

Restarted the dhcpv4 server.

Checked that the dhcp server config file didn't contain the network name anymore :

Packet capturing on my LA? using UDP and ports "69 68" :

14:04:03.780342 a4:bb:6d:ba:16:a1 > 90:ec:77:29:39:2c, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 128, id 49940, offset 0, flags [none], proto UDP (17), length 328)
    192.168.1.6.68 > 192.168.1.1.67: [udp sum ok] BOOTP/DHCP, Request from a4:bb:6d:ba:16:a1, length 300, xid 0xf4d1633c, Flags [none] (0x0000)
	  Client-IP 192.168.1.6
	  Client-Ethernet-Address a4:bb:6d:ba:16:a1
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Request
	    Client-ID (61), length 7: ether a4:bb:6d:ba:16:a1
	    Hostname (12), length 7: "Gauche2"
	    FQDN (81), length 10: "Gauche2"
	    Vendor-Class (60), length 8: "MSFT 5.0"
	    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)
14:04:03.780541 90:ec:77:29:39:2c > a4:bb:6d:ba:16:a1, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 31622, offset 0, flags [none], proto UDP (17), length 328)
    192.168.1.1.67 > 192.168.1.6.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xf4d1633c, Flags [none] (0x0000)
	  Client-IP 192.168.1.6
	  Your-IP 192.168.1.6
	  Client-Ethernet-Address a4:bb:6d:ba:16:a1
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: ACK
	    Server-ID (54), length 4: 192.168.1.1
	    Lease-Time (51), length 4: 86400
	    Subnet-Mask (1), length 4: 255.255.255.0
	    Default-Gateway (3), length 4: 192.168.1.1
	    Domain-Name-Server (6), length 4: 192.168.1.1

Important to note is here that the DHCP client request contains a list with wanted parameters, and the "Domain-Name (15)" is one of them.

You can see for yourself that what my DHCP server doesn't have, can't be given : there is no domain name in the reply anymore.

Works for me

Btw : I don't see this as a real solution. It's easier to enter a 'fake' domain name in DHCP server settings.

[frankz]

@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).

[Gertjan]

@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 :

[johnpoz]

@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 ;)

[frankz]

@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.

[johnpoz]

@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.

[frankz]

@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.

[johnpoz]

@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..

[frankz]

@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.

[frankz]

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 .

[johnpoz]

@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.