| Subject: | Bluecat Support ticket #10815: Don't accept (illegal) null hostname from DHCP client |
As discussed in Support ticket #10815 and evaluated by Marcin:
"The Host Name option must always contain a value per RFC2132, i.e. it must not be empty. So, the hostname option consisting of one letter, e.g. "a" is ok. I made an experiment and tried to configure dhclient to send empty hostname option, but it doesn't. I also tried to configure dhcpd server to hand out empty host name option, but it doesn't.
However, if there is a client that can actually generate an empty host name option and send it, the server will actually record empty host name option within a lease file. The server doesn't send this empty option back to the client, but it does record it in the lease. I was able to reproduce this behavior with a modified version of perfdhcp tool (bundled in Kea).
In my opinion the empty host name options should be ignored by the server and not recorded in the lease file."
---
And from me (Cathy) agreeing with Marcin that although we should fix this, we should not fix it unless in a new major release:
"However, and being cautious, we think that for currently supported versions of DHCP, that even though it is wrong that null hostnames requested by a client will find their way into the leases structures/file, that preventing that now might turn out to be a regressive behaviour for some production environments. So as the path of least surprise, we should not change this, other than in a new major release (i.e. for ISC DHCP 4.4.0)"
---
The crashes that have been reported in the Support ticket can anyway be addresses elsewhere - per bug ticket https://bugs.isc.org/Ticket/Display.html?id=29108
| Subject: | omapi_generic_set_value.patch |
Message body not shown because it is not plain text.