dhcpd no set domain name

Gertjan

@frankz said in dhcpd no set domain name:

The domain you enter is ignored in the client assignment.

I have :

I saw :

Its all grayed out, but correct.

And better :

A snipped of the DHCP negotiation / packet capture :

06:44:51.324391 IP (tos 0x0, ttl 64, id 57786, 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 0xd7236a0e, 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
	    Domain-Name (15), length 11: "blabla.arpa"

See the last line.
The DHCP server tells the client what domain name it has.

The client received the domain :

Carte Ethernet Ethernet :

   Suffixe DNS propre à la connexion. . . : blabla.arpa
   Adresse IPv6. . . . . . . . . . . . . .: 2a01:cb19:beef:a6eb::c7
   Adresse IPv6 de liaison locale. . . . .: fe80::daa9:bcf8:99cd:717e%11
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.6
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Passerelle par défaut. . . . . . . . . : fe80::92ec:77ff:fe29:392c%11
                                       192.168.1.1

Looks fine to me

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 ?
Screenshot 2024-03-22 alle 09.10.13.png

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 .